お問い合わせフォームが届かない原因と今すぐできるCHECK10項目

60秒セルフ診断

まずは、今のあなたの症状に近いものを下記 1〜6 のどれかに当てはまれば、番号に対応するリンク（CHECK）を確認してください。複数当てはまる場合は、上の番号から順に確認してください。

フォーム不達で頻出する原因10項目（CHECK10項目）

CHECK 1迷惑メールフォルダと受信ルール

症状お問い合わせを送信した本人は「確かに送った」と認識しているのに、受信者側の受信トレイには通知メールが見当たらず、対応が止まってしまう状態です。原因受信側のメールサービスが送信メールを迷惑メールとして判定したり、既存の受信ルールによって別フォルダへ自動振り分けしていたりするケースが多く発生します。確認まず受信者本人が迷惑メールフォルダとプロモーションタブを確認し、そのうえで送信元ドメイン名で全文検索し、最後に受信ルール・フィルタ設定で自動仕分け条件を点検してください。

CHECK 2管理者宛メールアドレスの入力ミス

症状送信者には自動返信メールが正常に届いているにもかかわらず、運営側の担当者には管理者通知だけが届かず、問い合わせに気づけない状態になります。原因フォーム設定内の通知先アドレスに誤字や余分な空白が含まれていたり、異動・退職後の古いメールアドレスが残っていたりする設定ミスが主因です。確認管理画面の通知先アドレスを一文字ずつ見直して再入力し、可能であれば予備アドレスを含む複数宛先でテスト送信して、どの宛先まで到達しているかを比較確認してください。

CHECK 3SPF・DKIM・DMARCの不整合

症状Gmail には届くのに企業ドメインには届かない、あるいは特定の取引先だけ未達になるなど、宛先ドメインごとに到達可否が分かれる状態です。原因送信元ドメイン認証（SPF・DKIM・DMARC）が不十分、または送信サービス設定とDNS公開情報に不整合があり、受信側ポリシーで拒否されることが原因です。確認ドメイン管理側のDNSレコード内容と実際の送信サービス設定を突き合わせ、SPFのinclude・DKIM鍵・DMARCポリシーが現行運用と一致しているかを順番に検証してください。

CHECK 4サーバー側の送信制限

症状日中の特定時間やアクセス集中タイミングだけ通知が遅延・未達になり、時間を置くと届くという不安定な挙動が繰り返されます。原因サーバー側の同時送信数制限に達していたり、メールキューが詰まって配送処理が滞留していたりして、即時配信できない状態になっている可能性があります。確認契約サーバーの送信上限値と現在の利用状況を確認し、あわせてメールキュー・配送ログ・エラーログを時刻単位で照合して、遅延が発生する時間帯の共通点を特定してください。

CHECK 5SMTP設定の誤り

症状画面上では「送信完了」と表示されるため利用者は送れたと思っているのに、実際の受信側にはまったく届いていない状態が発生します。原因SMTPホスト名、ポート番号、認証ユーザー、パスワード、暗号化方式（TLS/SSL）のいずれかが一致しておらず、裏側のメール接続が確立できていないことが主な原因です。確認フォーム実装のSMTP設定値をメールサービス提供元の公式設定と一項目ずつ再照合し、TLS/SSLとポートの組み合わせを揃えたうえで再テストして接続ログを確認してください。

CHECK 6バリデーションやJavaScriptエラー

症状利用者が送信ボタンを押しても画面遷移しない、読み込み表示だけ続く、端末によって成功率が異なるなど、操作結果が分かりづらい状態になります。原因必須項目バリデーションの想定漏れ、JavaScript実行エラー、外部ライブラリ競合などにより、送信処理の途中でクライアント側が停止している可能性があります。確認ブラウザ開発者ツールのコンソールエラーを確認し、PC・スマホ・主要ブラウザで同条件テストを行い、入力値の違いによって失敗条件が変わるかを比較して切り分けてください。

CHECK 7reCAPTCHA検証エラー

症状reCAPTCHAを導入して以降、以前は通っていた問い合わせ送信が通らなくなり、体感的に送信率が下がったと感じる状態です。原因サイトキーとシークレットキーの組み合わせ不一致、トークン有効期限切れ、サーバー側検証APIエラーなどにより、正当な送信まで拒否されていることがあります。確認フロントエンドに設定したサイトキーとサーバー側シークレットキーが同一プロジェクトのものか確認し、検証レスポンスログを記録して失敗コードの内容を特定してください。

CHECK 8PHPエラー・サーバーログ未確認

症状入力確認や完了画面は表示されるため一見正常に見えるのに、メール送信処理だけが実行されず通知が届かない状態が続きます。原因PHPの warning や fatal error がバックグラウンドで発生し、メール送信関数に到達する前に処理が停止しているケースが多く、画面上では異常が見えにくいのが特徴です。確認サーバーのPHPエラーログを有効化し、送信処理の直前・直後にアプリログを挿入して、どの行で処理が途切れているかを時系列で比較確認してください。

CHECK 9受信側（Gmail/Outlook/企業ドメイン）の拒否条件

症状同じフォームから送ったはずなのに、ある担当者には届き、別の担当者には届かないという宛先依存の未達が発生し、運用判断が難しくなります。原因受信側（Gmail・Outlook・企業メールゲートウェイ）の独自ポリシーによって、件名表現、本文内URL数、差出人情報の整合性が評価され、スコア次第で拒否・隔離されるためです。確認件名や本文の表現を過度に宣伝調にしないよう調整し、URL数・差出人名・Reply-To を見直したうえで、複数ドメイン宛に再テストして到達率を比較してください。

CHECK 10テスト手順が毎回異なる

症状現場から「たまに届かない」という報告はあるものの、担当者が確認すると再現せず、原因特定が長期化してしまう状態です。原因毎回テストする端末・ブラウザ・入力内容・通信環境・実施時刻がばらばらで、比較できる検証データが蓄積されていないことが根本原因になります。確認テスト条件を固定したチェックシートを作成し、端末・OS・ブラウザ・時刻・入力値・送信結果を必ず記録して、定例テストとして同手順で継続実施してください。

関連リンク: 修正可能範囲 / ご料金 / 無料お見積もり / お問い合わせ

再発防止の運用ルール

不達の再発を防ぐために、下記4項目を月次の運用チェックとして順番に確認してください。担当者が変わっても同じ品質で点検できるよう、実施記録を残す運用がおすすめです。

• 毎月1回の実送信テストを実施する
• フォーム改修時は事前・事後テストを固定手順で行う
• 送信ログを3か月以上保管する
• 障害発生時の連絡先と復旧手順を1枚にまとめる

まとめ

フォーム不達は、初動での確認順序が重要です。まずは本記事の10項目を上から確認し、再発防止まで仕組み化してください。原因切り分けが難しい場合は、症状と発生時刻を添えてご相談ください。