Contact Form 7で「メールが届かない」をゼロにする完全ガイド｜最短復旧チェックリスト＆マルチステップ対応

WordPress の定番であるお問い合わせフォーム、 Contact Form 7（CF7）プラグインで「送信は成功しているのにメールが届かない」。

このトラブルはフォーム設定のミスだけでなく、複数の要因が重なって発生します。

しかも、主要メールサービスのスパム対策は年々厳格化しており、以前は届いていた構成でも突然届かなくなることがあります。

本記事は、まず「いま止まっている場所」を素早く特定するための診断（症状別の切り分け）を行い、そのうえで確実に届くための恒久施策へと進める構成です。

恒久施策では、PHPのmail()依存からSMTP/API送信へ切り替える設計を軸に、配信レポートで実際の到達性を検証します。

分割フォームについては、ステップ間の値引き継ぎ（nameの不一致やhidden不足）、Ajax×キャッシュの衝突、同意チェックの配置など、不達が起きやすい落とし穴を実務目線で洗い出します。

読了後には、次の状態を目指します。

• 最短復旧：ログと履歴で「フォーム→WP→配送」のどこで止まるかを即判定。
• 恒久対応：SMTP/API＋DNS認証で“なりすまし扱い”を回避し、到達率を底上げ。
• 再発防止：改修時のチェックリストと監視運用で、仕様変更やスパム基準強化にも耐える。

「とりあえず届けばOK」ではなく、継続して届き続ける仕組みに作り替える——そのための実行手順とチェックポイントを、最短で辿れるように整理しました。

最短復旧チェックリスト（まずは120秒）

ここではContactForm7でのメールが届かない原因解決をするための”あるある”である設定間違いを確認と修正方法を3つ紹介します。

これらは簡単に確認できるので、まずはここから試してみてください。

迷惑メール／受信制限の確認とテスト送信

最初に受信側を確認します。

Gmailの「迷惑メール」や「プロモーション」タブ、Outlookの「迷惑メール」フォルダ、企業メールならゲートウェイ（Proofpoint/Mimecast/Barracuda等）の隔離ボックスをチェックしてください。

送信元アドレスやドメインを受信側の許可リストへ追加してもらうと、以後の検証が進めやすくなります。

次に、何が問題なのかを確認するために、Gmail と Outlookなど、異なるサービス2種の自分のアドレスを宛先に、URLや画像、署名を除いた純テキストだけでテスト送信します。

どちらかに届けば受信側の振り分けやドメイン相性の問題、両方届かなければフォーム〜配送のどこかで問題が起きています。

• 確認方法：迷惑フォルダ／隔離を確認 → 2種（Gmail/Outlook等）宛で純テキスト送信 → 片方のみ到達か、両方不達かを判定
• 改善方法：受信側で「迷惑ではない」に変更／差出人・ドメインを許可リスト登録／添付・URL・画像を外す
• 次の一手：片方のみ到達＝受信側・相性の問題を継続検証／両方不達＝Flamingo・送信ログで層別切り分けへ

Flamingo・送信ログで「フォーム→WP→配送」の切り分け

フォームからWordPressまでは届いているかをお問い合わせ内容をデータベースに保存するFlamingoプラグインで確認します。

履歴が残っていれば「フォーム→WP」は通過です。

続いてWP Mail Logging（またはCheck & Log Email）でwp_mail()の成否・エラー・宛先・ヘッダーを確認します。

• 確認方法：Flamingoの受信履歴有無 → WP Mail Loggingでwp_mail()の成功/失敗とエラー内容を確認
  • Flamingoあり × 送信ログ成功：配送・受信側の問題（迷惑振り分け、SPF/DKIM/DMARC、Return-Path不整合）を優先。
  • Flamingoあり × 送信ログ失敗：WPの送信方式・認証情報の問題。SMTP/APIへの切替・再設定。
  • Flamingoなし：送信完了前の問題。reCAPTCHA、JSエラー、キャッシュ除外、テーマ／プラグイン衝突を疑う。
• 改善方法：
  • 送信ログ失敗時：WP Mail SMTP導入・API/SMTP設定見直し・認証情報修正
  • 送信ログ成功時：DNS認証（SPF/DKIM/DMARC）、Return-Path整合、受信側フィルタ対策
  • Flamingoなし：reCAPTCHA一時無効化／キャッシュ・最適化・セキュリティ系停止→デフォルトテーマで再テスト
