問い合わせフォームのメールが届かない原因と確認方法

問い合わせフォームのメールが届かないときは、フォームを何度も送る前に、どの段階まで処理が進んだかを確認します。画面に「送信しました」と表示されても、通知メールが受信箱へ届いたことまでは証明できません。

フォームからWordPressへ処理が渡る順番を追います。その後に送信サーバーと受信側を分ければ、原因のない場所へ設定を追加せずに済みます。問い合わせを失っている可能性がある間は、電話など別の連絡手段もサイトへ表示しておきます。

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

最優先で確認するのは、メールではなく問い合わせ内容の記録です。フォームプラグインや外部フォームサービスに送信履歴が残っていれば、利用者の入力は受け付けられています。通知メールの経路に絞って調査できます。

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

送信内容を保存していないフォームでは、この時点で受付の成否を証明できません。すぐに保存機能を追加するのではなく、保存する個人情報と保管期間を決めます。閲覧権限と削除方法も合わせて設計し、必要以上の情報を残さない運用にします。

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

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

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

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

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

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

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

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

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

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

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

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

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

修正後は、最初に使ったフォームと入力内容で再送します。管理側の送信履歴、送信サーバーの記録、受信時刻を一件のテストIDで結びつけます。担当者への通知だけでなく、自動返信を使っている場合は利用者側へのメールも確認してください。

復旧の完了条件は、メールが一度届くことだけではありません。送信内容を後から確認でき、失敗したときに担当者が気づける状態まで含みます。月に一度など実際に続けられる間隔でテストし、フォームやDNSを変更した後は臨時確認を行います。

送信日時とテストした宛先を作業記録へ残します。変更箇所と確認したログも必要です。次に届かなくなったときは、その記録と現在の状態を比較できます。原因を経路ごとに切り分ける運用が、問い合わせを見失わないための対策になります。