WordPressのフォームからメールが届かないときの調べ方 （具体例：Contact Form 7）

フォームには「送信しました」と出るのに、メールが見当たらない。
運営者には届いているのに、問い合わせた人には自動返信が届かない。

どちらもメールの未着ですが、最初に確認したい場所は違います。
設定をあれこれ変える前に、届かないメールと、どこまで処理が進んだかを確かめましょう。

この記事では、WordPressのフォームを設定・保守する方向けに、確認する順番をまとめます。
具体的な設定や表示はContact Form 7（以下、CF7）を例にします。
パスワード再設定など、フォーム以外のメールは対象外です。

【1】 まず、どのメールが届かないのかを確認する

運営者への通知と、自動返信を分ける

問い合わせフォームでは、1回の送信で次の2通を送ることがあります。

• 運営者への通知：問い合わせ内容を担当者へ知らせるメール
• 自動返信：問い合わせた人へ、受け付けたことを知らせるメール

この2通は、宛先も設定も別です。
「フォームのメールが届かない」と言われたら、まずどちらなのかを確認します。

受信トレイだけでなく、迷惑メールや隔離フォルダーも見てください。
宛先の入力間違いがないか確かめ、送信時刻や件名を手がかりに検索します。
メールソフトに見当たらない場合は、Webメール側にもないか確認しましょう。

症状から調べる場所を選ぶ

今起きていること	最初に確認すること	詳しい説明
通知先が合っているか分からない	対象フォームの宛先・差出人	【2】メールの設定
自動返信だけ届かない	自動返信の有効化・宛先・実行条件	【2】メールの設定。 問題がなければ【4】送信経路・記録、 【5】一部だけ届かない場合
入力エラーが出る・送信が終わらない	フォームの入力と通信結果	【3】送信時のエラー
送信完了と出るが、どちらのメールも届かない	通知設定と、実際に使う送信経路	【2】メールの設定、 【4】送信経路・記録
Gmailなど、特定の宛先だけ届かない	通知ごとの設定差と、送信・受信側の記録	【2】メールの設定、 【5】一部だけ届かない場合
SMTPのテストメールは届くが、フォームからは届かない	テストと実フォームの条件の違い	【4】送信経路・記録

新設したときから届かないのか、以前は届いていたのかも控えます。
後者なら、直前のフォーム設定、送信サービス、DNS、プラグイン更新などが調査の手がかりになります。
ただし、直前に変えたものが必ず原因とは限りません。

おおまかな流れは、次のとおりです。

フォームの入力・受付
  → WordPressのメール送信処理
  → 送信サーバーやメール配信サービス
  → 相手側のメールサーバー・受信箱

調査では、このうちどこまで確認できたかを見ていきます。
最初からすべての設定を変更する必要はありません。

【2】 フォームの宛先・差出人・自動返信の設定を確認する

宛先・差出人・返信先を混同しない

Contact Form 7では、管理画面の「お問い合わせ」から対象フォームを開き、「メール」タブを確認します。
フォームが複数ある場合は、問題のページで使っているフォームを選んでください。

見る欄は、まず次の3つです。

設定	役割	確認すること
送信先（To）	メールを届ける相手	通知を受け取りたいアドレスか
送信元（From）	差出人として表示するアドレス	自分が管理し、送信に使えるアドレスか
Reply-To	受信者が返信するときの宛先	返信してほしい相手になっているか

たとえば、サイトを sample.example.test で運営しているとします。
問い合わせ者が入力したアドレスは [e-mail] です。
次は説明用の設定例です。
.test はインターネット上の実際の宛先ではないので、自分が管理するドメイン・アドレスへ置き換えてください。

CF7の設定欄	運営者への通知「メール」	自動返信「メール(2)」
送信先	[e-mail]	[your-email]
送信元	サンプルサイト <[e-mail]>	サンプルサイト <[e-mail]>
追加ヘッダー	Reply-To: [your-email]	Reply-To: [e-mail]

