Resendの料金と使い方：小規模チームのメール基盤として選ぶ条件

Resendの料金と使い方：小規模チームのメール基盤として選ぶ条件

Resendは、会員登録や領収書、パスワード再設定のメールを、手間をかけずにアプリケーションへ組み込みたい小規模なプロダクトチームに有力な選択肢です。ただし、本番運用の責任まで任せられるわけではありません。無料枠は1日100通までで、上限超過で拒否されたメールはアプリ側で処理する必要があります。開発のしやすさでResendを選び、ピーク時の需要に合わせてプランを決め、データの要件に照らしてサービス自体が適切か判断しましょう。

2026年11月13日時点のResendの公開料金表、ドキュメント、セキュリティページを確認しています。本レビューが評価するのは、文書で確認できるワークフロー、制限、料金の計算です。ログイン後の実機検証や、受信トレイへの到達率測定を行ったという主張ではありません。

Resendは何ができるメール配信サービスですか？

Resendは、プログラムから操作するAPI、またはメール送信の標準プロトコルであるSMTPを通じて、アプリケーションから呼び出すメール配信サービスです。イベントをきっかけにした個別メールや、マーケティング向けのBroadcastsを送信でき、連絡先とテンプレートの管理、配信イベントの通知、アプリで処理するためのメール受信にも対応します。ただし、領収書の送信先、再設定リクエストの正当性、送信失敗時の対応を決めるのは、引き続き自社のプロダクトです。導入ドキュメントで、送信方法と対応言語の連携を確認できます。

どんなチームに向いていますか？見送るべきなのは？

Resendが向いているのは、メールもアプリケーションのサービスの一つとして扱いたい創業者や開発者です。テンプレートをバージョン管理し、イベントデータを渡し、送信して結果を処理する、という流れです。特に、同じメンバーがアプリとトランザクションメールの両方を担当する小規模なSaaSと相性がよいでしょう。

判断材料は、組み込みの工数、失敗時の処理、マーケティング運用の担当者、データの制約です。根拠なく「ある事業者のほうが受信トレイに届く」と主張して選ぶものではありません。

今のサービスで問題がなく、Resendで解決する課題を具体的に挙げられないなら、移行は見送りましょう。 APIが扱いやすいという理由だけで、安定稼働中のメール配信を移す必要はありません。送信インフラの分離が必須ならPostmark、AWS内で運用を管理し続けたいならAmazon SESを候補に入れる価値があります。

マーケティング担当者が日々オンボーディングのシナリオを運用するなら、SaaSのライフサイクルメールを中心に据えたLoopsも比較しましょう。Resendにも現在はAutomationsがあります。「API経由の送信しかできない」という古い認識で判断せず、担当者が実際に維持するシナリオを比較するべきです。

Resendの代替サービスは、どんな場合に選ぶべきですか？

Twilio SendGrid： 既存のEmail API、SMTP、Marketing Campaignsの運用で要件を満たしている場合に適しています。今の構成を維持する負担が、移行による具体的なメリットを上回らない限り、使い続けるのが妥当です。

Postmark： トランザクションメールと一斉配信の分離が決め手になる場合に向いています。Message Streamsのドキュメントでは、IPインフラの分離が説明されています。これは具体的な設計上の違いであり、自社ドメインの配信結果がよくなるという約束ではありません。

Mailgun： 送信に加え、メールアドレスの検証とルーティングも要件に含まれるなら候補になります。その場合、送信APIの書きやすさより、こうした周辺ツールのほうが重要です。

Amazon SES： エンジニアがすでにAWSの運用を担当し、その環境にメールを組み込みたい場合に適しています。監視や障害対応まで含めた実装工数全体を比較しましょう。

Loops： SaaSのライフサイクル施策の担当者が、オンボーディング、利用促進、休眠顧客の呼び戻しを起点に選定する場合に向いています。決める前に、同じシナリオを両製品で再現してみましょう。

より広いキャンペーン配信基盤を検討するなら、GetResponseのレビューも参考になります。ただし、アプリのメール送信基盤を選ぶ場合とは、解決する課題が異なります。

ResendメールAPIの使い方：イベントをメール送信につなげる

Resendの強みは、アプリケーションのイベントからテンプレートメールの送信までを短い手順でつなげられることです。Node.js SDKに送信者、宛先、件名、本文を渡すと、データまたはエラーを含む結果が返ります。Python、PHP、Ruby、Go、Rust、Java、.NETのクイックスタートも公開されており、導入にReactは必須ではありません。