• 次の一手：結果を「フロント／WP内／配送」の層で記録し、該当の恒久施策（SMTP/API、DNS認証、フロント修正）へ進む

From/Reply-Toの是正（Fromは独自ドメイン、Reply-Toにユーザー）

短時間で改善しやすいのが差出人ヘッダーの見直しです。

From（差出人）はWordPressが公開されている独自ドメインで固定（例：お問い合わせ <noreply@your-wordpress-domain.jp>）。

Reply-To（返信先）にはユーザー入力のメールを設定し、Contact Form 7の「追加ヘッダー」に

Reply-To: [your-email]

を1行だけ入れます。

宛先（To）は管理用アドレスに設定し、ユーザー向け自動返信は「メール（2）」で分離しつつ、Fromは同じ独自ドメインの実在アドレスを使います。

Fromにユーザーのフリーメールを使うのはなりすまし判定の原因になり、非推奨です。

• 確認方法：CF7のメール設定でFromが独自ドメインか、Reply-Toが[your-email]か、追加ヘッダーの書式（全角/改行）に乱れがないか確認
• 改善方法：Fromをnoreply@yourdomain.jp等の実在アドレスに固定／追加ヘッダーへReply-To: [your-email]／自動返信（メール2）も独自ドメインFromに統一
• 次の一手：Gmail/Outlook/社内メールへ再テスト → 依然不安定ならSMTP/API送信切替とSPF/DKIM/DMARC整備へ進めて恒久化

問題把握：症状別の切り分け（どこで止まっている？）

送信ボタンを押してから受信箱に届くまでを、フロント（ブラウザ） → WordPress内部（wp_mail()） → 配送・受信側（メール基盤） → 分割フォーム特有の設計という4層で分解します。

狙いは、症状から原因層をすばやく特定し、確認 → 再現 → 修正 → 再テストを短いサイクルで回すこと。

まずは挙動を“見える化”し、原因が定まったら恒久策（SMTP/API送信・DNS認証整備・設計の見直し）へ進みます。

フロントで止まる（reCAPTCHA／JS／キャッシュ）

画面上で「送信中のまま」「成功メッセージが出ない」「二重送信になる」といった症状は、フロントで処理が止まっているサインです。

開発者ツールの Network で、送信時に CF7 のエンドポイント（/wp-json/contact-form-7/v1/contact-forms/<id>/feedback もしくは admin-ajax.php）へのリクエストが発生しているか、レスポンスが 200 か、本文に mail_sent / validation_failed / spam などの結果が返っているかを確認します。

Console にエラー（Uncaught、grecaptcha 未定義、CSP 由来など）が出ている場合は、テーマや最適化プラグインの スクリプト結合/遅延、初期化順序の崩れが疑わしい状態です。

問い合わせページがキャッシュ対象のままだと、CF7 の nonce が失効して直前で落ちることがあります。キャッシュや自動最適化（CDN含む）を一時停止し、ページを除外した状態で挙動を比べてください。

reCAPTCHA v3 のスコアが低くブロックされるケースもあるため、いったん v3 を外す／v2（チェックボックス）に切り替える A/B テストで切り分けると早いです。

影響範囲を最小化して検証するには、Health Check のトラブルシューティングモードで 自分だけ CF7＋デフォルトテーマにし、他プラグインを止めた状態で再テストします。

• 分かりづらいポイントの目印
  • Network で 4xx/5xx や HTML 混入レスポンスが出る
  • Console に wpcf7 / grecaptcha 関連のエラーが並ぶ
  • キャッシュ除外で症状が消える（＝キャッシュ干渉の可能性大）

WordPress内で止まる（wp_mail()エラー／プラグイン干渉）

画面では「送信成功」でも届かないときは、フォーム → WP 本体までは通過している一方で、wp_mail() の段階で失敗している可能性が高いです。

まず Flamingo を開いて受信履歴を確認します。

履歴が残っていれば「CF7 → WP」は成功。次に WP Mail Logging / Check & Log Email で直近の wp_mail() を開き、結果（Success/Failed）、エラー文（SMTP connect() failed など）、ヘッダーの書式を見ます。

From にフリーメールを使っていたり、Reply-To 未設定、全角混在・改行位置の誤りがあると弾かれやすくなります。

必要に応じて短時間だけ WP_DEBUG_LOG を有効化し、wp-content/debug.log で PHPMailer の詳細やプラグイン衝突の痕跡を追います。

解決はシンプルです。

