2026年のResend Webhookテスト方法：テストメールで配信・バウンス・苦情イベントを検証

結論：Resendのテスト用宛先で送達・バウンス・苦情イベントを発生させ、先にWebhookとアプリの分岐を検証してください。実際にメールが受信箱へ届くことや表示が正しいことまで確かめるには、管理下の実メールアドレスでも別途テストします。

Resend Webhookを組み込む開発者は、イベント受信と署名検証を確認できます。QAエンジニアは結果ごとの処理を再現でき、独立開発者は模擬テストで不足する実受信確認を切り分けられます。

最終更新：2026年10月22日。確認先はResendのテストメール案内、Webhookイベントの可視性に関する更新、Webhookの管理と検証例です。

イベントの種類ごとに、模擬と実受信を分ける

Resendテストメールアドレスの役割は、指定した結果のメールイベントを発生させ、Webhookを通じた自社アプリの処理を確かめることです。公式のテストメール案内では、送達・バウンス・苦情などのイベントを扱えます。利用する宛先や指定方法は、実装時に公式のテストメール情報で確認してください。

一方、模擬イベントは、実際の受信サーバーがメールを受け付けた証明ではありません。送信APIの応答、Webhookで受け取ったイベント、受信箱での到達確認は、それぞれ別の結果として記録します。

この区別をしないと、APIが成功応答を返しただけで「メール送達まで正常」と誤認したり、模擬の送達イベントを実受信の証拠として扱ったりします。送信要求の結果と、イベント処理結果、受信箱での確認結果を別々に保存してください。

送達イベントでは、Webhook到達後の記録を確かめる

送達の模擬イベントを使ったら、Webhookが受信したイベント種別に加え、メールを識別するIDと宛先をアプリ側で関連付けられているか確認します。単に「成功」とだけ記録する実装では、複数のテストメールが同時に動いたとき、どの送信結果を更新したのか追跡できません。

送達分岐で確認する項目

• イベント種別を読み取り、送達状態として扱うこと。
• イベント内のメールIDと宛先を、自社の送信記録に結び付けること。
• 対応する送信記録がないイベントや、想定外の宛先を受け取ったときの扱いを決めておくこと。
• Webhookの受信記録と、ユーザー向けの状態表示を分けて確認すること。

Resendは2026年1月にWebhookイベントの可視性に関する更新を公開しています。イベントの確認方法や表示仕様を前提にした運用では、公式の更新情報も参照し、現在の画面・仕様と実装上のログを照合してください。

バウンスでは、失敗状態と後続処理を検証する

バウンス用のテストシナリオでは、Webhookが失敗イベントを受け取り、対象の送信記録を正しく更新できるか確認します。失敗理由を保存する場合は、イベントから得た値と自社の分類を分けて記録し、元の情報を後から参照できるようにします。

たとえば、アプリが再送を検討する場合でも、すべてのバウンスを同じ条件で再送する設計にしないでください。イベントを受け取っただけで送信先を恒久的に無効化するのも避けます。どの失敗を一時的・恒久的として扱うかは、自社の製品要件とイベント情報に基づいて定義し、テストケースとして残します。

苦情イベントでは、製品側の抑止ルールを確認する

苦情イベントのテストでは、イベントを受信したときに、自社製品で決めた後続処理が動くかを確認します。たとえば、対象ユーザーや配信先の状態が更新され、以後の通知処理がその状態を参照する設計なら、状態更新から次の送信判断まで一続きで検証します。

模擬された苦情は、実際の受信者がメールを迷惑メールとして報告したという意味ではありません。発信元の評価や受信箱への分類を証明するものでもないため、テスト結果を配信品質の結論として扱わないでください。

署名・応答・重複処理を同じWebhookで確かめる

Webhookの検証では、正しいイベントが届くケースだけでなく、不正なリクエストや処理失敗も確認します。ResendのWebhook管理・検証例を参照し、署名シークレットとリクエスト形式を実装に反映してください。

署名検証では、svix-id、svix-timestamp、svix-signatureなどの署名関連ヘッダーと、受信した未加工のリクエスト本文を使います。本文をいったんJSONとして解析し、別の形式に組み立て直してから検証すると、元の本文と一致しない場合があります。フレームワークの本文解析処理が検証前に動く構成になっていないか確認してください。

応答の成功・失敗条件は自社の受信処理に合わせて決め、Resend側の再試行回数や間隔を固定値で仮定しないでください。イベントIDなどを使った冪等性の仕組みを用意し、同じ通知が再処理されても二重の副作用が出ないことを確認します。

まず自社環境で実行する確認手順

1. テスト用Webhookエンドポイントを用意し、受信したイベント種別・メールID・宛先を記録します。
2. Resendの公式案内で現在のテスト用宛先とイベント指定方法を確認します。
3. 送達、バウンス、苦情の各シナリオを個別に実行し、アプリの状態更新を確認します。
4. 正しい署名と無効な署名を使い分け、署名検証がイベント処理より先に行われることを確かめます。
5. 同じイベントを再送するテストを行い、重複処理による二重更新や二重通知がないか確認します。
6. 管理下の実メールアドレスにも送信し、受信箱・迷惑メールフォルダー・本文表示を確認します。

実際の受信箱で、模擬テストの対象外を補う

模擬テストでは、アプリがイベントを受け取った後の処理を繰り返し検証できます。しかし、受信先メールサーバーの判定、本文のレンダリング、リンクや画像の表示は、実際にメールを受け取らないと確認できません。リリース前は、自社で管理する実メールアドレスを使って別枠で確認してください。

テスト用の受信先を分けたい場合は、MsgGoneの一時受信箱を実メール確認の選択肢として使えます。受信した認証メールの内容を確認した後、主メールアドレスへ転送して保管したいケースでは、メール転送の案内も確認できます。いずれもWebhookイベントを発生させる仕組みではないため、Resendの模擬イベントテストの代用にはなりません。

テスト用メールアドレスとWebhooksの用途を混ぜず、イベント処理には模擬シナリオ、実際の到達と表示には管理下の受信先を割り当てれば、テスト結果から言えることを明確にできます。登録や一時的な確認メールの受信先を主メールと分けたいときは、MsgGoneの一時受信箱を使って実投函を確認し、Webhookの検証はResend側のテストイベントで続けてください。

よくある質問