決済成功後の領収書を例に考えます。アプリは決済を記録し、領収書のデータを用意してResendに送信を依頼し、返されたメッセージIDをその決済にひも付けて保存します。これでサポート担当者は、顧客名だけを頼りに探すことなく領収書を調査できます。基本の送信処理はNode.jsクイックスタートで確認できます。

メールテンプレート：本文を誰が管理するかで選ぶ

React Emailを使うと、Reactコンポーネントからメール本文を組み立てられます。Resendはコード管理のメールとホスト型テンプレートの両方に対応しています。React Email連携ガイドでは、ローカルプレビュー、HTMLまたはプレーンテキストへの出力、ホスト型のTemplatesへのアップロードを説明しています。

領収書の変更をアプリのレビューに通すべきなら、レイアウトはコードで管理します。エンジニア以外が文言を修正する必要があるなら、ホスト型テンプレートで役割を分けるほうが適している場合があります。アプリは変数を渡し、コンテンツの担当者が本文を編集する形です。Templatesのドキュメントでは、エディター、変更履歴、公開済みテンプレートIDによる送信が説明されています。

利点は、変更ごとの責任者を明確にできることです。ただし、どちらの方法でも、プレビューだけを見てパスワード再設定メールを承認してはいけません。公開前に、顧客が使うメールクライアントでリンク、有効期限の挙動、本文を確かめましょう。

リトライには同じ処理だと識別できるキーが必要です

Resendは冪等性キー（idempotency keys）に対応しています。同じ送信要求を繰り返した際に、メールを再送せず元の結果を返すための識別子です。ドキュメント上の保護期間は24時間です。領収書なら、その発行イベントからキーを生成し、リトライ時もリクエストの内容を変えないようにします。冪等性のガイドで、保護期間と、同じキーに異なるペイロードを渡した場合のエラーを確認できます。

アプリ側でも、この期間の境界を意識する必要があります。期限が過ぎてからジョブを再実行するなら、領収書の送信をすでに依頼したかどうか、永続的な記録を自前で持たなければなりません。サービス側の重複排除はリトライ時に役立ちますが、業務イベントの恒久的な履歴にはなりません。

SMTPなら既存アプリも移行しやすくなります

すでにSMTPでメールを送るアプリにもResendを利用できます。SMTP設定では、サーバーがsmtp.resend.com、ユーザー名がresend、パスワードがAPIキーと指定されています。ポート465は暗黙的TLS、587はSTARTTLSを使います。メールクライアントやフレームワークでも、それに対応する暗号化設定を選びます。

この方法なら、既存のメール生成コードを保ちながら送信経路を変更できます。ただし、障害調査には制約があります。Resendによると、SMTPで送ったメッセージもEmailsの一覧に表示されますが、SMTPサーバーログは提供されません。接続レベルの調査が日常的に必要なら、移行前に考慮しましょう。

ドメイン設定：認証も公開準備に組み込む

Resendには認証済みの送信ドメインが必要です。API連携と並べて、公開前のチェック項目に含めましょう。ドメインのレコードを公開する仕組みであるDNSで、Resendが自社の代わりにメールを送信することを許可します。

SPFは送信を許可するインフラを示します。DKIMはメッセージに暗号署名を付けます。DMARCはドメインの認証ポリシーに適合しないメールを受信側がどう扱うかを指定します。それぞれ役割が異なり、ドメイン認証の表示が緑になっても、DMARCを意図的に設定する必要はなくなりません。

新しいSaaSなら、次の手順が実用的です。

1. 1

   送信元と送信リージョンを決める

   ResendのDomainsページでドメインを追加します。新規の送信元には、account.example.comのように用途が分かるサブドメインを使い、受信者に適した送信リージョンを選びます。

2. 2

   生成されたレコードを公開する

   Resendが示すDKIMとSPFの設定を、表示どおり正確にDNS事業者の管理画面へコピーします。顧客向けメールを接続する前に、ドメイン認証を済ませましょう。チュートリアルからコピーした汎用レコードで代用しないでください。

3. 3

   DMARCを追加し、送信用途を分ける

   認証後にDMARCを設定します。ニュースレターとトランザクションメールの設定を個別に管理できるよう、マーケティング専用のサブドメインも検討しましょう。

4. 4

   移行時は既存の送信実績を生かす

   すでに送信実績のあるアドレスを使っているなら、その履歴を踏まえて移行を計画します。Resendは、実績のあるアドレスを機械的に新しいサブドメインへ置き換えず、維持することを勧めています。

手順はドメイン設定ガイド、移行時の例外と用途別のトラッキング設定は認証済みドメインの説明で確認できます。パスワード再設定では、設定項目があるからといって全クリックを計測するより、シンプルで直接的なリンクを優先しましょう。