WP Mail SMTP を入れて SMTP もしくは API 送信に切り替え、From は独自ドメインの実在アドレスに固定、Reply-To はユーザー入力に分けます。

設定後は Gmail / Outlook / 社内メールなど複数宛で再テストし、安定して届くかを確認します。

• つまずきやすい着眼点
  • Flamingo あり × 送信ログ失敗 ＝ WP の送信レイヤーが原因
  • エラーに Invalid address・Data not accepted・Could not instantiate mail function
  • 追加ヘッダーの書式ミス（全角・余計な改行・重複）

配送で止まる（迷惑判定／バウンス／Return-Path不整合）

WordPress の外へ出た「配送～受信」フェーズでは、迷惑判定、ドメイン認証の不整合、バウンスが主な原因です。

届いた（あるいは迷惑入りした）メールの生ヘッダーを開き、Authentication-Results で SPF / DKIM / DMARC が pass か fail かを確認します。

From ドメインと認証ドメインの Alignment（整合） が取れていないと fail になりやすく、Return-Path のドメインが From と揃っていない場合も信頼度が落ちます。

エラーメールが返っているなら、550/554 などのステータスや 5.7.x の拡張コードで、ポリシー違反・レピュテーション・サイズ超過などの方向性を特定します。

送信サービス（SendGrid / Mailgun / SES など）を使っている場合は、イベントログで Delivered / Deferred / Blocked / Bounced をドメイン別に見て、件名・本文・差出人の調整や送信量のウォームアップ計画につなげます。

実務的には、API 送信＋SPF/DKIM/DMARC の整備＋Return-Path 整合の三点を満たすと、迷惑寄りの判定が一気に安定します。

• 迷ったらここをチェック
  • 生ヘッダーの spf= / dkim= / dmarc= の結果と 署名ドメインの一致
  • Return-Path: と From: のドメインが一致しているか
  • 送信サービスのイベントログで Gmail/Outlook/携帯キャリアごとの不達傾向

分割フォームで止まる（値の引き継ぎ漏れ／アドオン衝突）

multi-step（分割）フォームは、ステップ間の値の受け渡しでつまずくことが多く、最終送信のメールに項目が反映されない、あるいは送信自体が実行されない、という形で現れます。

各ステップの入力に付与した name 属性が 全ステップで同一かを確認し、最終送信時の Network → Form Data に必須項目がすべて含まれるかを目視します。途中の値は hidden で保持し、最終ステップに確実に集約します。

同意（acceptance）チェックは 最終ステップにまとめ、直後に送信させる流れにすると安全です。

ステップ化アドオンは、CF7 本体・WP コア・jQuery との 互換リリースを満たしているかを作者のドキュメントで確認してください。問い合わせ関連 URL は キャッシュ除外し、Ajax が古いレスポンスや 304/403 で止まっていないかも比較します。

分割特有の問題かを切り分けるには、同じ項目で 単一ステップの最小フォームを作って比較するのがいちばん早道です。単一では届き、分割で消えるなら、引き継ぎ設計に原因が絞り込めます。

• ここだけ小さなメモ
  • name の不一致や hidden 不足は Form Data の抜けとして現れる
  • 中間ステップの acceptance は未同意扱いの温床
  • JS 最適化（結合/縮小/遅延）を一時停止し、初期化順序の崩れを疑う

解決方法1：確実に届く送信経路へ切り替える（SMTP／API送信）

「画面は送信成功なのに届かない」原因の多くは、PHPのmail()関数が“なりすまし寄り”に見えることに起因します。

ここを認証つきの送信経路（SMTPまたは各社のAPI）へ切り替えるだけで、迷惑判定やブロックが大幅に減り、配信ログで状況も追えるようになります。CF7の設定だけ直す対症療法から卒業し、送信経路そのものを健全化するのがこの章の目的です。

WP Mail SMTPでPHP mail()から卒業する

狙いは、wp_mail()が内部で呼ぶ送信エンジンを、mail()依存からSMTP/APIメーラーへ置き換えること。

mail() 依存だとホスティングしているサーバー環境で提供されているメール送信機能に頼る運用になるため、失敗ログが確認できない問題やサーバーによっては送信の抜けやが発生してしまいます。

置き換えることにより、送信者認証（USER/PASSやAPIキー）、TLS暗号化、レピュテーション管理、配信ログが使えるようになります。

導入の流れ（要点）