この設定なら、運営者は通知メールへの返信で問い合わせ者へ連絡できます。
問い合わせ者が自動返信に返信した場合は、運営者の窓口へ届きます。

ここで、問い合わせ者のアドレスをFromに入れる必要はありません。
「誰へ返信するか」はReply-Toで指定できます。
送信元に他人のドメインを使うと、そのドメインを名乗って別のサーバーから送信することになります。

CF7のFromは、サイトと同じドメインのアドレスにするのが基本です。
さらに、実際の送信サービスでそのアドレスを使えるかも確認します。
サービスによっては、差出人の登録・ドメイン認証や、メールアカウントの作成が必要です。

[your-email] は、フォームの入力値に置き換わるメールタグです。
フォーム側が [email* your-email] なら、このタグと対応しています。
入力欄の名前を変えた場合は、メール側も確認してください。
値を参照する欄が任意入力なら、空欄のときにも有効なメール設定になるかを見ます。

WordPressの「設定 → 一般」にある管理者メールアドレスを変えても、ここに直接入力した通知先は別です。
実際に使われている「送信先」を確認するのが確実です。

自動返信の設定と、実行される条件を確認する

自動返信にメール(2)を使っている場合は、次を確認します。

• 「メール(2)を使用」にチェックが入っている
• 送信先が、問い合わせ者のメールタグになっている
• そのメールタグと入力欄が対応している
• 送信元・追加ヘッダーに設定エラーがない

メール(2)は、最初の「メール」の送信が成功した場合に送信されます。
最初の送信が失敗していれば、自動返信側の宛先だけを修正しても解決しません。
なお、ここでいう成功は、運営者が受信したことを確認しているわけではありません。

自動返信は、入力されたアドレスへメールを送る機能です。
本番ではスパム対策も合わせて設定し、設定検証の警告を放置しないようにしてください。

【3】 送信ボタンを押しても完了しない・エラーになる

入力エラーとスパム判定を確認する

フォームにエラーが出る場合は、メールの設定より先に、処理が止まった理由を見ます。

表示・結果	確認する場所	次の対応
必須項目・形式のエラー	エラーが付いた入力欄	未入力や形式を修正する。添付がある場合は種類・サイズも確認
スパム判定	使用しているスパム対策と、取得済みの判定記録	どの対策が反応したかを確認し、設定を調べる
メール送信処理の失敗	メール設定と、送信側のエラー	【4】送信経路・記録の確認へ進む
読み込み表示のまま終わらない	ブラウザの通信とJavaScriptエラー	「処理が終わらない場合は、通信結果を見る」へ進む

CF7では、スパム判定とメール送信失敗で同じメッセージが出る場合があります。
標準表示の枠色は手がかりになりますが、見た目を変更しているサイトでは、色だけに頼らないでください。

スパムと判定されたからといって、本番のスパム対策をまとめて無効化するのは避けましょう。
導入している対策を確認し、判定記録が使える場合は、対象の試験と照合します。
たとえばFlamingoで記録している場合は、受信メッセージのスパムに分類された項目を開き、判定理由を確認します。
保存機能を導入していなければ、過去の判定記録があるとは限りません。

処理が終わらない場合は、通信結果を見る

Chromeなら、次の順で確認できます。

1. フォームを開き、開発者ツールの「Network」を選ぶ。
2. 管理下の試験用アドレスで、一度だけ送信する。
3. 「Fetch/XHR」で絞り、CF7の contact-forms や feedback を含む送信リクエストを探す。
4. HTTPステータスと「Response」の内容を確認する。

リクエスト自体が見当たらなければ、入力チェックで止まっていないかを見ます。
ConsoleにJavaScriptエラーがないかも調べてください。
403ならアクセス制限など、500ならサーバー側のエラーなどを候補にし、対応する記録を確認します。
番号だけで原因を決めず、どのリクエストに対する応答かも見てください。

HTTP 200が返っても、それだけではメール送信成功とはいえません。
CF7の応答にある status と、画面表示を合わせて確認します。

通信が止まったように見える場合も、裏で処理が進んでいる可能性があります。
何度も送信する前に、通知や保存データが重複していないか確かめましょう。

