SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Resendでメールが届かないとき、最初の30分でやること

Resendで送ったはずのメールが届かないときに、最初の30分で「送信失敗/到達失敗/見落とし」を切り分けて止血する手順です。

著者: 川原更新: 2026-05-15障害対応RSS
Xで共有FacebookLinkedIn
料金相談

Resendで「送ったはずのメールが届かない」問題の最初の30分は、(1)そもそも送信APIが成功していない、(2)送信は成功したが到達していない（バウンス/拒否/迷惑メール）、(3)到達しているが見落としている（受信ルール/転送/別受信箱）の3つに分けて“原因の場所”を固定することです。

この手順は、日次ブリーフ・問い合わせ通知・アラートなど「届かないと売上/対応が止まる系」のメール全般に使えます。

0. まずやらないこと

  • いきなりDNS（SPF/DKIM/DMARC）を闇雲に触る（変更は影響が大きい）
  • いきなり配信内容を変える（本文は原因になりにくい）
  • いきなり送信元ドメインを変える（レピュテーション/設定がズレやすい）

1. 症状を1行で固定（3分）

次のどれかを選び、まず「何が、どこに、いつから届かないか」を固定します。

  • すべて届かない（昨日まで届いていたのに今日からゼロ）
  • 一部だけ届かない（特定の宛先ドメイン/特定の受信箱だけ）
  • 遅延して届く（数分〜数十分遅れている）

ここが曖昧だと、以降の確認が全部ブレます。

2. 送信APIの“成功/失敗”を最速で確定（7分）

最初にやるべきは「アプリ側で送信が成功しているか」を確定することです。

  • アプリの送信ログにエラーが残っていないか（タイムアウト/レート制限/認証）
  • to / from / subject が空になっていないか（環境変数の欠落）
  • 送信リクエストが発生しているか（例: 日次ジョブ/フォーム送信の実行ログ）

ここで失敗が見えるなら、最初の止血は「必ず送信が成功する状態に戻す」ことです。DNSや受信側の調査は後回しにします。

3. “送信は成功した”のに届かない場合の切り分け（10分）

送信処理が成功しているのに届かない場合、原因はだいたい次のどれかです。

  1. バウンス/拒否が増えている（宛先が無効、受信側の拒否、送信元評価の低下）
  2. 迷惑メール/別タブに入っている（プロモーション/通知/迷惑メール）
  3. 転送/ルール/フィルタで見えなくなっている（転送先の変更、フィルタで自動処理）

この分類ができるだけで、次の1時間で触る場所が固定できます。

4. “バウンス/拒否”が濃厚なときの最短チェック（5分）

このケースは「送信ドメイン認証」か「受信側の拒否」かを最短で見ます。

  • 送信ドメイン認証（SPF/DKIM/DMARC）が崩れていないか（DNS変更/移管/レコード消失）
  • 送信元（From）が意図したドメイン/アドレスになっているか（環境差分でズレやすい）
  • “同じ宛先”だけ失敗していないか（宛先入力ミス/無効化/容量）

止血としては、まず「別の宛先へ同報」して取りこぼしを止めます（例: 個人メール＋チーム共有受信箱）。

5. “迷惑メール/見落とし”が濃厚なときの最短チェック（5分）

届いているのに気づけていないケースも多いです。

  • 迷惑メール/プロモーション/通知タブに入っていないか
  • 受信ルールでアーカイブ/削除/別フォルダ移動されていないか
  • 転送（Email Routing）で別アドレスに流れていないか（運用変更の影響）

この確認だけで復旧することもあります。

6. 最初の30分で出す“結論”の型

最初の30分で、次のどれかに分類して次の作業を固定します。

  1. 送信APIが失敗: 認証/レート/設定ミス。まず“成功率”を戻す。
  2. 送信は成功したが到達しない: 認証（SPF/DKIM/DMARC）/拒否/宛先問題。まず同報で止血。
  3. 到達しているが見落とす: 受信ルール/転送/迷惑メール。まず受信箱の可視性を戻す。

この分類ができれば、ムダなDNS変更や作り直しを避けられます。

SiteOpsでの再発防止（相談/料金導線）

通知が止まると、売上や対応が止まります。SiteOpsなら、複数サイトの「通知が止まった/減った」兆候を毎日まとめて確認でき、原因のあたり（送信・到達・見落とし）を早く固定できます。

  • まずは /dashboard で「通知/問い合わせ/収益の止まり」に近い変化を確認
  • 必要なら /#pricing から運用の自動化/監視を検討
  • 個別相談は /contact へ（今の構成と症状だけでOK）

関連

  • /media/contact-form-not-received-first-30-minutes
  • /media/cloudflare-1102-503-first-response

参考にした一次情報

  • RFC 7208: Sender Policy Framework (SPF)
  • RFC 6376: DomainKeys Identified Mail (DKIM)
  • RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事お問い合わせフォームの通知が来ないとき、最初の30分でやること次の記事Stripe Webhookの署名検証に失敗するとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