1. プラグイン導入 → セットアップウィザードを起動。
2. メーラー選択はAPI対応が第一候補（SendGrid/Mailgun/SES など）。SMTPでも構いませんが、APIは接続・認証が安定しやすく、Return-Pathの扱いも整えやすい傾向です。
3. Fromメールをサイトの独自ドメインの実在アドレスに設定し、「Fromを強制（Force From）」を有効化。運用上は noreply@yourdomain.jp のような専用アドレスを推奨します。
4. 「Return-Pathを設定」を有効化（後述の整合に重要）。
5. ウィザード最後のテストメールで、Gmail/Outlook/社内メールなど複数宛に到達を確認。

うまくいかない時の代表パターン

• APIキーやSMTP認証情報のコピーミス／余計な空白。
• Fromが存在しないメールアドレス（受信箱の実体がない）で信頼度低下。
• 既存プラグインがwp_mail()を横取りしている（セキュリティ・最適化系）→一時停止で比較。

設定直後は、件名・本文をプレーンテキストでシンプルにして検証すると、判定の純粋な比較がしやすくなります。

Return-Path整合とテスト送信で到達を検証する

Return-Path はバウンス（不達通知）の返送先で、受信側の迷惑判定でもFromとの整合が重視されます。WP Mail SMTPの「Return-Pathを設定」を有効にし、Fromと同じドメインになるように整えます。

検証のしかた

1. テスト送信後、受信側で生ヘッダー（オリジナル）を表示。
2. Return-Path: と From: のドメイン一致を確認。
3. Authentication-Results: で spf=pass / dkim=pass / dmarc=pass を目視（DNS認証の章と連動）。

到達性の初期チューニングでは、リンクや外部画像を減らし、短いテキストのみで送ります。

これで届き、本番用のテンプレートで迷惑フォルダ行きになるなら、本文の要素やURL数が影響している可能性が高いです。

新規ドメインや送信再開直後は、短期間に大量送信しない（ウォームアップ）ことも到達率の安定に効きます。

SendGrid／Mailgun／SESの選び方と配信レポートの読み方

どのサービスでも大筋は同じですが、導入容易性・価格・レポートの粒度・サポートに違いがあります。まずは以下の観点で絞り込むと選びやすいです。

選定の軸

• 導入のしやすさ：APIキー発行、WP Mail SMTPの連携手順、DNSレコード案内の分かりやすさ。
• 到達率とレピュテーション：共有IPか、専用IPの選択が可能か（大規模配信時）。
• コストと上限：月間無料枠・従量課金の単価・上限超過時の扱い。
• 運用の面倒見：配信ログの見やすさ、抑止（ブロック）理由の可視化、アラート設定。

運用で絶対見るべきレポート項目

• Delivered / Bounced / Blocked / Deferred：配信の到達状況。特にBounced/Blockedの内訳と理由は要確認。
• Spam Report / Unsubscribe：ユーザー反応。スパム報告が増えると到達率低下に直結。
• ドメイン別の傾向：Gmail/Outlook/携帯キャリアなど、受信側ごとの偏りを把握。件名・本文・差出人で小さくA/Bテストする。

サービスごとのざっくり特徴（超要約）

• SendGrid：WordPress連携が容易。UIのレポートが見やすく、通知連携もしやすい。
• Mailgun：開発者フレンドリーでログが細かい。地域（US/EU）の切り替えやドメイン運用が柔軟。
• Amazon SES：コストが魅力。最初は制限（いわゆるサンドボックス）があるため、解除申請や送信量の段階的拡大など運用設計が鍵。

いずれを選んでも、DNS認証（SPF/DKIM/DMARC）を正しく整えること、From／Return-Pathの整合を取ることが前提です。

CF7側はFrom＝独自ドメインの実在アドレス／Reply-To＝ユーザー入力に統一し、WP Mail SMTPのテストメール→本番テンプレの順で一段ずつ到達を確認してください。

配信ログを“結果の事実”として常時参照できるようにしておくと、トラブル時の切り分けが圧倒的に速くなります。

解決方法2：迷惑判定を回避する送信ドメイン認証を整える（SPF／DKIM／DMARC）

到達率を根本から安定させるには、「誰が、どのドメインとして送っているか」を受信側に正しく伝える必要があります。ここで中核になるのが SPF・DKIM・DMARC。

SPFは「このサーバー（またはサービス）はこのドメインから送って良い」を宣言し、DKIMは「このドメインが秘密鍵で署名した改ざん検知」を提供し、DMARCは「SPF/DKIMとFromの整合（Alignment）が取れていれば受信許可、ダメならどう扱うか」を決めます。

