目次
「ホームページの問い合わせフォームから送ったのに、返事がない」——お客様からそう言われて初めて、通知メールが届いていなかったと気づく。フォームを持っている会社なら、一度は肝を冷やす場面です。
やっかいなのは、システム側は正常に見えているという点です。フォームは「送信しました」と表示し、サーバーのログにもエラーは出ていない。メール配信サービスのAPIも、正常応答（成功）を返している。それなのに、メールボックスには何も届いていない。
これは、私たち自身のサイトで実際に起きたことです。原因を追ったところ、2つの問題が重なっていました。どちらも、コードを何時間眺めても見つからない種類のものでした。
何が起きていたか
症状は単純です。フォーム送信は成功する。送信処理を担うメール配信サービスのAPIも成功を返す。しかし受信側には届かない。
コードのバグを疑ってデバッグを始めたくなる場面ですが、結論から言えば、コードは正しく動いていました。原因は、コードの外側にありました。
原因1：サプレッションリストに載っていた
メール配信サービスには、サプレッションリスト（自動送信停止リスト）という仕組みがあります。過去に一度でもバウンス（宛先不明などによる不達）が発生したアドレスを自動的に登録し、以降はそのアドレスへの送信をサービス側で止める、というものです。
問題は、止め方です。APIは成功を返したまま、実際の送信だけがサイレントに止まる。エラーにならないので、送信側からは「正常に送れた」ようにしか見えません。
これは不具合ではなく、仕様として正しい挙動です。不達が続くアドレスに送り続けると、送信元ドメインの評価（送信レピュテーション）が下がり、他の正常な宛先にまで届かなくなるからです。配信サービスは、利用者全体の到達率を守るためにブレーキを踏んでいる。理屈は分かるのですが、知らなければ確実に踏み抜きます。
原因2：受信側のグループ設定で弾かれていた
もう一つは受信側です。通知の宛先にしていたGoogleグループが、外部からの投稿を許可しない設定になっていました。配信サービスから見れば「送った」、グループから見れば「外部なので受け取らない」。どちらも自分の役割としては正しく動いています。
この2つが重なっていたため、片方を直しても症状が消えず、調査が長引きました。
「APIが成功＝届いた」ではない
今回の教訓を一言にすると、これに尽きます。
メール送信は、送信側・配信サービス・受信側という複数の主体をまたぐ処理です。APIの成功が保証しているのは、あくまで「配信サービスがリクエストを受理した」ところまで。その先で止まっているかどうかは、別の場所を見ないと分かりません。
APIの成功はBまで。CとDで止まっても、送信側のログには何も残りません。
調査の順序：コードより先にダッシュボード
不達の相談を受けたとき、私たちがまず見る場所は、コードではなく配信サービスのダッシュボードです。配信ログとサプレッション状況を確認すれば、どこで止まっているかが数分で切り分けられます。
| 確認する場所 | 分かること | 対応 |
|---|---|---|
| 配信サービスの配信ログ | 送信を試みたか／止めたか | 記録がなければ設定・認証を疑う |
| サプレッションリスト | 宛先が停止対象か | 原因を確認してから解除 |
| 受信側の受け取り設定 | 外部からの受信を許可しているか | グループ・転送・フィルタを確認 |
| 迷惑メールフォルダ | 届いた上で振り分けられたか | 送信ドメイン認証の設定を見直す |
| アプリケーションのコード | 送信処理そのものの誤り | 上記で原因が出ない場合に着手 |
順序が大事です。コードのデバッグから始めると、正しく動いているものを何時間も眺めることになります。外側から内側へ——配信ログ、サプレッション、受信側設定、最後にコード。この順で見るだけで、調査時間は大きく変わります。
なお、サプレッションの扱いや解除手順は配信サービスごとに異なり、仕様も変わります。最新の内容は必ず公式ドキュメントで確認してください。
運用に組み込んでおくこと
一度直して終わり、にはできません。バウンスは今後も発生しますし、そのたびに同じ状態が再現します。仕組みとして持っておくべきものは3つです。
- 定期確認：配信ログとサプレッションリストを、月次などの決まったタイミングで目視する。件数が少ないうちは、これだけでも十分に効きます。
- 解除手順を文書化：登録された宛先をどう確認し、どう解除するか。担当者が変わっても再現できるように、手順を残しておきます。原因を確かめずに解除だけすると、また同じ不達を繰り返す点にも注意します。
- 到達を監視：重要な通知は、送りっぱなしにしない。自社宛のテスト送信を定期的に流す、あるいは問い合わせ通知が一定期間ゼロなら気づける仕組みを用意しておく——「届いていないことに気づけない」状態を作らないのが要点です。
問い合わせフォームは、壊れても誰も文句を言わない設備です。お客様は「返事が来ない会社だ」と思って離れるだけで、こちらには何の通知も届きません。機会損失が静かに積み上がるという意味で、優先度を上げて見ておく価値があります。
まとめ
- フォームの不達は、APIが成功を返していても起こる
- 実案件（自社サイト）では、サプレッションリストによる自動停止と受信側グループの外部投稿拒否が重なっていた
- バウンス時の自動停止は、送信レピュテーションを守るための正しい仕様。仕様は変わるため、最新は各配信サービスの公式ドキュメントで確認する
- 調査の順序は配信ログ → サプレッション → 受信側設定 → コード。外側から内側へ
- 解除手順の文書化と定期確認を、運用として組み込んでおく
RENOYでは、システムの開発だけでなく、こうした「動いているように見えて止まっている」箇所を洗い出す運用設計まで含めて支援しています。「うちのフォーム、ちゃんと届いているか不安」という段階のご相談も歓迎です。まずはお気軽に無料個別相談（オンライン・60分）をご利用ください。サービス内容をまとめた資料は資料請求からご覧いただけます。