サイト移管後にメールが届かない時の対処手順
目次
この記事でわかること
- サイト移管直後にメールが届かなくなる典型的な 3 原因と切り分け方法
- 緊急対応の優先順位(送受信どちらが止まっているかで動き方が違う)
- 復旧後に再発を防ぐためのチェックリスト
「サイト移管したらメールが止まった」の正体
サイト移管(サーバー移転、ホスティング切り替え、ドメイン移管)の翌日に、
- 取引先から「メールが届かない」と電話がきた
- Gmail / Outlook 宛のメールが迷惑メール扱いになる
- 受信は OK だが送信が拒否される
といった症状が出ることがあります。原因は DNS の連動忘れであることがほとんど。サイトの A レコードだけ更新して、メール関連のレコード(MX、SPF、DKIM)を古いまま放置するパターンが圧倒的に多い。
詳しい背景はGmailにメールが届かない時の原因も参考になります。
原因 1: SPF レコードの更新漏れ
SPF レコードに 古いレンタルサーバーの IP が残ったまま、新サーバーの送信元が含まれていないと、Gmail / Outlook で SPF fail → 迷惑メール / 配信拒否に直結します。
確認方法:
# ターミナルで(または公開ツールで)
dig +short TXT example.co.jp | grep spf
出力に 古いサーバーの include: か IP が残っていたら、それが原因の可能性大。SPF 設定の詳細はSPF レコードの設定方法で扱っています。
原因 2: MX レコードの切り替え忘れ
メールサーバー自体を変更した場合(例: 旧レンタルサーバーのメール → Google Workspace への移行)、MX レコードの更新が必要です。
旧 MX のままだと、送信側からのメールは旧サーバーに届き、新サーバーでは受信できません。MX レコードの仕組みはMX レコードとはを参照。
原因 3: DNS 伝播待ち
DNS 変更直後(数時間以内)に「届かない」と報告される場合は、単に DNS 伝播がまだ世界中に広がっていないだけのこともあります。レコードの TTL が長い(例: 86400 秒 = 24 時間)と、一部の受信サーバーは古いキャッシュを参照し続けます。
DNS の TTL の動きで詳しく解説しています。
緊急対応の優先順位
症状によって動き方が違います。
症状 A: 取引先から「届かない」と苦情(送信側障害)
最優先で SPF を確認・修正。古い include: を削除し、新サーバーの SPF を追加。SPF 反映には DNS 伝播時間がかかるので、伝播完了を待つ間は 送信元を一時的に旧サーバーに戻す手も。
症状 B: 自社が受信できない(受信側障害)
MX レコードを確認。新メールサーバーへの MX が登録されているか、優先度は適切か。Google Workspace なら 1 smtp.google.com.、Microsoft 365 なら 0 <tenant>.mail.protection.outlook.com.。
症状 C: 送受信できるが Gmail で迷惑メール扱い
SPF + DKIM 両方確認。DKIM のセレクタが新サーバー用に登録されているか、CNAME or TXT が正しく配信されているか。DKIM の確認はDKIM 設定の確認方法で詳しく扱っています。
復旧後の再発防止チェックリスト
次の移管時のために、以下を移管前に揃えます。
- 旧 DNS 設定の 全件スクリーンショット(復元用)
- メール送信元の 棚卸しリスト(レンタルサーバー、Google Workspace、SendGrid 等)
- 移管 1〜2 日前に TTL を 300 秒に短縮
- 移管直後の テストメール送受信(取引先に協力依頼)
特に「送信元の棚卸し」は重要です。自社が把握していない送信経路(古いマーケティングツールの自動配信、人事システムの通知メール等)が SPF 未対応になっていると、移管時に発見が遅れます。
まとめ
- サイト移管後のメールトラブルは「SPF 未更新」「MX 切り替え忘れ」「DNS 伝播待ち」の 3 つがほぼ全て
- 症状で送信側 / 受信側 / 認証問題を判別し、優先順に対応
- 移管前に旧 DNS のスクリーンショット保存と TTL 短縮で再発防止
まずは現状を診断
メールトラブルが起きていなくても、移管予定がある段階でドメイン診断を叩いて、SPF / DKIM / DMARC / MX を一括確認しておくのが安全です。3 分で完了します。
緊急対応で SPF / DKIM を専門家に確認させたい場合はお気軽にご相談ください。