この章では、Alignmentを満たす設定→DMARCの段階導入→落とし穴の潰し込みという順番で、実務的な手順を整理します。

SPF／DKIMのAlignmentを満たす設定手順

最初のゴールは、受信ヘッダーの Authentication-Results: に spf=pass と dkim=pass が並び、かつ Header From（表示上の差出人ドメイン）とSPF/DKIMの認証ドメインが一致（または同一組織内） している状態です。

1. Header Fromを決める（独自ドメインの実在アドレス）
   CF7のFromは noreply@yourdomain.jp のように、サイトの独自ドメインで実在するアドレスに統一します。以降のSPF/DKIM/DMARCはこのドメインを基準に整備します。
2. SPF（TXT）を1本で管理し、送信経路を宣言する
   DNSに TXTレコードを1つだけ 用意します（複数作らない）。外部サービスを使うなら include: を追加し、最終は -all（厳格拒否）を基本にします。
   例： yourdomain.jp. IN TXT "v=spf1 include:sendgrid.net include:_spf.google.com -all" 運用ポイントは 「10回までのDNSルックアップ制限」 と 重複includeの整理。複数サービス併用時は無秩序に増やさず、送信経路を絞るのが安全です。
3. DKIMを有効化し、署名ドメインをHeader Fromに揃える
   送信サービス側でDKIMを有効化し、指示通りに CNAME/TXT（セレクタ付き） を追加します。鍵は 2048bit を推奨。
   例（CNAME方式の一例）： s1._domainkey.yourdomain.jp. IN CNAME s1.domainkey.u123456.wl.sendgrid.net. s2._domainkey.yourdomain.jp. IN CNAME s2.domainkey.u123456.wl.sendgrid.net. メールヘッダーの DKIM-Signature: を開き、 d=yourdomain.jp（＝Header Fromと同じ組織）で署名されていることを確認します。
4. Return-Path（エンベロープFrom）も整える（SPFの素性合わせ）
   SPFの判定は Return-Pathのドメイン で行われます。送信サービスの「カスタムリターンパス／バウンスドメイン」機能を使い、bounces@rp.yourdomain.jp のように 自ドメイン配下 に統一します（CNAMEで委任する方式が一般的）。
   これで Header From と SPF・DKIM の整合（Alignment） が取りやすくなります。

DMARCを p=none から段階導入し運用レポートで調整する

SPF/DKIMが安定して pass を出せるようになったら、DMARCで 「整合していないメールの扱い」 を宣言します。

いきなり強制すると正当な送信が誤判定される可能性があるため、段階導入が鉄則です。

• 第1段階（観測期間）：p=none で影響ゼロ運用。
  例： _dmarc.yourdomain.jp. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.jp; fo=1; aspf=r; adkim=r" rua で集計レポートの送付先を指定します（受信は大量になるので、専用アドレスか集計サービス推奨）。aspf/adkim の r は relaxed（緩い整合）。まずは緩めで実態を把握します。
• 第2段階（軽い介入）：p=quarantine（隔離）＋ pct=25 などで適用率を段階的に上げる。 "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@...; fo=1; aspf=s; adkim=s" レポートを見ながら、送信元の取りこぼし（SaaSの不備、旧経路、部門ごとの独自送信） を潰し、pct を 50 → 100 へ。
• 第3段階（本施行）：p=reject で不正（整合不良）メールを受信側に拒否してもらう。
  ここまで来たら BIMI（ブランドアイコン）も検討できますが、BIMIは p=quarantine 以上が前提です。

ポイントは 「レポートを見て直す→段階を上げる」 の反復です。ruf（フォレンジック）レポートは個人情報が含まれる場合があるため扱いに注意してください（まずは rua の集計レポートで十分です）。

よくある失敗（include漏れ／優先度ミス／二重設定）を潰す

SPF・DKIM・DMARCは「書いたつもり」で微妙な不一致が続き、迷惑判定から抜け出せないことが多いです。下記を点検して、確実に“そろえる”ことに集中しましょう。

• SPFの二重TXT
  SPFは1レコードのみ有効です。v=spf1 ... が 二つ以上 あると fail 同然。すべてを一つに統合し、include: の重複や無関係な経路を削除します。~all（softfail）で運用を続けるより、経路を厳選して -all に寄せた方が判定は安定します。
• 10ルックアップ超過
  include: の連鎖や a/mx が多いと 10回のDNSルックアップ上限に達します。併用サービスを整理し、必要最小限に。上限対策での“SPFフラッテン”は運用負荷が増えるため、送信経路の集約が先です。