プラグインの競合を調べる場合は、まず検証環境で対象を絞って切り分けます。
営業中のサイトで、いきなり全プラグインを停止する手順にはしないでください。

【4】 送信完了と表示されるのに届かない

「成功」が何を確認した結果なのかを分ける

フォームの完了表示は、相手の受信箱を見て出しているわけではありません。
WordPressの wp_mail() も、戻り値がtrueなら相手に届いた、という関数ではありません。

「成功したはずなのに」と感じたときは、次のように分けてみます。

確認できた結果	分かること	まだ確認したいこと
CF7が送信完了を表示した	CF7側で送信成功として処理された	対象の通知・自動返信がどのように送信されたか、受信できたか
SMTPプラグインのテストが成功した	そのテスト条件で送信処理を実行できた	実フォームも同じ条件か、テストメール自体を受信したか
送信サービスがメールを受け付けた	サービスへ渡すところまで進んだ	保留・拒否になっていないか、配信先のサーバーが受け付けたか
配信先のサーバーが受け付けた	そのサーバーまで届いた	受信トレイ・迷惑メール・隔離など、どこへ入ったか
対象の受信箱でメールを確認した	その試験メールを受信できた	宛先・内容・返信先が正しいか、自動返信も確認できたか

サービスの「送信済み」「配信済み」も、同じ意味とは限りません。
表示名だけで判断せず、その状態が何を示すかを確認します。

自動返信だけ失敗した場合も試してみる

では、運営者への通知は成功し、自動返信だけ失敗した場合はどうなるのでしょうか。

WordPress 7.1・PHP 8.5.10・CF7 6.1.6のローカル環境で、5つの条件を試しました。
実際のメールは外部へ送らず、送信先をローカルの捕捉処理へ向けています。
送信失敗のケースは、この処理に意図的にエラーを返させたものです。

試した条件	通知の送信処理	自動返信の送信処理	CF7の応答 status
両方とも正常	成功	成功	mail_sent
必須の名前を未入力	実行されず	実行されず	validation_failed
通知の送信を失敗させる	失敗	実行されず	mail_failed
メール(2)を無効にする	成功	実行されず	mail_sent
自動返信の送信だけを失敗させる	成功	失敗	mail_sent

この5ケースでは、HTTPステータスはいずれも200でした。
最後のケースでは、自動返信の送信処理は失敗しているのに、CF7の結果は mail_sent になっています。
フォーム全体の結果だけでは、自動返信の送信が成功したかまでは判断できません。

表の成功・失敗は、WordPressの送信処理で確認した結果です。
ローカルでメールを捕捉した件数を、そのまま外部の受信件数として数えているわけではありません。
Gmailへの配送や受信拒否の再現も、この試験には含めていません。

また、これは外部へ配信できない専用の試験環境です。
自動返信のスパム保護が未構成のため、その警告は残したまま検証しています。
警告を消すための変更や、本番で警告を無視する運用を勧めるものではありません。

使っている送信経路と、確認できる記録を調べる

まずWordPressのプラグイン一覧を見て、SMTPやメール配信サービスとの連携を使っているかを確認します。
独自コードやMUプラグインで送信方法を変えているサイトでは、それらも対象です。

連携している場合は、その設定から、利用サービスと実際の差出人を調べます。
Fromを強制的に上書きする設定があれば、CF7に入力した値と、実際に送る値が違うこともあります。

メール送信の設定をしていないからといって、WordPressがメールを送れないとは限りません。
サーバー側の標準的な送信機能を使っている場合があります。
この場合は、ホスティング会社の管理画面や案内で、PHPからのメール送信方法・制限・ログの提供範囲を確認します。

次に、試験した日時・宛先・件名から、対象の送信記録を探します。
記録が見つかったら、次のように読みます。

