サーバー移転後のメール確認チェックリスト｜お問い合わせが届かなくなる原因と確かめ方

サーバー移転で、サイトの表示は確かめても、メールは確かめ忘れがちです。

メールは壊れても画面に出ません。

お問い合わせを送った人には「送信しました」と出て、運営者には何も届かない、という状態が続きます。

筆者のサイトでも、移転の2週間ほどあとに、お問い合わせのメールが止まっていました。

この記事では、移転のあとにメールを確かめる順番と、その方法をまとめます。

この記事で分かること

• 移転後のメール不具合で確認する4つの原因候補
• WordPressの送信設定のどこを見るか
• wp_mailを直接試す方法と、フォームから試す方法
• DNSと旧サーバーの受信箱で確かめること
• 確認を毎週の自動テストにする方法

本文の障害は筆者サイトのSMTP設定の事例です。

2026年10月11日に公式資料と照合しましたが、各サーバー・プラグインで送信を再実行していません。

外部メールサービスを使う構成では、Webサーバー移転後もMX・SMTP・DKIMを維持する場合があります。

著者

motoki

WEB制作をしているデジタルノマド
WordPressのカスタマイズが好きで、色々と自作しています。

WordPressのカスタマイズに困ったらご相談ください！

MOTOKI合同会社

カスタマイズの依頼・相談

結論：確かめる順番

設定を探す時間は構成によって変わります。

送信経路とテスト宛先を確認してから始めてください。

3は実際に送るので、受信箱を見られる状態でやります。

なぜ移転のあとにメールだけ壊れるのか

• WordPressのSMTP設定（プラグインやCode Snippets）に、旧サーバーのホスト名とパスワードが入っている
• DNSのSPFレコードが移転後の実際の送信元を許可しておらず、認証に失敗する
• ドメインのメール設定が旧サーバーに残っていて、旧サーバーが自分宛てとして受け取ってしまう
• メール箱のデータを移していない、または転送の設定が旧サーバーにしかない

どれも、サイトの表示とは関係なく起きます。

移転の作業に「メール」の項目を入れておかないと、気づくのは問い合わせが来ないと感じたときになります。

1. WordPressの送信設定を探す

WordPressが外部のSMTPで送る設定は、まず次の場所を確認します。

これ以外に独自プラグイン、サーバー側の設定、外部の配信APIが関わる構成もあります。

• SMTPのプラグイン（WP Mail SMTPなど）の設定画面
• Code Snippetsに入れた phpmailer_init のコード
• テーマの functions.php や wp-config.php

WP Mail SMTPを使っている場合は、「WP Mail SMTP → Settings → General」でメーラー方式を確認します。

以下は2026年10月13日に、新規Local環境（WordPress 7.1.3、PHP 8.1.23、WP Mail SMTP Lite 4.10.2）で撮影した英語UIの未設定例です。

「Other SMTP」を未保存の状態で選び、ホスト・暗号化・ポートの項目名と位置を確認しました。

画像内の「None」は導入直後の未設定状態で、推奨する暗号化設定ではありません。

実際のホスト・ポート・暗号化は利用中のメールサービスの案内に合わせて確認します。

Google / Gmailなど別のメーラー方式では、表示される設定項目が異なります。

ホスト名・ユーザー名・パスワードなどは空欄のままです。

設定保存、接続、認証、メール送信は行っておらず、再読み込みで元の「Default (none)」へ戻ることを確認しました。

この写真は項目の位置を示すもので、送信・受信や移転後の配達確認を済ませた記録ではありません。

SSHで入れる場合、次は一致するファイル名だけを探す例です。

設置先に合わせて移動し、ファイルを読むときは資格情報を公開・共有しないでください。

Code Snippetsなどデータベース側の設定はこの検索だけでは見つかりません。