配信イベントと受信メール：送信後の処理までつなげる

Resendは、送信APIを呼び出した後の情報もアプリに返します。顧客から「領収書が届かない」と言われたときに役立つ部分です。Webhookは、イベント発生時にアプリへ届くHTTPSの通知です。Webhookガイドでは、配信、バウンス、開封、クリックのイベント、リクエストの検証、再実行、自社データベースへのイベント保存を説明しています。

領収書の処理では、Webhookリクエストを検証し、保存済みのメッセージIDに各イベントをひも付け、繰り返し実行しても安全な処理にします。バウンスは、誰も見ないログに埋もれさせず、サポート担当者が対応できる状態につなげるべきです。サービスの保存期間を超えて必要な履歴は、自社システムに保持します。

Deliveredは、受信トレイで読まれたことを意味しません。 Resendは、受信者のメールサーバーに届いた状態と定義しています。メール管理ドキュメントでは、delivered、bounced、delayed、failed、suppressedを区別しています。顧客へ失敗の状況を説明するときも、この違いを踏まえましょう。

到達性ツールは診断に役立ちますが、受信トレイへの到達を証明しません

ResendのDeliverability Insightsは、リンクのドメイン不一致、DMARCの未設定、プレーンテキスト本文の欠落などをチェックします。自分たちが管理するメッセージを点検するには便利ですが、受信トレイへの到達率を示すものではありません。

サプレッションリストは、ハードバウンスや苦情があったアドレスへの継続送信も防ぎます。重要なのは、送信抑止がチーム全体に適用されることです。登録されたアドレスは、ドメインやサブドメインをまたいで、トランザクションメールとBroadcastの両方で送信対象から除外されます。サプレッションの説明には、Gmail/Google Workspaceが苦情イベントを返さない点も記されています。

マーケティングとトランザクションメールを併用する場合、ここに実務上の注意点があります。送信を抑止された受信者を別の送信サブドメインへ移しても、パスワード再設定メールは再び届くようにはなりません。抑止理由を調べ、アカウントを復旧できる手段を用意しましょう。理由を確認せずに抑止を解除し、再送してはいけません。

メール受信にも対応しています

Resendは、認証済みドメイン、またはサービスが管理するresend.appサブドメインでメールを受信できます。受信ガイドには、Webhook通知、本文と添付ファイルの取得、転送、スレッドを維持した返信が説明されています。

実用例は、注文の領収書への返信です。受信メッセージを注文にひも付け、本文を取得して、サポートの対応タスクを作成します。受信基盤を自分たちで運用する手間は減りますが、添付ファイルの扱い、送信者を信頼できるかの判断、受信メールにプロダクト内で何を変更させてよいかは、引き続き自社の責任です。

BroadcastsとContacts：マーケティングの配信意図を明確にする

Resendなら、小規模なチームも、配信システムをゼロから作らずにニュースレターや製品のお知らせを送れます。Broadcastsにはエディター、予約送信、連絡先の絞り込み、効果測定があります。Broadcastsガイドでは、ダッシュボードとAPIの両方の操作を説明しています。

新機能のお知らせなら、配信に同意した連絡先を追加またはインポートし、対象者をSegmentにまとめ、適切なTopicを選びます。その後、本文を用意し、配信停止の挙動を確認して、Broadcastを予約します。Segmentは送信側の内部的なグループ分け、Topicは受信者が選択できる配信の設定です。

古い連携がAudiencesを前提にしているなら、認識を更新する必要があります。現在のResendは全体共通のContactsとSegmentsを使います。同じメールアドレスが複数のセグメントに属しても、Contactとしては1件と数えます。Audiencesからの移行ガイドには、Audiences APIが非推奨であると記されています。配信停止を特定のAudience内だけの処理として扱う古いコードでは、この変更が重要になります。

Automationsには、カスタムトリガー、条件、遅延、イベント待機のステップも用意されています。そのため、ウェルカムメールのシーケンスをすべてアプリ側で実装せず、Resend内に置くこともできます。ライフサイクル施策を移す前に、実際の開始条件と終了条件を整理しましょう。シーケンスを描けるだけでは、誰が維持管理するかは決まりません。

Resendの料金：本番ではProが現実的な出発点です

ResendのProの基本枠は月額$20で50,000通、1日あたりの通数上限なし、10ドメインです。Freeは月3,000通、1日100通まで、3ドメインです。月間枠より先に問題になるのが、この1日の壁です。仮に公開当日に60件の登録があり、登録ごとに2通送るなら、その日は120通が必要になります。公開中の料金ページには、月100,000通で月額$90からのScaleと、個別見積もりのEnterpriseも掲載されています。

