はじめに： “Sent” と “Received” の間には、思った以上に多くの扉がある
プロダクトを運用していると、必ず一度は遭遇します。「送信は成功しているはずなのに、ユーザーに届かない」という報告。ダッシュボード上は Sent、ステータスもエラーなし。なのにユーザーの受信箱には何もない。サポートは困り、開発は焦り、PMは数字の落ち込みに胃が痛い。メールは“目に見えない配送”なので、問題の場所が直感しづらいのが厄介です。
この状況を解く鍵は、メールを「1つのAPI呼び出し」ではなく、複数段階のパイプラインとして捉えることです。送信（アプリ）→ キュー（MTA/ESP）→ ルーティング（DNS）→ 受信側の検疫（スパム判定）→ 受信箱（Inbox）という流れのどこで落ちたのかを、プロダクトチームが迷わず切り分けられるように、本稿では実務ベースのデバッグ手順をまとめます。
まず揃えるべき“共通言語”：一件のメールを特定する
デバッグを始める前に、関係者が同じメールを見ている状態を作ります。ここが曖昧だと、別のメールを追いかけて時間が溶けます。最低限、次の情報をチケットにまとめてください。
- 受信者アドレス（可能ならドメインも明記）
- 送信日時（タイムゾーン込み）
- 件名（テンプレIDがあればそれも）
- メッセージID（アプリ側で採番しているトラッキングIDでも可）
- 送信元ドメイン（From/Return-Path が分かれば理想）
- 送信カテゴリ（認証、通知、請求、マーケ等）
特に重要なのは、MTA/ESPが発行する Message-ID や内部の event_id です。ここが取れると、後続のログ探索が一気に早くなります。
“送ったのに届かない”を3つの現象に分解する
ユーザーの言う「届かない」は、実は3種類に分かれます。最初に分類できると、確認範囲が絞れます。
- A：配信は失敗している（バウンス）…実は相手に拒否されている
- B：配信は成功だが、受信箱に入っていない…迷惑メール/プロモーション/隔離へ
- C：遅延している…数分〜数時間後に届く（ピーク時に多い）
この分類は「受信者側の画面」だけでは判断しにくいので、こちら側のイベントログで根拠を取りに行くのがポイントです。
ステップ1：アプリ側で “送信要求” が正しく出ているか
まず、メール送信をトリガーしたイベントが本当に起きているかを確認します。たとえば「パスワード再設定」では、UIでボタンを押した瞬間にAPIを呼び、ジョブを積み、メール送信ワーカーが拾う、という段階があります。ここが欠けていると、ESPには一切届きません。
- ユーザー操作 → APIリクエストの有無（ステータスコード、レスポンス）
- DBに送信ジョブ/イベントが保存されているか（重複防止の抑止条件も見る）
- キュー投入が成功しているか（enqueue失敗、トランザクションロールバック）
- ワーカーが処理したログ（テンプレ生成、宛先、From、Reply-To）
ここでありがちな落とし穴が、レート制限や二重送信防止です。「同じユーザーに5分以内は再送しない」などのガードが働いているのに、画面上は「送信しました」と出してしまう。プロダクトとしては、ユーザーに期待値を誤って伝えてしまうので、UI文言とロジックの整合性を点検する価値があります。
ステップ2：ESP/MTAで “Accepted” まで到達しているか
次に、送信基盤（自前MTAでも、SendGrid/Mailgun/SESなどのESPでも）で、そのメールが Accepted されたかを確認します。ここで重要なのは、アプリが「送信APIを叩けた」ことと、MTAが「相手に配送を試みる」ことは別、という点です。
- ESPのイベントログで processed / queued / accepted があるか
- 失敗ならエラーコード（無効アドレス、認証不備、ポリシーブロックなど）
- 送信IP/ドメインの紐づけが正しいか（サブアカウント誤設定も多い）
もしESPにログが存在しないなら、アプリ→ESP間で落ちています。逆にESPにログがあるなら、以降は「相手側へ配送されたか」「相手側でどう扱われたか」の切り分けに進めます。
ステップ3：バウンス（Bounce）と苦情（Complaint）を最優先で見る
「届かない」の多くは、実はバウンスです。ユーザーはバウンス通知を見ないので、プロダクト側が拾う必要があります。バウンスは大きく2種類。
- Hard Bounce：宛先が存在しない、ドメインが無効など恒久的な失敗
- Soft Bounce：一時的（受信箱容量超過、受信側が一時拒否、グレーリスト等）
さらに、受信側が「迷惑メール」として通報した場合の Complaint も重要です。苦情が増えると、同じドメインからの配信全体が届きにくくなります。プロダクトチーム視点では、単発事故ではなく、配信品質の悪化として扱うべき指標です。
ステップ4：SPF/DKIM/DMARC を “実際に届いたヘッダ” で検証する
メール認証は設定したつもりでも、実際の送信経路やReturn-Pathが違うと失敗します。理想は、テスト受信箱（Gmail/Outlook/Yahooなど）に届いたメールのヘッダを取得し、次を確認することです。
- SPF：送信IPが許可されているか（Return-Pathドメインが一致しているか）
- DKIM：署名が付与され、検証に成功しているか（selector、ドメイン一致）
- DMARC：FromドメインとSPF/DKIMの整合（アライメント）が取れているか
「送ったのに届かない」案件で多いのが、Fromは自社ドメインなのに、実際の送信は別ドメイン経由（Return-PathがESPデフォルト）で、DMARCアライメントが崩れているケースです。設定画面上は“認証済み”でも、テンプレやサブドメインの使い分けで失敗することがあるため、現物ヘッダの確認が強いです。
ステップ5：受信側の “フォルダ振り分け” と “隔離” を前提に観測する
配送が成功していても、受信箱に見えないことがあります。日本のユーザーは特に「受信箱にない＝届いてない」と認識しがちなので、ここはサポート導線としても重要です。
- 迷惑メールフォルダ、プロモーションタブ、通知タブ
- 携帯キャリアメールの自動ブロック（特に厳しい場合がある）
- 企業メールのセキュリティゲートウェイで隔離
この段階で有効なのが、受信側が返す Delivery（配達完了）イベントや、ESPが持つ「受信側応答」の詳細です。可能なら、受信者に「迷惑メールに入っていないか」だけでなく、検索で件名や送信元を探す、フィルタ/ルール設定を確認など、より具体的な案内にすると解決率が上がります。
ステップ6：遅延（Delay）の典型パターンを押さえる
遅延は地味ですが、数字に効きます。認証メールが10分遅れただけで、サインアップ完了率がガクッと落ちる。遅延は「直ったように見えて、再発しやすい」ので、原因ごとに対処を持っておくと強いです。
- 送信キューの詰まり：ワーカー数不足、DB/Redisの遅延、再試行嵐
- 受信側のグレーリスト：初回送信は一時拒否→再送で通る
- ISP側のスロットリング：大量送信時に一時的に抑えられる
対策としては、ワーカーのスケール、送信レート制御、優先度キュー（認証メールを最優先）、リトライ間隔の最適化などが有効です。プロダクトチームは「どのメールが遅れると致命的か」を先に決めておくと、施策の優先順位が取りやすくなります。
ステップ7：抑止リスト（Suppression）とブラックリストを疑う
“送信しているのに特定のユーザーだけ届かない”とき、まず疑うべきが抑止リストです。過去にバウンスしたアドレスは、ESPが自動的に送信停止（抑止）することがあります。安全のための機能ですが、正しく把握していないと「送信したつもり」になる。
- ESPの suppression/bounce list に対象アドレスが入っていないか
- 解除フローがあるか（サポート対応手順として整備）
- 手動で抑止した記録（オペレーションミス）
また、ドメインやIPがブラックリストに載っていると、届きづらくなります。ここは運用チームやインフラと連携し、配信ドメインの分離（トランザクション用とマーケ用を分ける）や、送信レピュテーションの管理が重要になります。
プロダクトチームが用意しておくべき “観測点”
メール未達が起きたとき、毎回ログを掘っていては間に合いません。平時から「観測できる状態」を作るのが、結果的に最もコストを下げます。
- メール送信イベントのトレーシングID（アプリ→ESPまで一貫）
- 送信カテゴリ別のダッシュボード（認証/通知/請求など）
- バウンス率・苦情率・遅延率のアラート
- 抑止リストの検索/解除を安全に行う運用手順
- ユーザー向けヘルプ導線（迷惑メール確認、再送、別メール変更）
特に、認証メールはプロダクトの入口なので、到達率をKPIとして扱う価値があります。「未達はサポート案件」ではなく、「コンバージョンに直結する品質課題」として見たほうが、優先順位が上がりやすいです。
現場で効く“チェックリスト”：最短で切り分ける順番
実際のトリアージでは、次の順番がスムーズです。迷ったらこの流れに戻すと、チーム内の会話も揃います。
- 対象メールを特定（受信者・時刻・Message-ID）
- アプリ側：送信ジョブは作られたか、ワーカーは処理したか
- ESP側：accepted/queued があるか
- bounce/complaint/suppression を確認
- delivery か、spam/quarantine か、delay かを判定
- 認証（SPF/DKIM/DMARC）をヘッダで確認
- 恒久対策（観測・UX・運用）へ落とし込む
小さなストーリー： “届かない” の正体が、実はUIだった話
ある日、サインアップが伸び悩み、サポートに「認証メールが届かない」という問い合わせが増えました。ログを見ると、確かにESPは delivery を返している。バウンスも少ない。認証設定も問題ない。それでもユーザーは「届かない」と言う。
原因は意外なところにありました。モバイルのメールアプリで、プロモーションタブに入ったメールが表示されにくい設定になっており、さらにアプリ側の案内文が「受信箱をご確認ください」だけだった。ユーザーは迷惑メールや他タブを見ず、詰まって離脱していたのです。
対策は2つ。1つは、画面の案内を「迷惑メール、プロモーション、通知タブも確認」に変えること。もう1つは、認証メールの件名とプリヘッダを調整して、分類されにくくすること。結果、問い合わせは減り、完了率は戻りました。メールの問題は技術だけでなく、ユーザー体験の設計にも潜んでいます。
まとめ： “届かない” は、パイプライン全体の品質課題
「Sent but Not Received」は、メール配信に関わる全チームがぶつかる定番課題です。プロダクトチームとしては、単発の火消しで終わらせず、観測点を整え、UXを改善し、運用手順を整備して、再発コストを下げるのが理想です。
まずは、対象メールの特定と、ESPログでの accepted/bounce/suppression の確認。この“基本動作”が固まるだけで、対応スピードと精度は大きく上がります。メールは地味ですが、入口も継続も支えるインフラです。だからこそ、丁寧に、しかし淡々と。切り分けの型をチームに持ちましょう。