cd public_html
grep -rl -i 'phpmailer_init\|isSMTP' \
  wp-content/mu-plugins \
  wp-content/themes/*/functions.php \
  wp-config.php

Code Snippetsのコードはデータベースにあるので、管理画面の一覧で「SMTP」「mail」で探します。

見つけたら、Host と認証方式が現在利用しているメール配信サービスの案内に合うか確認します。

Webサイトを移しただけなら、外部SMTPのホストを新しいWebサーバー名へ変える必要はありません。

ユーザー名・資格情報・送信元アドレスも、採用しているメールサービスの設定と照合します。

筆者の場合は、2025年に作ったスニペットの Host が移転前のサーバー名のままでした。

移転のあとしばらくは旧サーバーが認証を受け付けていたので、すぐには壊れませんでした。

旧サーバーが止まった時点で、全部のメールが「SMTP エラー: 認証できませんでした」で失敗するようになりました。

関連記事：WordPressをコードだけでSMTP化する方法

2. wp_mailを直接試す

フォームを使わずに、WordPressの送信だけを試します。

WP-CLIでは送信処理の成否を確認できます。

info@example.comは自分が受信を確認できるテスト用アドレスに置き換え、受信箱と迷惑メールフォルダーも別に確認してください。

wp eval 'add_action("wp_mail_failed",
  function($e){echo "FAILED: ".$e->get_error_message()."\n";});
var_dump(wp_mail("info@example.com",
  "移転後の送信テスト", "届いたら成功"));'

bool(true)はWordPress側の送信処理の成功を示し、配達完了を保証しません。

受信箱への到着まで確認できた場合、そのテストの送信経路と宛先への配達を確認できたと判断します。

FAILED:のエラーは原因を調べる手掛かりです。

接続・認証・差出人などを確認し、出力に秘密値が含まれる場合は記録や共有から除いてください。

wp eval内のremove_all_actions("phpmailer_init");は、そのCLI実行中だけ、このフックの全コールバックを外します。

SMTP以外の変更も外れ、別のフックや配信経路には影響しないため、SMTPを完全に無効にする操作とは限りません。

それで届く場合は、外したコールバックが原因の候補になります。

実際に使われた送信経路を確認して切り分け、SMTP設定だけが原因とは断定しないでください。

テストごとに「実行時刻・送信経路・テスト宛先・WordPress側の結果・受信箱の到着・迷惑メールへの振り分け」を残します。

送信処理が成功しても届かない場合は、配信サービスのログやエラー通知と照合してください。

2026年10月20日にWordPress公式のwp_mail資料で、戻り値と配達成功が別であることを再確認しました。

今回、新しいメール送受信の試験は行っていません。

3. フォームから本当に送る

送信の設定が正常でも、フォームのプラグインの設定（宛先・差出人・自動返信）は別です。

自分のフォームから、実際に1件送ります。

• 管理者宛のメールが届くか
• 自動返信が、入力したアドレスに届くか
• 迷惑メールフォルダーに入っていないか
• 差出人が、利用中の配信サービスで許可・認証したアドレスになっているか

Snow Monkey Formsは、管理者宛の送信に失敗すると「管理者メールの送信に失敗しました」と画面に出します。

ただし、完了ページへの転送をJavaScriptで足している場合は、この表示を見ないまま完了ページに移ることがあります。

転送は、完了の応答が返ってから動くようにしておきます。

関連記事：Snow Monkey Formsの使い方

4. DNSに旧サーバー名が残っていないか

メールの認証（SPF・DKIM・DMARC）は、ドメインのDNSに書いてあります。

SPFは、実際にメールを送るサーバーや配信サービスを許可しているか確認します。

旧サーバーの記載が残ることだけでは、新送信元の認証失敗を意味しません。

利用中の全送信元を1つのSPFレコードにまとめ、旧送信元は利用終了後に整理します。

MXレコードが旧サーバーを指したままなら、受信が旧サーバーに行きます。

関連記事：SPF・DKIM・DMARCの確認方法

関連記事：DNSの浸透を確認する方法

5. 旧サーバーの受信箱を見る

旧サーバーにドメインのメール設定が残っていると、旧サーバーはそのドメイン宛てのメールを「自分の担当」として受け取ることがあります。

旧サーバーを経由して送ったメールが、新サーバーに届かず、旧サーバーの受信箱に入る形です。

特に、WordPressのSMTP設定が旧サーバーを指したままのときに起きます。

• 旧サーバーの契約が残っているうちに、旧サーバーのウェブメールで受信箱を見る
• 移転の日より後のメールが入っていたら、転送や保存で回収する
• 旧メールを保存・回収し、MX・転送・全送信元の切替と新受信箱への到着を確認してから、不要になった旧メール設定の停止や解約を行う。Webサイトも使うドメイン登録を一括で削除しない

解約してしまうと、この確認はできなくなります。

解約の前に、一度は見ておきます。

6. フォーム以外の送信

• コメントの通知、WordPress本体の更新通知
• WooCommerceの注文メール
• 会員サイトのパスワード再設定メール
• バックアッププラグインの完了通知

wp_mailを使う通知でも、宛先・テンプレート・送信条件は個別です。

独自の配信APIを使うプラグインもあるため、直接テストの成功だけで全通知の成功とは判断せず、対象の通知ごとに受信を確認してください。

ただ、宛先がサーバー移転の前のアドレスになっていないかは、個別に見ます。

7. 毎週の自動テストにする

移転の直後に確かめても、SMTPのパスワードの期限や、サーバーの設定変更で、あとから壊れることがあります。

筆者は、フォームを本番と同じ経路で毎週自動で送り、届くまでを確かめる仕組みを入れました。

この仕組みを動かした初日に、1で書いた壊れ方が見つかりました。

関連記事：お問い合わせフォームを毎週自動でテストする方法

よくある質問

Q. 移転の前に確かめておくことはありますか

SMTPの設定がどこにあるかを、移転の前に控えておきます。

移転の作業の最後に「フォームから1件送る」を入れておくと、ここで止まれます。

Q. サーバー標準の送信で足りますか

標準の送信で足りるかは、サーバーの送信仕様と実際の配達結果で確認します。

SPF設定だけで受信成功は保証できません。

SMTPを使うのは、送信元を1つにそろえたいときや、外部の配信サービスを使うときです。

障害時の代替経路を用意する場合も、その経路の認証と配達を事前に確認します。

設定を変える前に現在値と戻し方を控え、送信方式を切り替えただけで復旧完了とは判断しないでください。

Q. 止まっていた期間の問い合わせは取り戻せますか

旧サーバーの受信箱に残っていれば回収できます。

送信に失敗していた場合は、フォームのプラグインが内容を保存していない限り残りません。

GA4の完了ページ件数は参考情報です。

再表示・計測漏れや転送処理の影響があり、送信成功・受信成功・問い合わせ内容は証明できません。

回収できるかはフォームの保存記録や旧受信箱で確認します。

まとめ

• 移転のあとは、表示だけでなくメールを確かめる
• 順番は、SMTPの設定 → wp_mailの直接テスト → フォームから送る → DNS → 旧サーバーの受信箱
• 旧サーバーを解約する前に、受信箱と設定を見る
• 定期テストは、受信確認と異常時の通知まで動くことを確認する

関連記事：All-in-One WP Migrationでサーバー移転する手順

関連記事：お問い合わせメールが届かない・迷惑メールに届く場合の設定方法