• 接続できない：接続先・ポート・暗号化方式がサービスの指定と合うか。サーバー側で接続を制限していないか。
• 認証できない：アカウントや認証方式、有効期限、利用権限を確認する。
• 差出人を使えない：そのサービスで許可・認証されたアドレスやドメインか確認する。
• 受付後に保留・拒否：送信先サーバーの応答、制限、認証結果を調べる。【5】一部だけ届かない場合も参照する。

記録がない場合は、すぐに「送信されていない」とは判断できません。
ログ機能を使っていなかった、保存期間を過ぎた、別のサービスへ送っていた、という可能性もあります。
取得開始時期と保存範囲を確認してから、必要なら試験用データで記録を取り直します。

ログを有効にすると、宛先や問い合わせ本文まで保存される製品もあります。
保存する項目・閲覧者・保存期間を確認し、顧客の問い合わせを無制限に記録しないようにしましょう。

SMTPのテストだけ成功する場合は、実フォームと比較する

テストメールとフォームの通知は、同じメールではありません。
少なくとも次の条件を比べます。

• 宛先
• 差出人と、その上書き設定
• 使用している送信サービス・認証
• 件名・本文・添付ファイルの有無
• 通知と自動返信のどちらを試しているか

たとえば、自分宛てのテストは届いていても、フォームの通知先には古いアドレスが残っているかもしれません。
添付なしのテストでは通っても、実フォームの添付が制限に触れている可能性もあります。

SMTPやAPI経由の送信へ変更するのは、現在の送信方法で問題が確認できたときの選択肢です。
導入済みなら、別のSMTPプラグインを追加する前に、今の設定を調べてください。
変更する場合も、サービスが指定する接続・認証・差出人の条件を揃え、最後は実フォームで再試験します。

【5】 Gmailなど、一部の宛先・自動返信だけ届かない

届いたメールと届かないメールの条件を比べる

運営者への通知は届くのに、自動返信だけ届かない。
この状況だけでは、受信先が原因とは決められません。

まず【2】メールの設定を見直し、通知と自動返信で差出人や宛先がどう違うか確認します。
そのうえで、同じ種類のメールを管理下の試験用アドレスで比較します。
新たな宛先へ、実際の問い合わせ内容を転送して試す必要はありません。

Gmail宛に届かない場合も、「WordPressからGmailのSMTPを使って送る方法」とは別の話です。
先に、今どのサーバー・サービスから送っているかを特定しましょう。

拒否・保留の記録と、受信側の設定を見る

送信サービスにエラーやバウンスが残っていれば、対象メールの応答コードと理由を確認します。
Gmailの公式一覧では、たとえば次のような違いがあります。

応答コードの例	示される問題の例	調べる方向
550 5.7.26	送信元の認証やDMARCポリシーに関する拒否	番号に続く説明を読み、対象ドメインと認証結果を確認
550 5.7.25	送信元IPとDNSの対応に関する問題	送信サーバー・配信サービス側の設定を確認
552 5.7.0	本文や添付内容に関するブロック	該当する理由と、添付の種類等を確認

同じコードでも説明が異なる場合があるため、番号だけを検索して設定を変えないでください。
一時的な保留についても、サービス側が再送する状態なのかを確認し、フォームから何度も送り直すのは避けます。

送信側で問題を見つけられなければ、受信側のフィルター・隔離・転送・容量なども確認します。
会社のメールでは、個人の受信箱より手前で、組織のルールにより隔離されていることもあります。
その場合は、メール管理担当者に対象の時刻と宛先を伝え、記録を確認してもらいます。

エラーメールが返ってこないことだけで、正常に届いたとは判断できません。
バウンスの返送先は、画面に見えるFromと異なる場合もあります。

送信元認証の結果を確認する

SPF・DKIM・DMARCは、どれもメール認証に関係しますが、見るものが異なります。

方式	何を確かめるか	問題があった場合に確認すること
SPF	配送用の差出人ドメインについて、そのサーバーから送信してよいか	実際の送信元が、対象ドメインのSPF設定に含まれているか
DKIM	メールに付けられたドメインの署名を検証できるか	送信サービスで署名が有効か、指定された公開鍵がDNSにあるか
DMARC	SPFまたはDKIMの成功と、画面上のFromドメインとの整合を確かめる	認証したドメインとFromの組み合わせが合っているか