Resend APIの料金：超過課金より先に通数枠を比較する

Proの基本枠を使い切った場合、1,000通あたり$0.40です。$20を50,000で割り、1,000を掛けた計算です。実際の利用が5,000通にとどまるなら、同じ月額でも1,000通あたり$4になります。これは契約枠に対する費用であり、受信トレイへの到達成功件数に対する単価ではありません。

提供元の機械可読な料金表には、100,000通で$35のProもあります。同じ通数をProの基本枠に超過課金を有効にして送ると、$20 + 50 × $0.90 = $65です。超過課金やScaleを次の選択肢と決めつける前に、Proのより大きな通数枠を比較しましょう。

マーケティングは別の料金体系です。Freeは1,000件の連絡先まで、マーケティング向けProは5,000件で月額$40から、Enterpriseは個別見積もりです。Broadcastの送信回数は連絡先枠の範囲内で無制限で、トランザクションメールの通数枠を消費しません。一方、/emailsでニュースレターを送るとトランザクション枠を使い、配信停止処理も自前で実装する必要があります。

想定する読者のチームなら、本番の集中送信がFreeの上限を超え得る時点で、有料のトランザクション向けProを出発点にします。連絡先リストの規模に応じて、マーケティングの容量を追加しましょう。Scaleは、専用IPの選択肢など運用機能で評価すべきです。名称だけで、大量送信を最も安く購入できるプランだとは判断できません。

選定を左右する制限事項

Resendの主な制約は、配信運用の責任、保存期間、共有される上限、保存データにあります。最初のAPI呼び出しが洗練されているかどうかよりも、重要な論点です。

通数上限で拒否されたメールはアプリ側で対処します

Resendでは送信と受信の両方がトランザクション枠に算入され、宛先が複数あれば個別に数えます。Freeの日次枠はUTCの午前0時にリセットされます。有料プランの超過課金は管理者が有効にするまで無効です。上限超過で送信が拒否されるとエラーが返り、Resendはそのメールをキューに入れることもリトライすることもしません。アカウントの利用上限のドキュメントに明記されています。

再試行できる処理は自前のキューに入れ、上限による失敗を通知する仕組みを設けましょう。パスワード再設定では、古いジョブをリトライする前にトークンの有効性を確認します。枠のリセット後に送れても、その時点では役に立たないメールかもしれません。

有料プランでも、秒間リクエスト数が自動で増えるわけではありません

すべてのアカウントはチームあたり毎秒10リクエストから始まり、この枠をAPIキーとドメインで共有します。キーを追加しても枠は増えません。バッチ送信では1リクエストに最大100通をまとめられますが、キュー側でもリクエスト上限を守る必要があります。Resendによると、プランをアップグレードしても自動的には引き上げられず、より高い処理量にはサポートとの別途相談が必要です。

これは、容量とスループットの違いです。容量は月に何通送れるか、スループットは集中時にアプリが何回リクエストできるかを示します。両方を踏まえて予算と実装を考えましょう。

保存期間のあるログは恒久的な監査記録にはなりません

Free、Pro、Scaleのメールとログの保存期間は30日で、Enterpriseは柔軟な保存期間に対応します。領収書についての問い合わせやサポート調査が後から発生し得るなら、イベント履歴は自前で保存しましょう。業務イベントも、サービスの24時間の冪等性保護とは独立して保持します。

期限前の削除にも制約があります。Resendの公開データ取り扱いガイドによると、個別メールを削除するAPIはありません。送信済みメッセージの早期削除にはサポートへの依頼が必要で、受信メッセージは保存期間が終わる前に削除できません。プログラムから即時削除する必要があるワークフローには不向きです。

欧州から送信しても、欧州に保存されるわけではありません

Resendの送信リージョンには、バージニア北部、アイルランド、サンパウロ、東京があります。リージョンのドキュメントでは、送信場所と保存場所を区別しています。

メッセージ本文、配信ログ、Webhookペイロード、アカウント記録を含む顧客データは、米国に保存されます。Resendによると、保存データをEUへ移す設定はありません。GDPRページでは、準拠に関する立場、自己監査、標準のDPAとデータ移転条項を説明しています。これらの説明があっても、アイルランドの送信ドメインがEU内だけの保存に変わるわけではありません。