• DKIMセレクタ／CNAMEのタイプミス・プロキシ化
  s1._domainkey のつづり違い、CNAME先ホストのミス、CDNの プロキシ（例：オレンジクラウド）有効でDKIMが解決できない、といった凡ミスが多発します。プロキシは無効（DNSのみ） にして、正しく委任されているかを再確認します。鍵長は 2048bit 推奨。
• Return-Pathが他社ドメインのまま
  SPFの判定主体は Return-Path のドメインです。SendGrid等では「カスタムバウンスドメイン」を有効にし、rp.yourdomain.jp のように 自ドメインへブランド化 して整合させます。
• DMARCの場所／書式ミス
  ホスト名は _dmarc.yourdomain.jp。TXT内容は ダブルクォーテーションで1行 にし、余計な全角や改行を入れない。sp=（サブドメイン方針）や pct= の指定漏れも方針ブレの原因になります。
• Header Fromと認証ドメインの不一致（Alignment未達）
  送信サービスによってはデフォルトで他社ドメイン署名・他社Return-Pathになります。カスタムDKIMとカスタムReturn-Pathを有効化し、d=（署名ドメイン）とReturn-Pathを自ドメイン配下に統一してからヘッダーで dmarc=pass を確認しましょう。

最後は必ず 実メールの生ヘッダーで「結果」を見る こと。

spf= / dkim= / dmarc= の3つが pass、かつ Fromと署名／Return-Pathのドメインが組織として揃っている ことが到達率の土台です。

設定を書いたら、Gmail／Outlook／社内メールなど複数宛にテストし、同じ結果が再現するまで微調整を続けてください。

解決方法3：分割フォームの送信漏れをゼロにする（multi-stepの設計チェック）

分割フォームは、入力体験を良くする一方で値の受け渡し・最終ステップの整合・Ajaxとキャッシュの相性など、単一ステップにはない落とし穴が増えます。

ここでは「入れた値が最終メールに必ず載る」ことを最優先に、設計と検証の手順を整理します。方針はシンプルです。

1. 同じ名前（name）で最後まで運ぶ
2. 最終ステップで同意→送信を完結
3. Ajaxとキャッシュをぶつけない

この3点を満たすだけで、分割固有の“消える・届かない”は劇的に減ります。

ステップ間のname不一致をなくしhiddenで値を確実に渡す

分割での不達の大半は「途中の項目名（name）が最終ステップとズレている」「最終リクエストに値が載っていない」が原因です。

設計時は最終メールで使うタグ＝全ステップで使うnameと決め打ちし、途中で別名に変えないのが鉄則です。フォームプラグインやアドオンの都合で別名を強いられる場合は、最終ステップに“本名”の hidden を用意してマッピングします。

• 例（考え方）：
  • ステップ1：name="your-name"
  • ステップ2（最終）：<input type="hidden" name="your-name" id="cf7-final-your-name">
  • 画面遷移やステップ切替時に、ステップ1の値を #cf7-final-your-name へ代入（アドオンに引き継ぎ機能があればそれを優先）。
  • 最終メールテンプレートでは [your-name] のみを使用（[step1-your-name] のような別名は使わない）。

検証はブラウザの開発者ツールで行います。最終送信の Network → Form Data を開き、“最終メールで使うnameがすべて載っているか”を目視します。ここで欠けている値は、メールにも載りません。

確認画面（要約）を挟む設計なら、要約で全項目が表示されるかも必ずチェックしましょう。表示されない＝最終送信にも載らない、のシグナルです。

最終ステップで同意と送信を完結させるレイアウトにする

acceptance（同意）チェックや規約同意を中間ステップに置くと、最終送信時に未同意扱いで落ちることがあります。レイアウトは「最終ステップで同意 → 即送信」が安全です。

また、バリデーションは最終ステップで再評価される前提で設計し、各ステップでの暫定チェックはユーザー補助に留めます。最終メールに採用するタグは、最終ステップで必ず存在する入力または hidden で用意してください。

実装のコツとして、最終ステップ手前に確認画面（入力要約）を置くと、空欄や取りこぼしをユーザー側で発見しやすく、送信前のやり直しもスムーズです。要約には最終メールで使うのと同じタグ（name）を差し込み、入力と出力の“名前合わせ”を常に意識します。

Ajax×キャッシュ除外／アドオン互換・バージョン整合を検証する