DMARCのドメインの整合には、設定によりサブドメインを許容する場合と、完全一致を求める場合があります。
「SPFがpassなら、どんなFromでも大丈夫」という意味ではありません。

個人用Gmail宛ての送信では、すべての送信者にSPFまたはDKIMが求められます。
大量送信者には、SPF・DKIM・DMARCなど追加の要件があります。
ここでは認証に絞っていますが、TLSやDNSなどの要件もあるため、該当する範囲を公式案内で確認してください。

受信できた試験メールがある場合は、Gmailでそのメールを開きます。
返信ボタン横のメニューから「メッセージのソースを表示」を選ぶと、認証結果や詳細ヘッダーを確認できます。

たとえば、次は認証結果を読むための架空の例です。
実際に配送したメールの記録ではありません。

Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=sample.example.test;
  dkim=pass header.d=sample.example.test;
  dmarc=pass header.from=sample.example.test

spf=pass は、そのメールについてSPFの確認が通ったことを示します。
smtp.mailfrom は配送用の差出人、header.d はDKIMの署名ドメインです。
header.from は、メールに表示されるFromのドメインを指します。
受信サービスが付けた結果を読み、どのドメインが検証されたかまで確認します。

届かなかったメールのヘッダーは、その受信箱からは取り出せません。
届いた比較メールを手がかりにしつつ、未着メール自体は送信側の記録や受信側の管理機能で追います。
比較メールがpassでも、未着メールまで同じ条件だったとは限らない点に注意してください。

認証に問題があったら、使用中の送信サービスが指定するDNS設定・署名設定・差出人へ戻って確認します。
検索で見つけた別サービス用のSPFレコードを、そのまま貼り付けるのは避けましょう。
既存の送信元を消してしまうと、普段の業務メールにも影響します。

認証が通っても、受信箱への到達が保証されるわけではありません。
本文や添付、送信状況、受信側の判断も関係します。

【6】 修正後は、実際のフォームで受信まで確認する

通知と自動返信をそれぞれ再確認する

設定を直したら、問題があったフォームから送信します。
変更した項目と試験結果を対応させ、次を確認してください。

[ ] 元の症状が出ていた条件で試した
[ ] フォームに期待した結果が表示された
[ ] 運営者への通知が、意図した宛先で受信できた
[ ] 自動返信を使っている場合、入力した試験用アドレスで受信できた
[ ] 件名・本文・入力値・必要な添付が正しい
[ ] 返信操作の宛先が意図した相手になっている
[ ] 特定の受信先だけで起きていた問題も確認した
[ ] 試験用設定・一時ログを、必要な記録を残して元に戻した

一度の成功で、今後のすべての配信を保証できるわけではありません。
ただ、設定画面を眺めるだけでなく、問題があった条件で確かめることはできます。

直らない場合に備えて、確認結果を残す

調査を中断したり、サーバー会社へ問い合わせたりする場合は、次の程度を残しておくと再開しやすくなります。

試験日時・タイムゾーン：
対象フォーム・通知の種類：
症状（画面表示、どの宛先に届かないか）：
確認した設定・送信経路：
確認結果（応答コード、記録の有無など）：
変更した内容と、再試験の結果：
まだ確認できていないこと：

自分で確認できないログが必要なら、この情報を添えて該当の担当者へ相談します。
パスワード・APIキーや、顧客の問い合わせ原文を貼る必要はありません。
ヘッダーやログにも個人情報が含まれるため、共有先と必要な範囲を確認してください。

最後にもう一点。
これからのメールが届くようになっても、過去の問い合わせまで戻るとは限りません。
CF7は標準では送信内容を保存しないため、過去分を確認できるかは、導入していた保存・連携機能によります。

「届かない」ときは、まずどのメールなのかを分ける。
次に、そのメールの設定と処理結果を追う。
この順番で調べると、むやみに設定を変えず、次に確認する場所を絞れます。