問い合わせフォームは「送信済み」なのに、メールが届かないのはなぜ？

「送信しました」や「ありがとうございます」という表示だけでは、問い合わせが宛先の受信トレイに届いたとは限りません。ウェブサイトがフォームの送信を受け付け、すぐにエラーを返さなかったことだけを示している場合があります。

安全に調べるには、管理したテスト送信を1件だけ行い、次の4段階で記録をたどります。ウェブサイトやフォームの記録、送信元または送信サービス、宛先のメールサーバー、受信メールボックスです。確認できない最初の段階を調べ、そこでログを有効にするか、証拠で失敗が確認できた場合に修正します。手当たり次第にプラグインやDNSを変更すると、元の問題が見えにくくなり、新たな問題を招くことがあります。

「送信済み」の表示で何が確認できる？

問い合わせフォームのメッセージは、いくつかの段階を経て届きます。

• フォームでの受付: ウェブサイトが入力内容を受け付け、成功メッセージを表示します。
• 送信元またはサービスでの受付: ウェブサイトがメッセージをローカルのメール処理、SMTPサービス、またはメールAPIに渡し、受け付けまたは送信待ちキューに登録されます。
• 宛先メールサーバーからの応答: 受信側のメールサーバーが、メッセージを受け付けるか、保留するか、拒否します。
• メールボックスへの振り分け: 受信システムが受け付けたメッセージを、ルールに応じて受信トレイ、迷惑メールフォルダー、隔離領域などに配信します。

たとえばWordPressのドキュメントによると、wp_mail()が成功を返しても、意味するのは処理中にエラーがなかったことです。宛先にメールが届いたことまでは確認できません。用語は異なっても、ほかのプラットフォームにも同じ区別が当てはまる場合があります。

問い合わせフォームをどうテストする？

訪問者と同じように、公開中のフォームからテストを1件送信します。以前のメッセージと混同しないよう、ENQUIRY-2026-10-06-1437のような一意の識別番号を付け、本文に記載してください。可能であれば件名や名前欄にも入れます。

送信時刻はタイムゾーンも含めて正確に記録し、ページのURL、フォームに設定されているはずの宛先アドレス、成功メッセージのスクリーンショットも残します。内容は実際の問い合わせに近いものにしつつ、機密情報は含めないでください。短時間に何度もテストを送ると、ログの確認が難しくなったり、送信制限やフィルターにかかったりすることがあります。

次に、識別番号を使って順に確認します。

• 同じ識別番号と時刻の送信記録が、ウェブサイトに残っていますか？
• 送信元や送信サービスに、メッセージを受け付けた、キューに登録した、または失敗した記録がありますか？
• 宛先のメールサーバーは、メッセージを受け付けましたか、保留しましたか、それとも拒否しましたか？
• 受信側のメール管理者は、メッセージ追跡、隔離領域、迷惑メール、メールフロールールから、受け付けたメッセージを見つけられますか？

フォームの送信記録が残っていなければ、フォームの処理段階を調べます。記録はあるのに送信元や送信サービスの記録がなければ、ウェブサイトから送信元への受け渡しを確認します。送信元が受け付けた、またはキューに登録したのに宛先サーバーの応答がなければ、送信元のキューと配信記録を調べます。宛先サーバーが保留または拒否した場合は、推測せず、その応答をもとに対処します。宛先サーバーが受け付けている場合は、フィルタリング、振り分け、隔離、メールボックスのルールを調べます。

技術担当者に依頼したい記録

フォームが「動いています」という一般的な説明ではなく、一意の識別番号と送信時刻に結び付く証拠を依頼しましょう。たとえば、次の記録が役立ちます。

• 保存された送信内容、またはフォームの処理記録
• テスト送信時に設定されていた宛先アドレス
• 送信イベント、キューの記録、または送信サービスのイベント
• メッセージIDまたはプロバイダーのイベントID
• 受け付け、拒否、保留のコードを含む、相手側サーバーからの応答
• バウンス、送信停止、苦情の記録
• 受信メールボックスの追跡結果と、隔離や振り分けの結果

すべての環境で、これらの記録がすべて確認できるとは限りません。ログがないことも、現在のサービスでは何が起きたか確認できない段階を示す手掛かりになります。

フォームのFromとReply-Toには、どのアドレスを使う？

通常、訪問者のメールアドレスをメッセージの送信元として使うべきではありません。次のように設定するほうが安全です。

From: Website Enquiries <forms@example.com>

Reply-To: visitor@example.net

固定のFromアドレスはウェブサイトからのメールであることを示し、Reply-Toを使えば担当者は訪問者にそのまま返信できます。実際の送信サーバーやサービスは、使用するドメインとメール環境で送信を許可されている必要があります。会社のドメインのアドレスを選ぶだけでは、送信許可の設定にはなりません。

この設定なら、ウェブサイトが訪問者の任意のドメインを送信元として名乗ることも避けられます。受信側のシステムでは、表示上の送信元ドメインと、SPFまたはDKIMで認証された送信元との整合性を、DMARCに基づいて確認するケースが増えています。

メール認証が原因の可能性はある？

可能性はありますが、調査すべき原因のひとつにすぎません。証拠から、入力チェック、宛先の誤り、送信時の受け渡し失敗、送信枠の上限、プロバイダーによる送信停止、拒否、迷惑メール判定、隔離、転送、メールボックスのルールなどが原因と分かることもあります。

ドメインからメールを送るすべての正規の送信元を洗い出すまでは、DNSレコードを変更しないでください。従業員のメール、ウェブサイトからの通知、請求システム、ニュースレター、その他のサービスが対象です。送信元を確認せずにSPFレコードを置き換えたり、DKIMやDMARCを変更したりすると、現在使えているメールに影響するおそれがあります。DNSを変更する場合は、証拠を確認したうえで、実際の送信サービスの要件に照らして設定してください。設定確認には、GoogleとYahooが公開している送信者向けガイドも参考になります。メールプロバイダーを変更する場合も、同じ送信元の一覧が欠かせません。ウェブサイトのメールやほかの自動送信システムについて、移行するのか、現在の設定で送信を許可し続けるのかを計画する必要があります。

安定した運用のために残しておくもの

問い合わせフォームを安定して運用するには、適切な閲覧権限と保存期間を定めた送信記録、認証済みの送信経路、検索できるイベントまたは配信ログ、拒否の繰り返しや送信枠の超過などを知らせるアラートを用意しましょう。監視している業務用メールボックスに向けて、公開中のフォームから定期的にテストすることも大切です。

テストが1件の受信トレイに届けば一歩前進ですが、すべてのプロバイダーにいつでも確実に届く保証にはなりません。次の問い合わせを記憶だけに頼らず調査できるよう、必要な記録を保管してください。

別の視点が必要であれば、お問い合わせください。テスト送信を受付から宛先まで追跡し、確認できない最初の段階を特定します。