分割フォームは多くが Ajax で値を繋ぎます。

ここにページキャッシュや最適化（縮小・結合・遅延読み込み）が噛むと、古いHTML/JSが残る・nonceが失効する・初期化順が崩れるなどで最終送信が不安定になります。

問い合わせ関連のURLはキャッシュから除外し、CDNの自動最適化もまずは無効化して比較テストしてください。

アドオン側は、CF7本体・WordPressコア・jQuery と互換のあるバージョンを必ず揃えます。

作者のリリースノートで互換範囲を確認し、サイト側の JS 最適化（結合/遅延/Defer）と競合していないかを見ます。初期化順序が重要なアドオンでは、CF7初期化 → アドオン初期化の順を崩さない設定がカギです。

最後に、単一ステップの最小フォームで同じ項目を送って届くかを比較してください。

単一では届くのに分割で消えるなら、原因は引き継ぎ設計 or アドオン／キャッシュの相性に絞り込めます。Network の Form Data と画面の要約（確認画面）で“最終的に何がサーバーへ渡っているか”を可視化できれば、分割特有の送信漏れは着実に潰せます。

運用の安定化と再発防止

問い合わせメールは「一度届けば終わり」ではありません。

WordPress・送信サービス・受信側のポリシーは継続的に変化するため、常時監視 → 変化の検知 → 小さな修正の積み重ねが到達率の土台になります。ここでは、日々の監視、改修時の再テスト、送信ドメインのレピュテーション維持という3つの柱で、運用が回り続ける状態をつくります。

送信ログ（WP Mail Logging）と受信履歴（Flamingo）の常時監視

まずは「見えているか」を担保します。WP Mail Logging（または Check & Log Email）で wp_mail() の成功/失敗・エラー内容・宛先・ヘッダーを記録し、FlamingoでCF7経由の受信履歴（本文・差分・対応状況）を残します。

ログが取れていれば、障害時に「どこで止まったか」を即断できます。

• ログ方針
  • 保持期間を決める（例：30〜90日）。個人情報を含むため、自動削除を有効に。
  • 成功/失敗の比率、失敗時のエラーコード（5xx/4xx）を定点観測。
  • 個人情報の扱いはプライバシーポリシーに明記し、権限ロールで閲覧を制限。
• しきい値と検知
  • 直近24時間で連続失敗（例：3件以上）、または失敗率1%以上で運用者に通知。
  • 自動返信（メール2）が特定ドメインで急に迷惑行きになったら、本文・件名・リンク数を要確認。
• 簡易ヘルスチェック
  • 1日1回の定時テスト送信（Gmail/Outlook/社内メールの3宛先）。どれかが未着なら即調査。
  • 送信サービス側（SendGrid/Mailgun/SESなど）のイベントログも朝イチ確認をルーチン化。

改修時のリグレッションテスト（宛先別・環境別）を定例化

テーマ更新、プラグイン追加、CDN設定変更、フォーム改修――なにかを変えたら必ず再テスト。テストは「誰宛に」「どの環境で」「どのテンプレートで」を固定化したチェックリストに落とし込みます。

• テストの粒度
  • 宛先別：Gmail / Outlook（Microsoft） / 代表的な社内ドメイン / 可能なら携帯キャリア。
  • 環境別：本番（必須）＋ステージング。CF7のID・SMTP設定・ドメインが環境でズレていないかを確認。
  • テンプレート別：管理者通知 / 自動返信（メール2） / 添付あり無し / URL多め少なめ。
• 合格条件の例
  • すべての宛先で受信トレイ or 重要タブに到達（初期は迷惑でも、設定変更で回復するかも確認）。
  • 受信ヘッダーで spf=pass / dkim=pass / dmarc=pass、Return-Path と From のドメイン整合を目視。
  • CF7の送信結果メッセージ・Flamingo履歴・WP Mail Logging成功が揃う。
• 改修頻度の現実解
  • 定例アップデート（例：毎月第1水曜）は実施→リグレッション→到達確認までを1セット。
  • 大型更新（メジャーアップデート、CDN切替）は事前にステージングで2日運用し、実装順に差分確認。

レピュテーション維持（送信量・差出人統一・自動返信の設計）

受信側は「このドメインからのメールは健全か」を継続的に評価しています。

送信量の急増、差出人のコロコロ変更、スパムに見える自動返信は、評価を落とす典型です。日々の運用で、以下の衛生管理を徹底します。

