WordPressでお問い合わせフォームを送信したのに通知が届かない、パスワード再設定メールが来ない、注文や予約のメールだけ抜ける。このようなメール不達は、サイト上では「送信完了」と表示されることも多く、気づかないまま問い合わせや商談の機会を逃しやすいトラブルです。
ただし、メールが届かない原因はWordPress本体だけにあるとは限りません。入力した宛先、迷惑メール判定、フォーム設定、送信元アドレス、サーバーのメール送信機能、DNSの認証設定、外部メールサービスの制限など、複数の経路を順番に確認する必要があります。
この記事では、初心者でも作業を広げすぎないように、受信側から送信側へ段階的に切り分ける方法を説明します。あわせて、SMTPを導入するべきケース、自分で直せる範囲、サーバー会社や制作会社へ依頼したほうがよい判断基準も整理します。
WordPressのメールは「送信処理」と「受信」が別もの
最初に知っておきたいのは、WordPressがメール送信処理を受け付けても、相手の受信箱まで届いたとは限らないことです。WordPressでは多くの通知に wp_mail() という仕組みが使われます。公式の開発者向け資料でも、関数が成功を返すのは送信方法がエラーなく処理されたことを示すだけで、受信者への到達を保証しないと説明されています。
メールは、WordPressからサーバーの送信機能へ渡され、送信先のメールサーバーで認証や迷惑メール判定を受け、最終的に受信箱へ入ります。途中で拒否、保留、迷惑メール振り分け、破棄が起きることがあります。そのため「フォームに完了画面が出たから問題ない」「テスト送信の画面で成功したから必ず届く」と判断するのは危険です。
参考: WordPress Developer Resourcesのwp_mail()解説
最初に確認するべき症状と影響範囲
いきなりプラグインを追加する前に、どのメールが、誰に、いつから届かないのかを整理します。症状の範囲によって、確認する場所が変わります。
特定の宛先だけ届かない
一つのメールアドレスだけ届かない場合は、受信側の迷惑メール判定、拒否設定、容量不足、アドレスの入力ミスなどを先に疑います。Gmailには届くが会社メールには届かない、またはその逆であれば、送信自体は動いていても、受信側のポリシーや送信ドメイン認証が影響している可能性があります。
特定のフォームや機能だけ届かない
お問い合わせフォームだけ届かない一方で、パスワード再設定メールは届く場合、WordPress全体の送信機能よりもフォーム側の設定を確認します。宛先、送信元、Reply-To、条件分岐、自動返信の有無、必須項目、スパム対策との競合が主な確認箇所です。
WordPressからのメールがすべて届かない
パスワード再設定、管理者通知、フォーム、自動返信などがすべて届かない場合は、サーバーのメール送信環境、SMTP設定、送信元ドメイン、セキュリティ制限を確認します。サイト移転やサーバー変更、ドメイン変更、メールサービス変更の直後なら、変更前後の設定差も重要です。
以前は届いていたのに急に届かなくなった
更新や移転の直後であれば、プラグイン設定のリセット、認証情報の期限切れ、DNS変更、送信サービスの利用上限、メールアカウントの停止などが考えられます。何も変更していないように見えても、外部メールサービスのトークン期限や受信側の判定基準が変わることがあります。発生日時の前後に行った作業を時系列で残してください。
安全に原因を切り分ける確認順序
メール不達は、確認順を決めないと設定を同時に変えてしまい、何が原因だったのか分からなくなります。次の順番で、一度に一項目ずつ確認するのが基本です。
宛先アドレスと受信箱を確認する
- 宛先アドレスに全角文字、空白、不要な記号が入っていないか
- 迷惑メール、プロモーション、隔離フォルダへ入っていないか
- 受信箱の容量が上限に達していないか
- 送信元アドレスやドメインを拒否していないか
- 転送先やメーリングリストの設定が止まっていないか
管理者用と利用者用で別の宛先を用意し、異なるメールサービスへテスト送信すると、受信側だけの問題かどうかを判断しやすくなります。実在する顧客のアドレスをテストに使わず、自社で管理できるテスト用アドレスを使いましょう。
WordPressの管理者メールアドレスを確認する
WordPressの「設定」にある管理者メールアドレスが現在使えるものかを確認します。アドレス変更時には確認メールへの操作が必要になる場合があります。古い担当者のアドレス、退職者のアドレス、閉鎖したドメインが残っていると、重要な通知を受け取れません。
ただし、フォームプラグインが独自の宛先を持っている場合、管理者メールアドレスを直すだけでは解決しません。WordPress全体の宛先と、各フォームの通知先は別々に確認します。
フォームの宛先と送信元を確認する
お問い合わせフォームでは、「To」「From」「Reply-To」を混同しやすい点に注意が必要です。Toは通知を受け取る自社アドレス、Fromはサイトが送信者として名乗るアドレス、Reply-Toは受信した通知へ返信するときの宛先です。
訪問者が入力したGmailや携帯メールのアドレスを、そのままFromに設定すると、サイトのドメインと送信元ドメインが一致せず、不正な差出人と判断されやすくなります。基本は、自分が管理するサイトと同じドメインのアドレスをFromにし、訪問者のアドレスはReply-Toへ設定します。フォームごとの仕様を確認し、項目名だけで判断しないでください。
別種類のWordPressメールを試す
フォーム通知だけでなく、管理者が安全に確認できるテストメールやパスワード再設定など、別経路のメールも確認します。ただし、ログイン中の管理者が不用意にパスワード変更を完了する必要はありません。目的はWordPress共通のメール経路が動いているかを分けることです。
フォームだけ失敗するならフォーム設定、すべて失敗するなら共通の送信経路というように、確認範囲を狭められます。テストの日時、宛先、件名、結果を記録すると、後でサーバーログやメールログと照合しやすくなります。
送信失敗の記録を確認する
利用中のSMTPプラグインやメールサービスに送信ログがある場合は、成功、失敗、保留、拒否の状態とエラーメッセージを確認します。ログが「送信成功」でも受信していないなら、その後の配送経路や受信判定を確認します。ログ自体が作られていないなら、フォームが送信処理を呼び出していない可能性があります。
メールログには宛先や本文などの個人情報が含まれることがあります。保存期間を必要最小限にし、管理者以外が閲覧できないようにしてください。トラブル解決のためにログを有効化した場合は、解決後の保持方針も決めます。
WordPressでメールが届かない主な原因
サーバーの標準メール送信機能が使えない
WordPressはサーバー側のメール送信環境を利用します。公式の管理者向け資料では、管理されたホスティングでは一般に問題になりにくい一方、自分で管理するサーバーにメール転送エージェントや関連環境がなければ、外部SMTPを設定しない限り送れないと説明されています。
レンタルサーバーでも、迷惑メール対策、送信数制限、国外接続制限、ポート制限、Fromアドレスの制限が設けられている場合があります。契約プランやサーバー会社によって異なるため、一般的な手順をそのまま当てはめず、公式マニュアルとサポートへ確認します。
参考: WordPress Advanced Administration HandbookのMail
送信元アドレスとサイトのドメインが合っていない
WordPressの標準的な送信元はサイトのドメインを使いますが、フォームやプラグインで外部ドメインのアドレスへ変更すると、送信サーバーがそのドメインを名乗る正当性を示せないことがあります。差出人を訪問者のアドレスにしない、存在しないアドレスを使わない、送信サービスで認証したドメインやアドレスを使うことが大切です。
SPF・DKIM・DMARCなどの認証が整っていない
受信側は、送信元ドメインになりすましたメールではないかを確認します。SPFは送信を許可するサーバー、DKIMはメールに付ける電子署名、DMARCは認証に失敗したメールの扱いや報告方針に関わります。これらはWordPress管理画面だけで完結せず、DNSと利用するメール送信サービスの両方で設定することがあります。
認証レコードを推測で追加すると、既存の業務メールや別サービスの配信へ影響するおそれがあります。すでにSPFレコードがある場合は、同じ種類のレコードを単純に増やさず、利用サービスの公式手順に沿って統合します。DNSを管理している会社や担当者が分からない場合は、自分で変更せず確認を依頼してください。
迷惑メール判定や受信拒否を受けている
メールが送信されても、本文、件名、送信頻度、送信元の評判、認証状態などによって迷惑メールへ振り分けられることがあります。WordPress公式のトラブルシューティングでも、迷惑メールフォルダやSPF・DKIMの確認が案内されています。
同じ内容を短時間に何度も送る、存在しない宛先へ送り続ける、フォームを第三者に悪用されると、送信元の信頼を損ねる可能性があります。届かないからとテストを連打せず、回数と宛先を限定してください。
参考: WordPress.org FAQ Troubleshooting
フォームやSMTPプラグインの設定が競合している
複数のSMTPプラグイン、メールカスタマイズ機能、セキュリティプラグインが同じ送信処理へ介入すると、送信元の書き換えや認証が重複することがあります。SMTP機能は原則として一つに絞り、既存プラグインに同等機能がないか確認します。
原因調査のためにプラグインを停止するときは、公開サイトで無計画に行わないでください。お問い合わせ、決済、会員登録などへ影響する可能性があります。バックアップと復元手段を確認し、可能なら検証環境で試します。
認証情報やAPI連携の期限が切れている
SMTPのユーザー名やパスワード、OAuth連携、APIキーには、変更、失効、権限不足が起こります。メールアカウントのパスワード変更後にWordPress側が古いまま、担当者アカウントの削除で連携が無効、送信ドメインの認証が未完了というケースもあります。
認証情報をチャット、メール本文、作業報告書へそのまま貼らないでください。制作会社へ依頼するときも、権限を限定した作業用アカウントや安全な共有手段を使い、完了後に不要な権限を削除します。
SMTPを導入するときの考え方
SMTPはメール配送に使われる仕組みです。WordPressの送信を、認証されたSMTPサーバーやメール配信サービスへ接続することで、サーバー任せの送信より経路を管理しやすくなります。ただし、SMTPプラグインを入れるだけで必ず届くわけではありません。接続先、認証、送信元、DNS、受信側判定まで整える必要があります。
SMTP導入が向いているケース
- お問い合わせや予約など、取りこぼしが売上や対応品質に直結する
- 標準のメール送信では不達が繰り返されている
- 送信履歴や失敗理由を管理したい
- 複数の担当者で通知状況を確認したい
- サイト移転後も安定した送信経路を維持したい
接続方法を選ぶ比較ポイント
選択肢には、レンタルサーバーのメールアカウント、Google WorkspaceやMicrosoft 365などの業務メール、トランザクションメール向け配信サービスなどがあります。比較するときは、月間送信数だけでなく、認証方式、ログ、障害時の通知、再送、送信ドメイン認証、日本語サポート、複数サイトの管理、個人情報の扱いを確認します。
無料枠や料金、送信上限は変更されるため、導入時点の公式情報で確認してください。現在の送信数が分からない場合は、問い合わせ、会員通知、注文、管理通知を分けて概算し、繁忙期の増加も見込みます。
SMTPプラグインを選ぶ比較ポイント
- 利用するメールサービスの公式APIまたは認証方式に対応しているか
- 最終更新、対応WordPress版、サポート状況を確認できるか
- 送信ログの内容と保存期間を管理できるか
- パスワードをデータベースへ直接保存しない方法があるか
- 障害時の予備接続や通知が必要か
- 既存フォームやECプラグインとの動作実績を確認できるか
WordPress.orgの公式プラグインディレクトリには複数のSMTP関連プラグインがあります。人気だけで決めず、自社が使う送信サービスと必要機能を先に決め、その条件に合うものを選びます。カテゴリを増やすような感覚で複数導入するのではなく、送信経路を一つに整理することが重要です。
自分で設定するときの安全な進め方
変更前の状態を記録する
WordPress、フォーム、SMTP、DNS、メールサービスの現在値を記録します。パスワードやAPIキーそのものは記録資料に貼らず、どこで管理しているかだけ残します。サイト全体のバックアップと、元の設定へ戻す手順も確認します。
送信元アドレスを決める
サイトのドメインで管理できる送信専用または通知用アドレスを用意します。受信可能なアドレスにするか、返信を受けない運用ならReply-Toを明確にします。フォーム訪問者のアドレスはReply-Toへ渡し、Fromとして使わないのが基本です。
送信サービス側の認証を完了する
利用サービスの公式手順に従い、アカウント、送信元、ドメイン、必要なDNSレコードを設定します。DNSの反映には時間差があるため、同じ値を何度も変更しないでください。認証済みと表示されるまで待ち、失敗時はレコード名、値、重複の有無を確認します。
WordPress側は一つの送信経路に絞る
SMTPプラグインまたは既存サービスの連携機能を一つ選びます。古いSMTPプラグインが有効なままなら、設定の重複を避けます。ただし、公開サイトで停止する前に、どの機能がそのプラグインへ依存しているか確認してください。
少数のテストで到達を確認する
管理できる複数ドメインの宛先へ、件名を変えて少数ずつ送ります。テスト送信、フォーム通知、自動返信など種類を分け、受信箱、迷惑メール、送信ログ、エラーを確認します。成功した日時と設定値を記録し、設定後すぐに大量送信しないようにします。
直った後に確認すること
一度届いたことだけで完了にせず、実際の運用に近い経路を確認します。
- 管理者通知と利用者への自動返信が両方届くか
- Gmail、会社メール、携帯メールなど異なる受信先で確認したか
- From、Reply-To、表示名が意図どおりか
- 本文の日本語、改行、リンクが崩れていないか
- 個人情報が不要な宛先やログへ残っていないか
- 送信失敗を誰が、どの頻度で確認するか決めたか
お問い合わせフォームでは、メールだけを唯一の保存先にしない考え方も重要です。管理画面や外部システムへ安全に記録を残せる仕組みがあれば、メール不達時の確認経路になります。ただし、保存する個人情報、閲覧権限、保持期間、削除方法を決めてください。
自分で直すか依頼するかの判断基準
自分で確認しやすい範囲
- 宛先の入力ミス、迷惑メール、容量不足の確認
- WordPressとフォームの通知先の確認
- 利用中サービスの公式マニュアルに沿ったテスト送信
- 変更履歴と発生日時の整理
元に戻せる設定で、公式手順が明確であり、サイトの売上や会員機能に大きく影響しない範囲なら、自分で切り分けやすいでしょう。
早めに相談したほうがよい範囲
- 問い合わせ、注文、予約、会員登録のメールが止まっている
- DNSやSPF、DKIM、DMARCの既存設定を変更する必要がある
- 複数のメールサービスやドメインが関係している
- 送信ログに認証エラー、接続拒否、上限超過が出ている
- サイト移転後から届かず、旧サーバーと新サーバーの設定が混在している
- 管理者権限やサーバー情報が分からず、安全な復旧手段がない
事業上重要なメールが止まっている場合、原因調査に時間をかけるほど機会損失が広がります。サーバー会社は送信制限やサーバーログ、メールサービス会社は認証や配送、制作会社はWordPressやフォームの設定というように、担当範囲を分けて相談します。
依頼先へ伝えると解決が早くなる情報
- サイトURLと利用中のWordPress環境
- 届かないメールの種類とフォーム名
- 発生を確認した日時と、最後に届いた日時
- 届く宛先と届かない宛先の違い
- 直前に行った更新、移転、DNS、メールアカウントの変更
- 画面やログに表示されたエラー文
- すでに試した確認と、その結果
問い合わせ本文や顧客のメールアドレスをそのまま送る必要はありません。個人情報を伏せ、再現に必要な範囲だけ共有します。パスワード、APIキー、認証ヘッダーは通常のメールやチャットへ書かず、安全な権限付与方法を相談してください。
メール不達を再発させない運用
設定が直っても、担当者変更、ドメイン更新、外部サービスの仕様変更、認証情報の失効によって再発します。月次またはサイト更新後の確認項目に、フォーム送信と通知受信のテストを加えます。
- 重要フォームを定期的にテストする
- 送信失敗や利用上限の通知先を複数担当者で管理する
- 送信ドメインとDNSの管理者を記録する
- 連携に使う担当者個人アカウントへの依存を減らす
- プラグイン更新後にテストする
- ログの保存期間と個人情報の削除方針を決める
フォーム送信完了画面には、返信までの目安や、一定時間たっても返信がない場合の別連絡手段を案内すると、利用者側も異常に気づきやすくなります。ただし、実際に運用できる連絡先だけを掲載してください。
症状別に考える具体的な対応例
お問い合わせ通知だけ管理者へ届かない場合
まず、フォームの送信記録や完了画面を確認し、訪問者の入力がWordPressまで届いているかを見ます。入力記録があり、自動返信は訪問者へ届いているなら、管理者通知の宛先、条件分岐、受信側の拒否設定へ範囲を絞れます。入力記録も自動返信もないなら、フォームの送信処理やスパム対策によって送信前に止まっている可能性があります。
管理者通知のFromに訪問者のメールアドレスを指定している場合は、サイトと同じドメインで管理するアドレスへ変更し、訪問者のアドレスはReply-Toへ設定します。変更後は、管理者通知へ返信したときに訪問者宛てになることまで確認してください。通知が届くだけでなく、日常の返信動作が正しいことが完成条件です。
利用者への自動返信だけ届かない場合
自動返信の宛先に、フォームで入力されたメール項目が正しく割り当てられているかを確認します。確認用メールアドレス欄が別にある場合、違う項目を参照していないかも見ます。自動返信だけに長い本文、多数のリンク、添付ファイルがあるなら、内容を簡素にしたテストも役立ちます。
ただし、テストのために本番の案内文を消す前に設定を控え、元へ戻せるようにします。特定の携帯メールだけで届かない場合は、受信許可の案内をフォーム付近へ掲載する方法もありますが、送信側の認証不足を利用者の設定だけで解決しようとしないことが大切です。
パスワード再設定メールだけ届かない場合
迷惑メールと登録メールアドレスを確認し、別のWordPress通知が届くかを試します。ログインできる管理者がいる場合は、対象ユーザーの登録アドレスが現在使えるものかを確認できます。ログインできる管理者がおらず、再設定メールも届かないときは、無理にデータベースを直接変更せず、サーバー会社や保守担当者へ相談したほうが安全です。
ログイン復旧とメール送信経路の修復は別の作業です。一時的に管理画面へ入れるようになっても、不達の原因を残せば、次回のパスワード再設定や重要通知で再発します。
注文や予約メールだけ届かない場合
EC、予約、会員機能では、管理者通知、利用者通知、決済結果、ステータス変更など複数のメールがあります。どのイベントで、どちら向けのメールが欠けるのかを表にして確認します。テンプレート単位の有効・無効、宛先、送信条件、注文ステータスも確認対象です。
メール不達が売上や顧客対応へ直接影響するため、テスト注文やテスト予約は実際の決済が発生しない方法を公式手順で選びます。本番データを不用意に編集せず、必要ならサービス提供元、決済会社、制作会社へ同時に状況を共有します。
費用を考えるときは初期設定だけで決めない
メール不達対策の費用は、プラグイン代だけでは判断できません。無料のSMTPプラグインでも、接続先のメールサービス、DNS設定、監視、障害対応、ログ管理に作業が必要です。一方、有料プランでも、現在のフォームやサーバーとの接続確認を省けるとは限りません。
自分で設定する場合に見落としやすいコスト
- 原因調査と公式マニュアル確認に使う時間
- DNSやメールサービスのアカウント管理
- 更新後や障害後の再テスト
- 送信ログに含まれる個人情報の管理
- 担当者変更時の引き継ぎ
送信数が少ない小規模サイトでも、一件の問い合わせが重要であれば、単純な送信単価より不達を早く検知できるかが重要です。反対に、問い合わせを受け付けない情報サイトで通知が少ないなら、高度な配信分析や複数経路は過剰になることがあります。
依頼費用の見積もりで確認する範囲
制作会社や保守会社へ依頼するときは、「SMTPを設定する」だけでなく、原因調査、フォーム確認、DNS認証、テスト、ログ設定、操作説明、一定期間の再確認が見積もりに含まれるかを確認します。既存の業務メールへ影響しないこと、設定後の管理者、障害時の連絡先も明確にします。
メールサービスの月額費用や従量料金が別契約になる場合、誰の名義で契約し、請求と更新を誰が管理するかを決めます。制作会社個人のアカウントへサイトを紐づけると、契約終了時の移管が難しくなることがあります。事業者自身が所有できるアカウントを基本にし、制作会社には必要な権限だけを付与する方法が安全です。
作業前後で使える確認チェックリスト
作業前
- 影響しているメールの種類と宛先を特定した
- 最後に正常受信した日時を記録した
- 直前の更新、移転、DNS変更を確認した
- バックアップと復元手順を確認した
- 既存のSMTP機能と契約中のメールサービスを確認した
- 認証情報を安全に扱う方法を決めた
設定中
- 一度に複数の設定を変えていない
- FromとReply-Toの役割を分けた
- 送信元に自分が管理するアドレスを使った
- DNSは利用サービスの公式値を使った
- SMTP機能を重複して有効にしていない
- テスト日時、件名、宛先、結果を記録した
作業後
- 管理者通知と自動返信を実際のフォームで確認した
- 異なるメールサービスの宛先で受信を確認した
- 送信ログと受信結果の両方を確認した
- 返信先、表示名、本文、リンクを確認した
- 不要な作業用アカウントや権限を削除した
- 運用担当者と次回の定期テスト日を決めた
チェックリストは、すべてのサイトへ同じ設定を強制するものではありません。サイトの用途、利用中のフォーム、送信数、個人情報の量に合わせて必要な項目を残し、担当者が実際に続けられる運用へ整えます。
まとめ
WordPressのメールが届かないときは、SMTPプラグインを急いで追加する前に、宛先、受信箱、フォーム、WordPress共通の送信、サーバー、ドメイン認証の順で範囲を狭めます。送信処理の成功と受信箱への到達は別なので、複数の宛先と実際のフォームで確認することが欠かせません。
お問い合わせや注文など商談に近いメールでは、不達が続く状態を放置しないことが重要です。送信ログや認証を管理したい場合はSMTPや外部メールサービスを検討し、DNSや複数サービスが関係する場合は、サーバー会社、メールサービス会社、制作会社の担当範囲を整理して早めに相談しましょう。
