先に要点
Webサイト運用でかなり多いのが、お問い合わせフォームから送信されたはずなのに届かない という相談です。
この手の不具合は、フォームの画面、アプリの処理、送信サービス、受信側の迷惑メール判定まで関係するので、勘で触るとすぐ迷子になります。
この記事では、お問い合わせフォームが届かないときの切り分け手順を、実務で使いやすい順番で整理します。
スパム対策そのものを見たい場合は、問い合わせフォームのスパム対策は何をやるべき？reCAPTCHAだけで十分かを整理 が近いテーマです。
送ったメールが迷惑メールに入りやすい理由を深く見たい場合は、メールが迷惑メールに入りやすいのはなぜ？到達率が下がる原因を整理 もつながりやすいです。
この記事は 2026年4月22日時点で、Google Workspace Admin Help の送信者ガイドラインFAQ、Microsoft Learn の message trace、Laravel の mail ドキュメントを確認しながら整理しています。製品ごとの画面は変わることがありますが、切り分けの順番は共通して使えます。
結論: まずは「送れていない」のか「送ったが届いていない」のかを分ける
一番大事なのはここです。
問い合わせフォーム不達は、次の2系統に分かれます。
- フォーム送信自体が失敗している
- 送信処理は成功したが、相手に届いていない
この2つを混ぜると、調査がぶれます。
たとえば送信ボタンを押してもアプリが例外で落ちているのに、SPF や DKIM を見始めても意味がありません。
逆に、送信サービスでは accepted なのに Gmail 側で迷惑メールへ入っているなら、画面やコードを直しても改善しません。
切り分けはこの順番で見る
現場では、次の順番で見るとかなり安定します。
先に DNS を見るのではなく、画面から順に下流へ掘るイメージです。
手順1: フォーム送信が画面上で成功しているか確認する
最初に見るのは、もっとも手前です。
- 送信ボタンを押したあと完了画面へ遷移するか
- バリデーションエラーが出ていないか
- reCAPTCHA や CSRF エラーが出ていないか
- スマホだけ失敗していないか
- JavaScript エラーで送信が止まっていないか
ここで失敗しているなら、まだメールの問題ではありません。
届かない ではなく 送れていない です。
特にありがちなのは、フロント側の改修後に hidden 項目やトークン周りがずれているケースです。
ブラウザの開発者ツールで送信リクエスト自体が飛んでいるかを見るだけでも、かなり切り分けが進みます。
手順2: アプリログで送信処理まで到達しているかを見る
画面上は完了していても、サーバー側で例外が出ていることがあります。
ここで見るのは、アプリログとジョブの状態です。
Laravel 系のアプリなら、mail 設定のズレ、キュー処理の停止、例外の握り潰しがありがちです。
公式ドキュメントでも mailer や failover mailer の考え方が整理されており、複数送信経路を持つ構成では どの mailer が実際に使われたか を追えるようにしておくと切り分けが楽になります。
手順3: 送信基盤が受け付けたか確認する
ここで初めて、メール基盤側を見ます。
共有レンタルサーバーでも、外部送信サービスでも、見るべきことはだいたい同じです。
- 送信ログに記録があるか
- SMTP 接続が成功しているか
- 送信サービスで accepted / delivered / bounced のどこか
- エラーコードが返っていないか
- 差出人アドレスが許可されたドメインになっているか
外部サービスを使っているなら、管理画面の送信履歴や Webhook イベントがとても重要です。
ここで送信記録が全くなければ、アプリから送信基盤へ渡る前で止まっています。
逆に記録があるなら、次は受信側の扱いを見ます。
手順4: 受信側で迷惑メールや拒否になっていないか確認する
送信サービスで成功していても、相手の受信箱へ入るとは限りません。
よくあるのは次の3つです。
- 迷惑メールフォルダへ入っている
- 受信側サーバーで拒否されている
- 転送設定や社内フィルタで別箱へ流れている
この段階では、受信テストを複数宛先で行うのが有効です。
- Gmail
- Outlook / Microsoft 365
- 独自ドメインメール
1つの宛先だけ届かないのか、全部届かないのかで、見る場所が変わります。
Microsoft 365 を使っている環境なら、Microsoft Learn にある message trace がかなり役立ちます。
管理者権限があれば、メッセージが受信、遅延、拒否、配送済みのどこにいるかを追えます。
手順5: DNS 認証を確認する
ここまで来たら、SPF、DKIM、DMARC を見ます。
この3つは、送れたが届きにくい ときにかなり重要です。
それぞれの違いを先に整理したい場合は、MXレコード・SPF・DKIM・DMARCの違いとは？メールDNS設定の基本を整理 がつながります。
最低限見ること
Google の送信者ガイドラインFAQでも、Gmail 側は SPF / DKIM / DMARC とドメイン整合を重視しています。
特に bulk sender 向け要件として書かれていますが、小規模フォーム通知でも方向性は同じです。
認証が崩れているメールは、迷惑メール扱いや拒否の原因になります。
DNS を疑いやすい典型例
このあたりは、DNS切り替え後に確認すること｜Web・メール・SSLのチェックリスト ともかなり相性がよいです。
よくある原因パターン
1. フォーム送信は成功しているが、管理者通知だけ届かない
この場合は、差出人や通知先アドレスの設計、SMTP 認証、迷惑メール判定を疑います。
フォーム送信内容のDB保存は成功している なら、アプリ側より送信基盤側の可能性が高いです。
2. 一部の宛先だけ届かない
Gmail には届くが独自ドメインへ届かない、またはその逆です。
この場合は、受信側のフィルタ、迷惑メール判定、企業メールのポリシーが絡みやすいです。
3. 移転後から届かない
サーバー移転や DNS 切り替え後なら、MX、SPF、DKIM、DMARC、送信元ホスト、SMTP 認証情報を優先して見ます。
Web が見えていても、メールだけ旧設定のままということは普通にあります。
4. たまに届かない
これが一番やっかいです。
送信量制限、タイムアウト、キュー詰まり、外部送信サービスの一時失敗、受信側のレート制限などが候補になります。
このタイプは、都度のログがないと追えません。
先に入れておくと調査が楽になるもの
不達は起きてから調べるより、起きたときに追えるようにしておく方が大事です。
- フォーム送信履歴の保存
- 送信成功 / 失敗ログ
- メール送信IDの記録
- Webhook での bounce / complaint 受信
- テスト送信先の用意
問い合わせフォームを メール送信だけの機能 と見るより、受付記録と通知の両方を持つ仕組み と見た方が安定します。
まとめ
お問い合わせフォームが届かないときは、DNS から見始めるより、まず 送信できているか と 送信基盤まで到達しているか を分けるのが近道です。
順番としては、フォーム画面、アプリログ、SMTP や送信サービス、迷惑メール判定、SPF / DKIM / DMARC の順で見ると整理しやすいです。
この順番で切れば、画面の不具合なのか、送信設定なのか、受信側の評価なのかがかなり見えやすくなります。
小規模サイトでも、問い合わせフォームは売上や機会損失に直結するので、ログと送信履歴だけは残しておく価値があります。
参考リンク
- Google Workspace Admin Help: Email sender guidelines FAQ
- Google Workspace Admin Help: Email sender guidelines
- Microsoft Learn: Trace an email message in Exchange Online
- Microsoft Learn: New Message trace in Exchange admin center
- Laravel: Mail