フォーム送信時に「送信エラー」が出て先に進めないとお困りではありませんか。
原因はブラウザやネットワーク、JavaScriptエラー、reCAPTCHA設定やSMTP、プラグイン・テーマの競合、サーバー制限など多岐にわたり、放置すると機会損失や信頼低下につながります。
この記事では原因ごとの確認方法と5分で試せる優先対応、サーバーやContact Form 7固有の対処、ログの見方まで即効で使える手順を分かりやすく解説します。
まずは環境確認とキャッシュ削除などの簡単な初動から、ブラウザ開発者ツールやPHPログ、SMTPテストといった詳細確認まで順を追って案内します。
手順に沿えば原因の切り分けが短時間でできるので、次章から順に確認して問題を素早く解決しましょう。
メッセージの送信に失敗しました。後でまたお試しください。表示時の原因と即効対応
Contact Form 7で「メッセージの送信に失敗しました。後でまたお試しください。」と表示されたとき、原因は多岐にわたります。
ここでは環境確認から即効で試せる対処まで、順にわかりやすく解説します。
環境確認
まずは問題が発生している環境を整理してください。
ブラウザ、OS、WordPressとプラグインのバージョンを控えておくと後の切り分けが楽になります。
ブラウザのキャッシュ
ブラウザのキャッシュが古いスクリプトを読み込んでいる可能性があります。
キャッシュをクリアして、同じ現象が再現するか確認してください。
JavaScriptエラー
フロントでJavaScriptエラーが起きると送信処理が止まることがあります。
開発者ツールのコンソールで赤いエラーが出ていないか確認してください。
reCAPTCHA設定
reCAPTCHAのキーが正しく設定されていないと送信がブロックされます。
サイトキーとシークレットキーが合っているか、対応するバージョンを確認してください。
SMTP設定
サーバー標準のメール送信が失敗する場合、SMTP経由に切り替えると改善することが多いです。
SMTPプラグインで認証情報が正しいか、送信ポートが開いているか確認してください。
送信先メールアドレス
送信先が存在しないアドレスや転送設定が誤っていると配信に失敗します。
管理者メールを自分宛に変更してテスト送信してみてください。
プラグイン競合
別プラグインがフックを乗っ取り、送信処理を阻害することがあります。
一時的にプラグインを無効化して再現を確認してください。
テーマ競合
テーマのJavaScriptやテンプレートがフォーム動作に影響する場合があります。
デフォルトテーマに切り替えて挙動が変わるか確認してください。
サーバー制限
ホスティング側の送信数制限やプロセス制限で送信が弾かれるケースがあります。
1時間あたりのメール送信上限や同時接続数を確認しましょう。
サーバーログ確認
サーバーログには原因特定のヒントが豊富にあります。
| ログ名 | 見るべきポイント |
|---|---|
| Apache error log | 500エラーやPHP致命的エラー |
| PHP error log | 未定義関数や例外 |
| Mail log | 送信エラーコード |
テスト送信
フォーム以外の方法でメール送信が可能かを検証します。
WPのメールテストプラグインやtelnetでSMTP接続を試してください。
一時的回避策
優先的に使える簡単な逃げ道をいくつかご紹介します。
- 管理者メールを別アドレスに変更してテストする
- reCAPTCHAを一時的に無効化する
- SMTPプラグインで強制送信する
- プラグインを一つずつ無効化して競合を切り分ける
5分で試せる優先対応手順
急いで原因を切り分けたいときに有効な短時間でできる対応をまとめます。
順番に試すだけで、原因の見当を付けやすくなります。
まずは簡単に確認できる項目から手を付けてください。
フォーム保存と再読み込み
管理画面でContact Form 7のフォーム編集画面を開いて、何も変更せずに一度保存してください。
保存によって設定キャッシュや内部のトークンがリフレッシュされることがあります。
公開ページに戻り、ブラウザで強制リロードを実行してください。
WindowsならCtrl＋F5、MacならShift＋リロードボタンで完全再読み込みが可能です。
キャッシュ削除
ブラウザやサイトのキャッシュが古いままになっていると、送信処理がうまく動かないことがあります。
まずはローカルとサーバー側のキャッシュをクリアしてください。
- ブラウザキャッシュの削除
- サイトキャッシュのパージ
- CDNキャッシュのクリア
- オブジェクトキャッシュのクリア
キャッシュをクリアしたら再度フォーム送信をお試しください。
プラグイン無効化テスト
他プラグインとの競合が疑われる場合は、影響範囲を特定するために一時的に無効化テストを行ってください。
まずはキャッシュ系やセキュリティ系のプラグインを優先的に無効化してください。
すべてをいったん無効化するのが不安なら、ステージング環境で一つずつ無効化して原因を特定する方法が安全です。
無効化後はページを再読み込みして、送信の動作を確認してください。
reCAPTCHAキー確認
Contact Form 7でreCAPTCHAを使用している場合は、サイトキーとシークレットキーが正しく設定されているか確認してください。
キーが間違っていたり、ドメイン制限が設定されていると検証に失敗しますので、管理画面で設定を見直してください。
必要に応じてGoogleの管理画面からキーを再発行して、再設定してみてください。
SMTPでのテスト送信
送信がサーバー側のメール送信に起因するかを切り分けるために、SMTPプラグインで直接送信テストを行ってください。
一般的な設定の目安を下表に示しますので、プロバイダの情報に合わせて確認してください。
| 項目 | 推奨設定 |
|---|---|
| サーバー | smtp.example.com |
| ポート | 587 |
| 暗号化 | TLS |
| 認証 | 必要 |
SMTPテスト送信で成功すれば、WordPressのメール処理が原因でないことが確認できます。
ブラウザ開発者ツール確認
ブラウザの開発者ツールを開き、コンソールとネットワークタブでエラーを確認してください。
JavaScriptのエラーやContact Form 7のXHRが400や500で返っていないかを重点的に見てください。
ネットワークでエラーが出ている場合は、エラーメッセージを控えてサーバーログと照合すると手がかりになります。
問題箇所が絞れない場合は、画面のスクリーンショットやログを取り、開発者やホスティングに提示してください。
原因別の詳細確認方法
メッセージ送信に失敗したときは、原因を絞り込むために段階的に確認することが近道です。
ここではブラウザ側からサーバー側まで、ログやツールを使った詳細な確認方法を解説します。
ブラウザ開発者ツール
まずはブラウザの開発者ツールを開いて、コンソールとネットワークタブを確認してください。
JavaScriptのエラーやreCAPTCHAの読み込み失敗が出ていないか、まずそこをチェックします。
ネットワークタブのXHRを使ってフォーム送信時のリクエストとレスポンスを確認すると、多くの原因が分かります。
確認ポイントを一覧でまとめます。
- コンソールエラー
- XHRリクエスト
- レスポンス本文
- ステータスコード
特にレスポンスにJSONでエラーメッセージが含まれている場合は、その文言を手掛かりに次の調査先を決めます。
PHPエラーログ
サーバー側のPHPエラーログは致命的な問題を示す最初の手掛かりになります。
ホスティングのコントロールパネルや/var/log配下など、ログの保存場所を確認してください。
エラーログではFatalやWarningなどのキーワードで絞り込むと見つけやすいです。
送信時間とログのタイムスタンプを照らし合わせて、該当のエントリを特定してください。
メモリ不足や関数未定義などの致命的エラーが出ていれば、それが直接の原因です。
Mailログ
送信処理がサーバーから実際に出たかどうかはMailログで確認できます。
以下の表は確認すべき項目と見方の目安です。
| チェック項目 | 見方 |
|---|---|
| 送信履歴 | 送信日時 送信者 |
| 送信ステータス | delivered bounced |
| SMTP応答 | ステータスコード エラーメッセージ |
ログに250などの成功コードがあれば外部配信側までは届いています。
550や421などのエラーがあればリレー拒否や受信側の問題を疑います。
サーバー内でメールがキューに溜まっていないかも合わせて確認してください。
Flamingo保存確認
Contact Form 7を使っている場合、Flamingoが有効なら投稿内容がDBに保存されます。
Flamingoにデータがあるか確認すれば、フォームがサーバーに到達したかどうかが分かります。
保存があるのにメールが届かない場合は、送信処理やSMTPまわりの問題が疑われます。
逆にFlamingoにも保存がなければ、フロントエンドやJavaScriptの問題を優先的に調べてください。
WP_DEBUG確認
問題の切り分けにはWP_DEBUGの一時的な有効化が有効です。
wp-config.phpでWP_DEBUGをtrueにし、WP_DEBUG_LOGを有効にしてから再現テストを行ってください。
wp-content/debug.logに出力された内容を見れば、プラグインやテーマからの警告やエラーが見つかります。
調査が終わったら必ずWP_DEBUGをfalseに戻し、ログの公開を避けてください。
ネットワークログ（XHR）
ネットワークタブのXHRではリクエストヘッダーとレスポンス本文が直接確認できます。
送信時のHTTPステータスコードを見て、200以外ならそのコードに応じた対処を考えます。
レスポンスがJSONの場合はmail_sentやmail_failedなどのフラグを確認してください。
CORSエラーや事前検証で失敗しているケースもあり、レスポンスヘッダーのAccess-Controlをチェックすると手掛かりになります。
またファイル添付がある場合は、リクエストサイズやタイムアウトにも注意してください。
Contact Form 7固有の設定チェック
Contact Form 7で「メッセージの送信に失敗しました」と表示される場合、フォーム側の設定ミスが原因のことが多いです。
設定項目は細かく、見落としで送信が止まることがあるため、順を追って確認すると解決が早まります。
メールタグ
フォームの入力タグとメールテンプレート内のメールタグが一致しているかをまず確認してください。
名前やメールアドレスのタグが異なると、CF7は期待通りの値を取得できません。
特にファイル添付や配列で返るタグは、記述ミスに弱いため注意が必要です。
- your-name
- your-email
- your-subject
- your-message
- file-attachment
メールタグは角括弧で囲まれる表記になっているため、コピーペースト時の余分な空白や記号に気をつけてください。
送信元アドレス
送信元アドレス（From）は最もトラブルになりやすい設定の一つです。
外部のフリーメールアドレスをそのままFromに使うと、送信先サーバーで拒否される場合があります。
推奨はサイトドメインに属するメールアドレスをFromに設定することです。
もしユーザー入力のメールを返信アドレスにしたい場合は、Reply-Toヘッダーに設定する方法を検討してください。
追加ヘッダー
追加ヘッダー欄にはReply-ToやCc、Bccなどを指定できます。
ここに不正な値や未定義のタグを入れるとメール送信が失敗します。
Reply-Toにユーザー入力のメールを入れる場合は、メールタグが正しく動作しているかテストしましょう。
Return-Pathを設定する場合はホスティングの仕様も確認してください。
ファイル添付設定
ファイル添付の設定ミスはエラーに直結しやすいため、容量や拡張子の確認が重要です。
サーバーのアップロード上限とフォームで指定した最大値が合っているか確認してください。
| 設定項目 | 推奨設定 |
|---|---|
| 最大ファイルサイズ | 2MB |
| 許可ファイルタイプ | jpg png pdf |
| 添付方法 | メール添付 保存併用 |
大きなファイルや不正な拡張子は、メールサーバー側でブロックされることがあります。
必要ならば一時的に添付を外して動作確認を行ってください。
フォームタグの整合性
フォームタグのname属性とメールのメールタグが一致しているかを入念にチェックしてください。
同じnameを複数使っている場合や、required属性の抜けは送信エラーにつながります。
複雑なフォームでは、テキストエリアやチェックボックスの値が意図せず空になることがあるため、実際に入力して検証するのが確実です。
メール文面のプレースホルダ
メール本文や件名内に残っている未使用のプレースホルダはエラーや空欄の原因になります。
存在しないタグを参照している場合、CF7は空の値を送るか送信自体を止めることがあります。
テンプレートを更新したら、テスト送信で文面が期待通りに置換されるかを確認してください。
サーバーとメール配信の対処
フォーム送信がサーバー側で止まる場合、メールの配信設定を優先して確認する必要があります。
ここではSMTP導入からDNS設定まで、実務で使える具体的な対処法を順を追ってご説明します。
まずは手元で試せる項目を実行し、改善が見られない場合はホスティング側へ問い合わせる流れが基本です。
SMTP導入
WordPressの標準メール機能はサーバー依存で不安定になりやすく、SMTP経由に切り替えるのが最も確実です。
SMTPを導入すると送信元認証やログの取得が容易になり、配信成功率が高まります。
導入の手順は環境によって異なりますが、次のポイントを押さえてください。
- SMTPプラグインをインストール
- SMTPホストの情報を取得
- 認証方式とポートを設定
- テスト送信でログを確認
代表的なプラグインはWP Mail SMTPやPost SMTPなどで、どちらも設定画面で送信テストが実行できます。
外部メールサービス（GmailやSendGridなど）を使う場合はAPIや専用のSMTPサーバー情報を用意してください。
sendmail設定
sendmail経由での送信を利用しているサーバーでは、sendmailのパスや権限を確認してください。
PHPのmail関数が内部的にsendmailを呼び出す場合、設定が間違っているとメールがキューに入らないことがあります。
sendmailのログやキューをチェックし、エラーや再送試行が発生していないかを確認してください。
必要ならばsendmailの代わりにPostfixやEximといったMTAを導入し、より詳細なログ管理を行うと良いでしょう。
ポートとファイアウォール
SMTP接続に使用するポートがブロックされていると、WordPressから外部SMTPサーバーへ接続できません。
一般的に使用されるポートは25 465 587で、使用するサービスに合わせて開放する必要があります。
サーバー側のファイアウォールとホスティング側のネットワーク制限の両方を確認してください。
外部SMTPを使う場合は送信先のホストへ疎通確認をするため、telnetやncでポート接続を試してください。
メール送信制限（レート）
ホスティングによっては1時間や1日あたりの送信数が制限されており、超過すると送信が失敗します。
大量送信やテストを繰り返した場合、レート制限に達している可能性をまず疑ってください。
制限の種類には送信数制限と接続数制限があり、ログに「rate limit」や「quota exceeded」といった表示が出ることがあります。
必要な場合は送信上限の引き上げ申請や、外部配信サービスへの移行を検討してください。
SPF/DKIM設定
ドメイン認証が適切に設定されていないと、受信側で迷惑メール判定される可能性が高まります。
SPFとDKIMはDNSで設定する主要な認証方式で、送信元の正当性を担保します。
正しく設定されていれば配信成功率が上がり、相手先での受信も安定します。
| 項目 | チェック内容 |
|---|---|
| SPF レコード | TXT レコードに追加 |
| DKIM 鍵 | DNS に公開鍵登録 |
| DMARC 設定 | ポリシーの有無確認 |
DNS設定後は外部の検証ツールでレコードが反映されているか必ず確認してください。
自力で解決が難しい場合やログから原因が読み取れない場合は、ホスティングのサポートへ問い合わせるのが早いです。
問い合わせ時には発生日時、フォームのURL、使用しているプラグインや送信方法を明示してください。
サポート側でネットワークやMTAのログを確認してもらうことで、原因特定がスムーズになります。
また、サーバー側の変更が必要な場合は作業の見積もりや影響範囲について事前に相談することをおすすめします。
送信エラー発生時の優先判断基準
送信エラーが発生したら、まずは影響範囲と深刻度を確認してください。
フォームが全ユーザーに影響しているのか、一部の環境だけかを速やかに切り分けます。
再現手順の有無を明確にし、再現できる場合は詳細な操作手順の記録。
ログやブラウザのエラーメッセージを優先的に確認し、原因の手がかりを素早く探します。
業務に大きな支障が出る場合は、まず一時的回避策を適用してユーザーへの影響を抑えた上で、根本対処に移ります。
ホスティングやメール配信の制約が疑われるときは、必要な情報をまとめてサポートへ連絡してください。