「contact form 7 メール 届かない」で検索してこのページを開いた人の多くは、フォームから送ったはずの問い合わせが手元の受信箱に見当たらない、という状況にいます。応募や申し込みを受ける窓口を担当していると、この状態は落ち着いていられません。届いていない件数すら分からないまま、設定画面と受信箱を往復することになるからです。
先に結論を書きます。この症状は原因が1つではなく、送信ボタンが押されてからメールが受信箱に入るまでの間に、止まりうる場所がいくつも並んでいます。そして、それぞれ確かめる手間の重さがまったく違います。公式ドキュメントが挙げている原因を、確かめやすい順に並べ替えて上から潰していけば、当てずっぽうで設定をいじるより早く原因にたどり着けます。この記事は、その順番を決めるための記事です。
「届かない」という言葉の中に、性質の違う出来事が混じっている
窓口の担当者から出てくるのは「フォームのメールが届かない」という一言ですが、この一言は現象の名前であって原因の名前ではありません。裏側では、少なくとも次のように性質の違う出来事が起きています。
1つ目は、送信そのものが失敗している場合です。WordPressのメール送信関数が呼ばれたものの、その場で失敗して戻ってきています。
2つ目は、スパム対策のモジュールが送信を止めている場合です。この場合、送信者の画面には送信失敗と同じ見た目のメッセージが出ます。
3つ目は、送信までは成功しているのに、その後どこかで消えている場合です。迷惑メール判定、会社のメールゲートウェイでの隔離、転送設定の途中での欠落などが該当します。
4つ目は、宛先や差出人の設定が想定と違っていて、そもそも見ている受信箱に入らない設計になっている場合です。
この4つは、対処法がまったく違います。3つ目に対して送信設定をいじっても直りませんし、1つ目に対して迷惑メールフォルダを探しても見つかりません。だからこそ、最初にやることは設定変更ではなく、いまどれに当たっているかを見分けることです。
そして、Contact Form 7はこの見分けのための手がかりを、送信直後の画面にきちんと出しています。公式のFAQを読むと、送信後に表示される枠の色が、どこまで進んだかの信号になっていることが分かります。
送信直後に出る枠の色が、最初の手がかりになる
Contact Form 7でフォームを送信すると、フォームの下に結果のメッセージが表示されます。このメッセージの枠の色が、切り分けの出発点です。公式FAQには、赤枠、オレンジ枠、緑枠のそれぞれについて説明があります。
赤枠の「There was an error trying to send your message.」については、公式に次のように書かれています。「The red border means that Contact Form 7 tried to send mail with wp_mail(), but it failed.」つまり、WordPressのメール送信関数を呼んだが失敗した、という意味です。原因として公式が挙げているのは、メール設定が正しくなかった可能性と、メールサーバーが停止していた、到達できなかった、あるいは何らかの問題を抱えていた可能性です。その場合はホスティング事業者に問い合わせてエラーログを確認してもらうよう案内しています。あわせて「In some cases, it is possible to solve this issue by using another mail server.」とも書かれています。
オレンジ枠については、公式は次のように説明しています。「The orange border is a sign of spam. It indicates that one of the spam protection modules has detected suspicious activity in the form submission.」スパム対策のどれかが反応した、という信号です。どのモジュールが止めたのかは、スパムログの機能で判別することが推奨されています。
そして厄介なのが緑枠です。緑枠が出ているのに届かない場合について、公式には次の記述があります。
Showing the green border message means that the PHP function for sending the mail has certainly completed successfully. So if you can't receive the mail, it's highly possible that the mail has been kidnapped or killed after that. 出典: contactform7.com
送信関数は確かに成功しており、その後で消えている可能性が高い、という説明です。あわせて「If you can check the log of your mail server, it could give you some clues. Spam filter often causes this kind of problem.」と、メールサーバーのログを確認することと、スパムフィルタがこの種の問題をよく起こすことが書かれています。
ここで注意しておきたいのは、赤枠とオレンジ枠で送信者に見えるメッセージが同じである点です。公式には、メール送信の失敗とスパム判定で同じメッセージを出している理由についての説明があり、スパムだと判定したことを送信者に伝えない方針が取られています。つまり、送信者から「エラーが出ました」と報告を受けただけでは、送信失敗なのかスパム判定なのかは区別できません。枠の色をスクリーンショットで送ってもらうか、自分で同じフォームから送ってみて確かめる必要があります。
切り分けの順番は、確かめる手間が軽い順に決める
原因の切り分けで遠回りになるのは、いちばん複雑な話から手を付けてしまったときです。SPFやDKIMといった認証まわりの話は、いかにも原因らしく見えます。しかし、実際に多いのは差出人アドレスの設定と、サーバー側の送信が動いていないことです。
そこで、次の順番で確かめます。判断の基準は「原因である確率」ではなく「確かめるのにかかる手間の軽さ」です。手間の軽い項目は、外れてもほとんど損をしません。
1つ目は、差出人アドレス（From）がサイトと同じドメインになっているかどうか。管理画面を開けば数十秒で分かります。
2つ目は、既定のテンプレートが使う wordpress@ で始まるアドレスが、サーバー上に実在するかどうか。
3つ目は、サーバーのメール送信そのものが動いているかどうか。ホスティング事業者に確認するか、別の経路から送ってみます。
4つ目は、受信側の迷惑メール判定で消えていないかどうか。
5つ目は、スパム対策モジュールが送信を止めていないかどうか。
6つ目は、別のメールサーバーから送る方式に切り替えるかどうかの判断です。
上の4つは設定を壊さずに確かめられます。順番に消していけば、少なくとも「どこで止まっているか」までは必ず絞り込めます。
差出人アドレスがサイトと同じドメインになっているかを見る
Contact Form 7の管理画面には Mail タブがあり、To、From、Subject、Additional headers、Message body、File attachments を編集できます。いずれの欄にも mail-tag を埋め込めます。
この中でまず見るのが From です。公式の説明には次のように書かれています。「This field value should be an email address that belongs to the same domain as the web site. Otherwise you'll get a configuration error.」サイトと同じドメインに属するメールアドレスにするべきで、そうでなければ設定エラーになる、という記述です。
ここでよくある詰まり方が、フォームの入力欄に入った送信者のアドレスを、そのまま From に入れてしまう組み方です。返信しやすくしようという意図は分かりますが、この形にすると差出人がサイトと無関係のドメインになります。送信元のサーバーが名乗ってよいドメインと、メールの差出人欄に書かれたドメインが食い違うため、受信側で疑わしいメールとして扱われる余地が生まれます。
公式が案内しているのは、From はサイトと同じドメインのアドレスに固定したうえで、返信先を分けたい場合は Additional headers に Reply-To を書く方法です。Reply-To は Mail と Mail (2) の両方で指定できます。この形にすると、差出人はサイトのドメインのまま、受信箱で返信ボタンを押したときの宛先だけが送信者になります。窓口の運用としても、この形のほうが安全です。差出人が送信者のアドレスになっていると、受信箱の検索や自動振り分けのルールが作りにくくなります。
To の欄についても公式に記載があります。「Specify values in the valid mailbox syntax, or you'll get a configuration error.」有効なメールボックスの書式で指定する必要があります。宛先を複数にしたい場合は、Additional headers に Cc や Bcc を1行1件で追加する方法があり、公式Docsには「Adding Cc, Bcc and other mail headers」というページが用意されています。
このタイミングで、管理画面に設定エラーの警告が出ていないかも確認します。Contact Form 7は設定内容の問題を検知して警告を表示する仕組みを持っているので、警告が出ているならそこが先です。
既定のテンプレートが使うアドレスが、サーバー上に実在するか
差出人の設定を触っていない場合、既定のメールテンプレートは wordpress@ にサイトのドメインを付けたアドレスを From に使います。ここについて、公式のベストプラクティスのページには明確な案内があります。
「It is recommended you prepare a real wordpress@{your-site-domain} address on your host.」ホスト上に実在する wordpress@ のアドレスを用意することが推奨されています。その理由も添えられています。「Some hosts also block outgoing mail from this address if it doesn't exist.」実在しないアドレスからの送信をブロックするホストがある、という記述です。
この項目が厄介なのは、症状が「たまに届く」ではなく「まったく届かない」になる一方で、管理画面にはエラーが出ないことがある点です。設定としては正しく見えるのに、サーバーが送信を拒んでいます。レンタルサーバーの管理画面でメールアカウントを1つ作るだけで解決する場合があるので、確かめる価値のわりに手間が軽い項目です。
なお、実在するアドレスを作った場合、そのアドレス宛の受信箱に配信エラーの通知が溜まっていくことがあります。送ったメールが弾かれたときの通知は、多くの場合この差出人アドレスに返ってきます。届かない原因を追っているときは、この受信箱そのものが有力な手がかりになります。定期的に中身を確認できる状態にしておくと、次に同じことが起きたときの調査が速くなります。
サーバーのメール送信そのものが動いているかを確かめる
赤枠が出ている場合、疑うのはサーバー側のメール送信です。公式は、メールサーバーが停止していた、到達できなかった、その他の問題を抱えていた場合にも送信は失敗すると書いており、ホスティング事業者に問い合わせてエラーログを確認してもらうよう案内しています。
ここで大事なのは、問い合わせるときに何を伝えるかです。「フォームのメールが届きません」だけでは、事業者側も調べようがありません。次の情報をそろえてから連絡すると、話が早く進みます。
送信を試した日時を、できれば秒単位まで。差出人として設定しているアドレス。宛先のアドレス。送信直後に表示された枠の色とメッセージの文言。同じサーバー上の他の機能、たとえばWordPressのパスワード再設定メールが届くかどうか。
最後の項目は特に有効です。パスワード再設定メールもWordPress本体のメール送信関数を通るので、これが届かないならフォームの設定の問題ではなく、サーバーのメール送信の問題だと切り分けられます。逆にパスワード再設定メールは届くのにフォームのメールだけ届かないなら、原因はフォーム側の設定か、差出人アドレスの扱いか、スパム対策モジュールのどれかに絞られます。この1つの確認で、調べる範囲が半分になります。
共有型のレンタルサーバーでは、同じサーバーを使う他の利用者の送信が原因で、サーバー全体の評判が下がることもあります。この場合は自分の設定をいくら見直しても改善しません。公式が「In some cases, it is possible to solve this issue by using another mail server.」と書いているのは、こうした状況を想定した案内です。
受信側の迷惑メール判定で消えていないかを確かめる
緑枠が出ているのに届かない場合、公式の説明どおり、送信後にどこかで消えている可能性が高い状態です。ここで確認する場所は、送信側ではなく受信側です。
確認する順番を決めておきます。まず自分の受信箱の迷惑メールフォルダ。次に、メールソフト側で作った自動振り分けのルール。フォームからのメールは件名が毎回同じ形になりやすいため、過去に作ったルールで意図せずアーカイブに飛んでいることがあります。次に、会社でメールゲートウェイを使っている場合は、その隔離領域。最後に、転送設定を使っている場合は転送元と転送先の両方です。
転送は見落とされやすい経路です。フォームの宛先には代表アドレスを指定していて、そこから個人のアドレスに転送している構成だと、転送の途中で認証が壊れて受信側に弾かれることがあります。この場合、転送元の受信箱には残っているのに転送先には届きません。代表アドレスの受信箱を直接開いて中身を確かめれば、この可能性はすぐに切り分けられます。
公式は「Spam filter often causes this kind of problem.」と書いており、緑枠なのに届かない事象の原因としてスパムフィルタを挙げています。加えて、本文の作り方についての注意もあります。任意入力欄の値を使うときは空欄でもヘッダが有効なままかを確認すること、そして本文を空または短くしすぎないことです。理由も添えられています。「It not only makes the mail look like spam, it makes mail sending function fail on some hosts.」本文が短すぎるとスパムらしく見えるだけでなく、一部のホストでは送信関数自体が失敗する、という記述です。
Mail タブには「Exclude lines with blank mail-tags from output」という設定があり、空欄の行を出力から除けます。任意入力欄が多いフォームでこれを有効にすると、本文が想定以上に短くなることがあります。届かない相談の中には、この組み合わせで本文がほとんど空になっているものが混じります。
スパム対策モジュールが送信を止めていないかを確かめる
オレンジ枠が出ている場合、あるいは特定の送信者からのものだけ届かない場合は、スパム対策のモジュールを疑います。Contact Form 7の公式の方針は「Contact Form 7 provides several spam protection modules; we recommend utilizing different types in combination.」であり、複数の種類を組み合わせて使うことが推奨されています。裏を返すと、複数入っている環境では、どれが止めたのかを判別する作業が必要になります。
Akismetを使っている場合、スパム判定時の挙動は公式に明記されています。「Contact Form 7 will suspend the email and show a message saying, "There was an error trying to send your message," surrounded by an orange border.」メールの送信を保留し、オレンジ枠のメッセージを出します。フォーム側では form-tag に akismet:author、akismet:author_email、akismet:author_url といったオプションを付けて判定材料を渡します。公式は「To get accurate results, you are advised to use as many options as possible.」と、できるだけ多くのオプションを使うよう案内しています。送信されるデータについても記載があり、akismet の付いた欄だけでなく、すべての入力と環境変数が送られます。
動作確認用の値も公開されています。名前欄に「viagra-test-123」、メール欄に「[email protected]」を入れると、スパムとして扱われる挙動を確かめられます。これを使えば、オレンジ枠がAkismetによるものかどうかを実際に再現できます。
誤判定の報告については、公式に前提条件が書かれています。「To report false detections to Akismet, you need the Flamingo plugin activated because Contact Form 7 doesn't come with the ability to store submission data into the database.」誤判定を報告するにはFlamingoが必要で、その理由はContact Form 7自体が送信データをデータベースに保存する仕組みを持たないためです。Flamingo > Inbound Messages で Inbox と Spam のリストを切り替え、Status を変更すると Akismet API へ報告が送られます。
Cloudflare Turnstileを使っている場合は、Contact > Integration に site key と secret key が正しく入っているかを確認します。公式は「Unlike Google reCAPTCHA, Turnstile is available for free. We recommend Turnstile unless you have reasons to use reCAPTCHA.」と書いており、ウィジェットのモードは Managed が推奨されています。既定ではフォームの先頭に配置されますが、位置を変えたい場合は [turnstile] form-tag を差し込みます。
reCAPTCHAを使っている場合は、キーの世代を確認します。「Contact Form 7 5.1 and later uses this reCAPTCHA v3 API.」であり、「API keys for reCAPTCHA v3 are different from those for v2; keys for v2 don't work with the v3 API.」とあるとおり、v2のキーはv3では動きません。古い環境から設定を引き継いだサイトでは、ここが原因になることがあります。また、[recaptcha] form-tag はもう不要で、テンプレートに残っていても空文字に置き換えられる旨が書かれています。
意外な盲点がもう1つあります。WordPressの Settings > Discussion にある「Disallowed Comment Keys」です。公式には「Contact Form 7 can also utilize it to blocklist specific words or IP addresses.」とあり、ここに入れた語やIPアドレスを含む送信はスパムとして扱われ、配信されません。コメントスパム対策として過去に追加した語が、フォームの本文にたまたま含まれていて弾かれる、ということが起こりえます。特定の人からだけ届かない場合は、この一覧を一度見直す価値があります。送信元IPを調べたい場合は、メール本文に特殊 mail-tag の [_remote_ip] を入れる方法が案内されています。
別のメールサーバーから送る方式に切り替えるかどうか
ここまでの確認で、サーバーのメール送信そのものが不安定だと分かった場合、次の判断は送信経路を変えるかどうかです。公式も「In some cases, it is possible to solve this issue by using another mail server.」と、別のメールサーバーを使うことで解決する場合があると書いています。
WordPressでは、メール送信関数の処理を差し替えて、外部のSMTPサーバー経由で送るようにするプラグインが広く使われています。この方式にすると、送信の主体がWordPressの動いているサーバーから、メール配信を専門にしているサービスに移ります。配信の実績が積み上がっている経路を使えるため、受信側で弾かれる確率を下げられる可能性があります。
ただし、これは万能の解決策ではありません。判断するときに押さえておきたい点が3つあります。
1つ目は、原因がスパム対策モジュールによる保留だった場合、送信経路を変えても直らないことです。オレンジ枠が出ているなら、先にそちらを解決します。
2つ目は、送信経路を変えると、送信元の認証設定を別途そろえる必要が出てくることです。使うサービスの案内に従って、ドメイン側の設定を行うことになります。
3つ目は、認証情報の管理が増えることです。APIキーやパスワードがWordPressの管理画面に保存されるため、管理者権限を持つ人の範囲を確認しておく必要があります。
なお、Contact Form 7の Additional Settings には「skip_mail: on」という設定があり、これはメール送信だけを飛ばす設定です。公式には「Unlike demo_mode, skip_mail doesn't affect other activities like storing messages with Flamingo.」と書かれています。テスト中にこれを入れたまま本番に戻し忘れると、送信されないのに送信成功の表示が出ます。届かない相談の切り分けでは、この設定が残っていないかも一度確認しておくと安心です。
SPFやDKIMの話をどこまで踏み込むか
到達率を上げるための設定として、公式は認証の仕組みにも触れています。「you can utilize email authentication methods including SPF and DKIM, which are supported by most major mail service providers.」主要なメールサービス事業者の多くが対応しているSPFとDKIMを活用できる、という案内です。
仕組みを一般的な範囲で説明しておきます。SPFは、そのドメインのメールをどのサーバーから送ってよいかを、ドメイン側の情報として公開しておく仕組みです。DKIMは、送信時にメールへ署名を付けておき、受信側が公開されている鍵で検証する仕組みです。DMARCは、SPFとDKIMの検証結果を踏まえて、認証を通らなかったメールをどう扱うかの方針をドメイン側から示す仕組みです。いずれも、差出人として名乗っているドメインと、実際の送信経路の関係を受信側が確かめられるようにするためのものです。
ここで断定を避けたい理由があります。これらの設定は、利用しているレンタルサーバー、ドメインの管理事業者、外部のメール配信サービスのどれを使っているかによって、書く場所も書き方も変わります。同じ内容の設定でも、管理画面上の項目名が事業者ごとに違います。また、すでに他の用途で設定が入っている場合、単純に追記すると既存の送信に影響が出ることもあります。
したがって、この部分については、利用中のサーバーやドメイン管理事業者が公開している案内に従って進めるのが確実です。フォームからのメールだけの問題ではなく、そのドメインから送るすべてのメールに関わる設定なので、既存の設定を確かめてから触ることをおすすめします。設定の内容によっては、社内の情報システム担当や、契約している事業者のサポート窓口に確認したほうが早い場合もあります。
添付ファイル付きのフォームで、詰まりやすい箇所
応募書類や見積依頼をフォームで受け取っている場合、添付ファイルが原因で届かなくなることがあります。ここは公式に具体的な数値が書かれているので、確かめやすい部分です。
まずメール添付の上限です。公式には次のように書かれています。「Keep in mind that there is an upper limit (25 MB) on the total size of files attached to an email. You will receive a warning if your contact form configuration allows attached files that exceed this limit.」メールに添付するファイルの合計サイズには 25MB の上限があり、これを超える設定になっていると警告が出ます。あわせて公式は「Transferring a large amount of data is not the primary purpose for which the email system is designed. You should instead use a specialized service such as Dropbox.」と、大量のデータ転送はメールの本来の用途ではないため専用のサービスを使うよう案内しています。
次に、フォーム側の受け取り条件です。ファイル欄の form-tag は [file] と [file*] で、後者は必須項目になります。受け付ける種類は filetypes: オプションで指定し、拡張子とMIMEタイプが使え、複数はパイプ記号で区切ります。最大サイズは limit: オプションで指定し、kb または mb の接尾辞が使えます。省略時はバイト数として扱われます。小数点は使えず、書いても無視される旨が明記されています。記述例は [file your-file filetypes:pdf|txt limit:2mb] のような形です。
省略した場合の既定値も公開されています。「The default filetypes: option value is audio/|video/|image/*, and the default limit: option value is 1mb.」既定の上限は 1MB です。応募書類のPDFは、この 1MB をあっさり超えることがあります。公式も「Since these default values can change in future versions without notice, it is recommended to set the options explicitly.」と、既定値に頼らず明示的に指定するよう推奨しています。
もう1つ、サーバー側で詰まる箇所があります。アップロードされたファイルは、検証を通ったあと一時フォルダへ移され、そこからメールに添付されて送信され、送信後に削除されます。一時フォルダの場所は既定で wp-content/uploads/wpcf7_uploads です。このフォルダは自動作成されますが、失敗することがあります。公式は理由として「The most possible reason for this is that the parent folder doesn't have sufficient writing permissions.」親フォルダの書き込み権限が足りないことを挙げています。ファイル添付のあるフォームだけ届かない場合は、ここを確認する価値があります。
なお、サーバー上のファイルを添付する機能もありますが、セキュリティ上の理由から wp-content ディレクトリの外にあるファイルの指定は許可されていません。
メールが唯一の記録になっている状態から抜ける
ここまでは、届かない原因を突き止める話でした。ただ、受付を回している立場からすると、もう1つ考えておきたいことがあります。届かなかったメールが、そのまま失われるかどうかです。
Contact Form 7の標準の挙動については、公式に明確な記載があります。「Contact Form 7 doesn't save the submitted messages. To manage messages through Contact Form 7, you need to install Flamingo (another plugin created by the same developer).」送信されたメッセージは保存されず、管理したい場合は同じ開発者が作ったFlamingoを入れる必要がある、という説明です。
さらに踏み込んだ記述もあります。「Contact Form 7 doesn't store submitted messages anywhere. Therefore, you may lose important messages forever if your mail server has issues or you make a mistake in mail configuration.」メールサーバーに問題があったり、メール設定を間違えたりすると、重要なメッセージを永久に失う可能性がある、と公式自身が注意しています。
Contact Form 7 doesn't store submitted messages anywhere. Therefore, you may lose important messages forever if your mail server has issues or you make a mistake in mail configuration. 出典: contactform7.com
この構造は、届かない問題の深刻さを一段上げます。設定を直せば今後は届くようになりますが、直すまでの間に送られたものは手元に残っていません。応募や申し込みを受けている窓口では、これは取り返しがつかない損失になります。
Flamingoを入れると、この前提が変わります。公式の説明は「Flamingo saves all messages through contact forms into the database. Flamingo is a free WordPress plugin created by the same author as Contact Form 7.」であり、Flamingo側のreadmeには「After activation of the plugin, you'll find Flamingo on the WordPress admin screen menu. All messages through contact forms are listed there and are searchable.」と、管理画面に一覧が出て検索できることが書かれています。
管理画面のメニューは Flamingo > Inbound Messages です。Subject と From の欄があり、既定では Contact Form 7 の標準入力欄である your-subject、your-name、your-email から値を取得します。フォームを作り替えて標準の欄名を使っていない場合は、Additional Settings で flamingo_subject、flamingo_name、flamingo_email に mail-tag を指定して差し替えます。ここを設定しないと、一覧の Subject や From が空欄になることがあります。
保存させたくないフォームがある場合は、そのフォームの Additional Settings に「do_not_store: true」を書きます。公式の説明は「This setting tells message storage modules, such as Flamingo, not to store messages through this contact form.」です。
個人情報の扱いについては、Flamingoのreadmeに注意書きがあります。「This plugin stores submission data collected through contact forms, which may include the submitters' personal information, in the database on the server that hosts the website.」送信者の個人情報を含みうるデータが、サイトをホストしているサーバー上のデータベースに保存されます。保管の期間や範囲をどう決めるかは、扱う情報の内容によって判断が変わるため、自組織の規程や所管の窓口、専門家に確かめてください。公式も、GDPRについて「Ultimately, no WordPress plugin in itself can provide legal compliance, and the responsibility for making your contact forms compliant with legislation lies with the user (you).」と、法令への適合は利用者の責任であると明記しています。
自動返信と本文の組み方が原因になっている場合
送信者への自動返信が届かない、という相談も混じります。ここも公式の記述で切り分けられます。
Contact Form 7では Mail (2) を自動返信に使います。公式の説明は「Mail (2) is an additional mail template. It is often used as an autoresponder, but you can use it for any purpose.」であり、重要なのは次の一文です。「Mail (2) is sent only when the primary Mail has been sent successfully.」Mail (2) は、最初の Mail が正常に送られたときにだけ送られます。
つまり、自動返信が届かないという相談の一部は、自動返信の設定の問題ではなく、最初のメールが送れていない結果です。この場合、窓口側にも届いていないはずなので、まずそちらを確認します。窓口には届いているのに自動返信だけ届かない場合は、Mail (2) の宛先設定、つまり送信者のメールアドレスを受け取る mail-tag が正しく入っているかを見ます。
Message body の形式についても押さえておきます。既定はプレーンテキストで、HTMLを使う場合は「Use HTML content type」にチェックを入れます。HTMLの本文を書いたのにチェックを入れていないと、タグがそのまま文字として届きます。逆に、チェックを入れた状態で本文がほとんど空だと、前に触れたとおり送信そのものが失敗するホストがあります。
動作環境の更新をきっかけに止まる場合
「昨日までは届いていた」という場合は、動作環境の変化を疑います。Contact Form 7は wordpress.org のプラグインディレクトリで配布されており、ライセンスは readme に「License: GPLv2 or later」と記載されています。ディレクトリへの登録は2007年8月2日で、現行バージョンは 6.1.7、最終更新は2026年8月17日です。組み合わせて使う Flamingo も同じく wordpress.org 配布で、現行バージョンは 2.6.4、最終更新は2026年8月18日です。
動作要件も公開されています。Contact Form 7 6.1.7 の readme 記載値は「Requires at least: 6.7」「Tested up to: 7.1」「Requires PHP: 7.4」です。Flamingo 2.6.4 も同じく、WordPress 6.7以上、PHP 7.4以上となっています。
今後の方針についても、2025年12月2日付の公式アナウンスがあります。新しい方針は「WordPress: The latest major version (at the time of the plugin's major release) and greater.」「PHP: Versions recommended by the latest major version of WordPress.」というものです。次期メジャーの見通しとして、Contact Form 7 の次のメジャーバージョン 6.2 は2026年前半にリリース予定で、そのときの最新のWordPressメジャーバージョンはおそらく 6.9 になるため 6.2 は WordPress 6.9以上を対象とし、WordPress 6.9 が PHP 8.3以上を推奨することから 6.2 は PHP 8.3以上を必要とする、と書かれています。
サーバーのPHPバージョンを上げた直後、あるいはWordPressやプラグインを更新した直後に届かなくなったなら、この線を確認します。あわせて、Ajax送信についての記載も知っておくと役に立ちます。「Contact Form 7 4.8 and later versions use the WordPress REST API for Ajax submission. If the REST API isn't available on your site, you have to give up using Ajax submission. You can still use non-Ajax submission.」セキュリティ設定などでREST APIを止めている環境では、送信の挙動が変わります。非Ajax送信モードでは wpcf7mailsent や wpcf7submit といったDOMイベントが発火しない点も明記されています。古い記事を見て on_sent_ok を使っている場合は、これが Contact Form 7 5.0 で正式に削除されている点にも注意が必要です。
受付データの考察
ここまでの切り分けを一通り終えた窓口担当者が、次に決めることになるのは「今後この症状にどう備えるか」です。原因を特定して直すことと、同じことが起きたときに気づける状態にしておくことは別の作業です。
届かない問題がここまで厄介になる理由は、突き詰めると1つです。受付の記録がメールの受信箱にしか存在しないと、届かなかったものは記録に残りません。何件消えたのかも分からず、送信者から連絡が来て初めて気づきます。ここに手を入れるかどうかが、次の判断になります。
Contact Form 7を使い続けるなら、Flamingoを入れて送信内容をデータベースに残す構成が、公式に案内されている対処です。これで「届いていないが記録には残っている」という状態が作れます。まず相手のまま解決できるなら、それが最短です。フォームの数が少なく、届いた件数も1日に数件で、対応する人がひとりなら、この構成で十分に回ります。
一方で、対応する人が複数いる場合や、届いたあとに返信の有無を追う必要がある場合は、別の課題が出てきます。問い合わせ1件ごとに担当者を割り当てる機能、対応ステータスを管理する機能、対応履歴や個別返信の記録を残す機能については、contactform7.com の Docs と FAQ、および wordpress.org のプラグインページ上では確認できませんでした。公式に確認できるのは、Flamingo の Inbound Messages に一覧と検索があり、Inbox と Spam の間で Status を変更できることと、複数の担当者にメールを届ける手段として Additional headers に Cc / Bcc を追加する方法があることの2点です。なお Flamingo の Status について公式ページで説明されているのは、Akismet への誤判定報告の手順としてであり、対応状況の管理として説明されているわけではありません。
この違いを整理したうえで判断したい場合は、機能の対応関係をまとめたContact Form 7との比較を確認してください。標準の挙動、Flamingoを入れた場合の挙動、それ以外の選択肢を並べています。
Cc / Bcc で複数人に届ける運用は、届けるところまでは解決しますが、返信の重複を防ぐ仕組みにはなりません。全員の受信箱に同じメールが入るだけなので、誰が返したのかは受信箱の外側で共有する必要があります。現場では、返信したかどうかが表に残らない構成のまま件数が増えると、二重返信と返し忘れが必ず起きると言われています。受付を回す側にとっては、届く届かないと同じくらい、この点が実務の負担になります。送信されたあとを回す道具が最初から同じ画面にそろっている構成にしておくと、届いた件数と対応済みの件数が同じ場所で数えられます。
フォームの置き場所を変えることを検討している場合は、他の選択肢との違いも見ておくと判断が早くなります。回答をスプレッドシートで受ける方式との違いを整理したGoogleフォームとの比較と、Microsoft 365環境での受け方をまとめたMicrosoft Formsとの比較があります。どちらも、作る手間ではなく届いたあとの回しやすさを軸に並べています。
受付の中身によって、必要になる項目は変わります。応募書類を受け取って選考の進み具合を追う場合は採用の応募受付、要件の確認と可否の連絡が要る場合は助成金・公募の受付、日々の連絡を受けて返す窓口なら問い合わせの受付に、それぞれ想定される流れをまとめています。定員と締切の管理が中心になる場合はイベントの申し込みと講座の受講申し込み、施設の空き状況と結びつく場合は施設利用の申請、会費や資格の確認が入る場合は会員の入会申し込み、機器や製品の不具合を受ける場合は修理・サポートの受付が近い形です。
いま使っている構成のどこを補えばよいかを具体的に確かめたい場合は、対応できる範囲を一覧にしたできることと、実際の画面の動きを見られる動くところを見るが参考になります。費用の目安は料金に、導入前によく出る疑問はよくある質問にまとめてあります。
最後に、この記事で挙げた確認項目を、もう一度順番だけ書いておきます。送信直後の枠の色を確かめる。差出人アドレスがサイトと同じドメインになっているかを見る。wordpress@ のアドレスが実在するかを確かめる。パスワード再設定メールが届くかでサーバー側の送信を切り分ける。受信側の迷惑メールフォルダ、振り分けルール、ゲートウェイ、転送先を順に見る。スパム対策モジュールとDisallowed Comment Keysを確認する。ここまでで原因が絞れなければ、送信経路の変更を検討する。そして、届かなかったものが記録に残る構成になっているかを見直す。この順番で進めれば、当てずっぽうで設定をいじる時間を減らせます。
Q1. 送信後に緑色の枠が出ているのに届きません。設定は合っているのでしょうか？
公式によれば、緑枠はメール送信のPHP関数が正常に完了したことを示し、その後にメールが失われた可能性が高い状態です。設定側ではなく受信側を確認します。迷惑メールフォルダ、メールソフトの自動振り分けルール、会社のメールゲートウェイの隔離、転送設定を使っている場合は転送元の受信箱を順に見てください。
Q2. 差出人アドレスに送信者のメールアドレスを入れてはいけないのですか？
公式は、Fromの値はサイトと同じドメインに属するメールアドレスにすべきで、そうでなければ設定エラーになると案内しています。返信しやすくしたい場合は、Fromはサイトのドメインに固定したうえで、Additional headersにReply-Toを書いて返信先だけ送信者に向ける方法が案内されています。
Q3. 届かなかった問い合わせを後から取り戻すことはできますか？
Contact Form 7は標準では送信内容を保存しないため、公式も、メールサーバーの問題や設定ミスがあると重要なメッセージを永久に失う可能性があると注意しています。事前にFlamingoを入れておけば送信内容がデータベースに保存され、管理画面のInbound Messagesで一覧と検索ができます。
Q4. 添付ファイル付きのフォームだけ届きません。何を確認すればよいですか？
まずサイズです。メール添付の合計サイズには25MBの上限があり、フォーム側のlimit:オプションは省略時1MBが既定値です。次に一時フォルダで、既定の場所はwp-content/uploads/wpcf7_uploadsです。公式は、このフォルダの作成に失敗する最も多い原因として親フォルダの書き込み権限不足を挙げています。