• 送信量のコントロール
  • 新規ドメインやIPはウォームアップ（少量から徐々に増やす）。
  • キャンペーンやバッチ送信は分散し、短時間の集中送信を避ける。
  • Bounced/Blocked が増えたら件名・本文・URL数・画像の簡素化でまず切り分け。
• 差出人の統一
  • From名/Fromアドレスは固定（例：お問い合わせ <noreply@yourdomain.jp>）。
  • Reply-To にユーザー入力を一貫適用。部署別や担当者名でFromを乱立させない。
  • 送信ドメインは1つに集約し、SPF/DKIM/DMARCは常にAlignmentを維持。
• 自動返信（メール2）の作法
  • 短く・簡素に・URL最小限。初回はプレーンテキストを基本に、到達確認後に装飾を足す。
  • スパム増加時は件名の絵文字/過剰強調/短縮URLを避ける。
  • 同一ユーザーへの短時間連続自動返信を抑制（重複送信の防止、レート制限）。
  • スパム流入を抑えるため、Turnstile/reCAPTCHAやキーワードフィルタ、添付禁止を検討。
• ドメイン健全性の点検
  • Authentication-Results が常に pass×3（SPF/DKIM/DMARC） になるかを月次で抜き取り確認。
  • ブラックリストや**逆引き（PTR）**の異常がないか、送信サービスのヘルスダッシュボードを巡回。
  • 送信サービス側で専用IPを使う規模なら、逆にIPのウォームアップ/維持も運用タスクに含める。

この3本柱（常時監視／再テストの定例化／レピュテーション維持）を回し続けることで、単発の不達を都度直すのではなく、“届き続ける仕組み”が育ちます。

トラブルはゼロにできませんが、検知が早ければ影響は最小化できます。到達の成否をデータで把握し、小さく直す――それが安定運用の最短ルートです。

まとめ

「Contact Form 7で届かない」を確実に解消するには、どこで止まっているかを素早く特定し、送信経路とドメイン認証を正しく整えることが核心です。

まずはフロントのエラーやキャッシュ・reCAPTCHAの影響を外し、Flamingoと送信ログで「フォーム→WP→配送」の層別切り分けを行います。

次に、From＝独自ドメイン／Reply-To＝ユーザーに統一し、WP Mail SMTPでSMTP/API送信へ切り替えます。

あわせてSPF/DKIM/DMARCとReturn-Path整合を満たせば、迷惑判定は大きく減少します。

multi-stepフォームでは、nameの統一・hiddenでの値引き継ぎ・最終ステップ完結を守るだけで、分割特有の送信漏れをほぼ撲滅できます。

最後に、送信ログ・受信履歴の常時監視、改修時のリグレッションテストの定例化、レピュテーション衛生管理を回し続ければ、「届き続ける仕組み」へ移行できます。

最短で動かすための再確認ポイントは次の3つです。

1. 切り分け：Flamingo・送信ログで層を確定（フロント／WP内／配送）。
2. 送信経路：WP Mail SMTPでAPI/SMTPへ、From/Reply-Toを正規化、Return-Path整合。
3. 認証と運用：SPF/DKIM/DMARCをAlignment付きで整備し、ログ監視と再テストを継続。

参照リンク・参考リンク

• 公式ドキュメント
  • Contact Form 7 Docs：https://contactform7.com/docs/
  • Flamingo（受信履歴プラグイン）：https://ja.wordpress.org/plugins/flamingo/
  • WP Mail SMTP（送信経路のSMTP/API化）：https://ja.wordpress.org/plugins/wp-mail-smtp/
• 到達性ガイドライン・認証
  • Gmail 送信者ガイドライン：https://support.google.com/a/answer/81126
  • Microsoft（Outlook）受信ポリシー：https://learn.microsoft.com/exchange/antispam-and-antimalware/mail-flow-guidance
  • DMARC.org：https://dmarc.org/
  • BIMI（ブランドアイコン）：https://bimigroup.org/
• 送信サービス（参考）
  • SendGrid Docs：https://docs.sendgrid.com/
  • Mailgun Docs：https://documentation.mailgun.com/
  • Amazon SES Docs：https://docs.aws.amazon.com/ses/latest/dg/
• 検証・運用に役立つツール
  • メールヘッダー解析（Gmailの「オリジナルを表示」機能 等）
  • MXToolbox（DNS・ブラックリスト確認）：https://mxtoolbox.com/
  • Cloudflare Turnstile（スパム防御）：https://www.cloudflare.com/products/turnstile/