ResendはSOC 2 Type IIへの準拠も表明しています。公開ページには報告対象期間が示されていますが、報告書そのものの閲覧にはログインが必要です。セキュリティ概要には暗号化の保護策が掲載され、HIPAAは「In progress（対応中）」とされています。ここで確認しているのは提供元の公表内容であり、独立した準拠監査ではありません。

EU内だけのデータ保存や、現時点で利用可能なHIPAA対応の契約・体制が調達の必須条件なら、送信リージョンの選択肢やセキュリティのバッジだけでResendの採用を承認してはいけません。 組み込みを始める前に、正確な要件を解決しましょう。

結論：周辺の運用まで担えるチームなら有力です

小規模なプロダクトチームが、テンプレート、APIまたはSMTPでの送信、配信イベント、ときどき行うマーケティング配信までを一貫した流れで扱いたいなら、Resendは有力です。プロダクトの挙動を自分たちで管理しながら、組み込みの負担を減らせる点に価値があります。

一方、米国での保存が要件に合わない、SMTPレベルの診断が不可欠、上限超過やリトライをアプリで安全に処理できない場合は、判断が変わります。移行の具体的な見返りがなければ、今動いている既存サービスを使い続けるのもよい選択です。

来週の実装に向けて、パスワード再設定と領収書のフローをそれぞれ、ドメイン認証、上限超過による拒否、重複リクエスト、バウンス処理、サポート時の検索まで通して確認しましょう。ピーク日の通数見積もりも含めます。ウェルカムメールがきれいに表示されるという理由だけでなく、失敗が起きる各地点で担当者と期待する挙動を明言できるなら、Resendを選びましょう。

よくある質問

製品名は、英語で「メールを再送する」という一般的な操作名と重なります。以下では、製品とメールボックスの操作を区別して説明します。

無料で使えるメール送信サービスには何がありますか？

アプリ向けなら、Freeの日次・月次上限に収まる場合、Resendは妥当な出発点です。ただし、公開時の集中送信で使い切る可能性があれば、無料枠だけでは本番運用に十分とはいえません。最も忙しい日に合わせてサービスの規模を選びましょう。

新しいOutlookでメールを再送するには？

新しいOutlookで「送信済みアイテム」を開き、対象のメールを選び、その他のオプションのメニューから「高度なアクション」→「メッセージの再送信」を使います。送信前に下書きを確認しましょう。Microsoftの再送手順は、このメールボックス機能を説明したもので、ResendのAPIとは無関係です。

英語のresentとResendはどう違いますか？

「resend」は「再び送る」という意味で、「resent」はその過去形です。先頭を大文字にしたResendは、本記事で紹介しているメールプラットフォームのブランド名でもあります。

送信済みのメールを取り消すには？

Resendをメールボックスの送信取り消しツールとして扱わないでください。Outlookには別途、アカウントや組織の条件がある取り消し機能があります。Microsoftの取り消し機能の説明によると、外部や個人のアカウントに送ったメッセージは取り消せません。

すでに送ったメールをもう一度送るには？

Outlookなら、上記の送信済みメッセージの操作を使います。アプリでは、元のイベントのリトライなのか、意図した新規送信なのかを判断します。保護期間内にResendの同じ冪等性キーを再利用すると、重複送信が防止されます。

送信済みメールを取得できますか？

Resendのメッセージを調べたいなら、保存期間内にEmailsページとメッセージ詳細を開きます。受信者の手元から削除したいという意味なら、自分の記録の閲覧や削除は、メールボックスでの送信取り消しとは別の操作です。

送ったメールはどこで確認できますか？

ResendのEmailsダッシュボードには、SMTPでの送信を含め、送信済みと予約済みのメッセージが表示されます。メッセージを開くと、メタデータ、プレビュー、HTML、プレーンテキスト、配信イベントを確認できます。

送ったメールが見つからないのはなぜですか？

Resendなら、送信が受理されたか、データがまだ保存期間内かを確認します。Outlookなら、正しい「送信済みアイテム」フォルダーと保存設定を確認しましょう。Microsoftの送信済みメールのガイドでは、送信済みのコピーが見つからない理由を説明しています。

送信済みメッセージを復元するには？

まず、メールボックス内のコピーがないのか、配信サービスのログが期限切れなのかを区別します。Resendの保存期間を過ぎた調査には、自分たちで保存したイベント履歴を使います。ダッシュボードを恒久的な保存先と見なしたサポート運用は避けましょう。

**AI Business Workflow Audit Checklist（AI業務ワークフロー監査チェックリスト）**を使い、メールの各トリガー、失敗、復旧手順に担当者を割り当てましょう。ニュースレターからチェックリストを入手できます。