問い合わせフォームのメールが届かない原因には、宛先の誤り、フォームの送信処理の失敗、送信認証の不一致、受信側の迷惑メール判定などがあります。「送信しました」という画面が出ても、受信箱へ届いたとは限りません。

フォームに受付履歴があれば、内容を回収しながら通知経路を調べられます。まず保存記録と受信側の迷惑メール・隔離を見て、その後に送信設定を確認する流れです。調査中に連絡を受けられない場合は、電話など代わりの窓口を案内します。

最初に問い合わせ内容が保存されているかを見る

受付内容が残っているかは、未対応の問い合わせを回収するうえでも重要です。フォームプラグインや外部フォームサービスに送信履歴が残っていれば、利用者の入力は受け付けられています。通知メールの経路に絞って調査できます。

保存機能が有効なフォームで履歴がなければ、フォーム自体が処理を完了していない可能性があります。もともと履歴を保存しないフォームとは分けて考えます。必須項目の判定とJavaScriptエラーを確認します。迷惑投稿対策とサーバー側のエラーログも対象です。送信完了画面へ移動したかだけで判断せず、管理側の記録と一件ずつ照合してください。

送信内容を保存していないフォームでは、この時点で受付の成否を証明できません。今後の取りこぼしを防ぐには保存機能も役立ちます。ただし個人情報の保存先が増えるため、閲覧権限や保管期間を含めて選ぶ必要があります。

WordPressから送信処理へ渡ったかを確認する

WordPressのフォームは、多くの場合 wp_mail() を通じてメール送信処理を呼び出します。WordPress公式リファレンスにも、関数が成功を返しても受信者へ届いたことを意味しないと明記されています。成功表示は、次の送信処理へ渡せたという一つの記録として扱います。

フォームの送信先アドレスに入力ミスがないかを確認します。通知先を複数設定している場合は、一時的に同じ会社の別アドレスと外部サービスのアドレスへ一通ずつ送ります。片方だけ届けば、フォームより受信側の設定を疑いやすくなります。

この段階でプラグインをすべて更新したり、SMTPプラグインを追加したりしません。複数の変更を同時に行うと、届くようになっても原因が分からなくなります。現在の設定を保存し、一つの変更ごとに同じテスト内容を送ります。

FromとReply-Toを混同しない

送信元の From へ、利用者が入力したGmailなどのアドレスをそのまま設定しているフォームがあります。この設定では、自社サーバーが他社ドメインの差出人を名乗る形になります。受信側からなりすましを疑われやすく、メール認証とも整合しません。

Fromには、利用する送信サービスで認証・送信を許可された自社ドメインなどのアドレスを使います。利用者のアドレスは Reply-To へ設定すれば、担当者が返信操作をしたときに問い合わせた人へ返せます。表示上の分かりやすさと、送信経路の正当性を分けて設定することが大切です。

自社ドメインでも、実際に送信を担当するサービスがDNSのSPFへ含まれていなければ認証に失敗する場合があります。フォームをサーバーから送るのか、外部のメール配信サービスから送るのかを決め、その経路をDNS設定と一致させます。

送信サーバーとDNS認証を確認する

サーバーのメールログを確認できる場合は、テスト送信の時刻と宛先で記録を探します。送信を受け付けたのか、接続に失敗したのか、相手サーバーから拒否されたのかで次の確認先が変わります。ログを確認できない契約では、サーバー会社へ時刻と宛先を伝えて調査範囲を尋ねます。

Gmailの送信者向けガイドラインでは、すべての送信者にSPFまたはDKIMによる認証を求めています。安定した配信にはSPFとDKIMを設定します。DMARCも加え、From のドメインと認証に使うドメインを揃えます。

SPFは送信に使うすべてのサービスを一つのレコードへまとめます。WebサーバーとMicrosoft 365の両方から同じドメインで送る会社では、片方だけを書かないようにします。SPFレコードを二つ作るのではなく、現在の送信経路を整理して一つに統合します。

SMTPプラグインは、WordPressから認証済みの送信サービスを使う手段です。ただし、追加すれば自動的に直るわけではありません。送信アカウントと認証方式を管理できる場合に採用します。送信上限と障害時の確認場所も必要です。

受信側の隔離と転送を調べる

送信側のログに配送完了が残っていても、受信箱へ表示されないことがあります。迷惑メールフォルダーだけでなく、管理者の隔離領域とメールフロールールを確認します。共有メールボックスや転送を使っている場合は、転送元と転送先のどちらで止まったかを分けます。

件名や本文を変えたテストも有効です。URLが多い本文や同じ内容の連続送信は、迷惑メール判定へ影響する場合があります。ただし、テストで届く短い文へ変えるだけでは本番の解決になりません。通常の問い合わせ内容に近い条件へ戻し、再現しないことまで確認します。

受信拒否や隔離の理由が管理画面へ残るサービスでは、判定名と時刻を記録します。「迷惑メールに入っていた」で終わらせず、送信認証の失敗なのか社内ルールなのかを特定すると、恒久対応を選べます。

修正後は通知と自動返信の両方を確認する

修正後はテスト内容でフォームを送り、管理者への通知と、利用している場合は自動返信も確認します。実際の顧客データを外部のテスト用アドレスへ転送するのは避けます。

通知は届くのに自動返信だけ届かないなら、差出人や宛先など、そのメール固有の設定が手掛かりになります。特定のメールサービスだけ届かない場合は、認証結果や隔離理由も関係します。

SMTPプラグインを追加すれば必ず解決するわけではありません。フォームで受け付けられたか、送信サーバーが送れたか、受信先がどう扱ったかに分けると、直す場所が見つかりやすくなります。