## この記事でわかること

- サイト移管直後にメールが届かなくなる典型的な 3 原因と切り分け方法
- 緊急対応の優先順位(送受信どちらが止まっているかで動き方が違う)
- 復旧後に再発を防ぐためのチェックリスト

## 「サイト移管したらメールが止まった」の正体

サイト移管(サーバー移転、ホスティング切り替え、ドメイン移管)の翌日に、

- 取引先から「メールが届かない」と電話がきた
- Gmail / Outlook 宛のメールが迷惑メール扱いになる
- 受信は OK だが送信が拒否される

といった症状が出ることがあります。原因は **DNS の連動忘れ**であることがほとんど。サイトの A レコードだけ更新して、メール関連のレコード(MX、SPF、DKIM)を古いまま放置するパターンが圧倒的に多い。

詳しい背景は[Gmailにメールが届かない時の原因](/blog/gmail-not-receiving)も参考になります。

![移管後にメールが止まる典型 3 原因](/blog/site-migration-mail-broken/three-causes.svg)

## 原因 1: SPF レコードの更新漏れ

SPF レコードに **古いレンタルサーバーの IP** が残ったまま、新サーバーの送信元が含まれていないと、Gmail / Outlook で SPF fail → 迷惑メール / 配信拒否に直結します。

確認方法:

```bash
# ターミナルで(または公開ツールで)
dig +short TXT example.co.jp | grep spf
```

出力に **古いサーバーの `include:` か IP** が残っていたら、それが原因の可能性大。SPF 設定の詳細は[SPF レコードの設定方法](/blog/spf-setup-guide)で扱っています。

## 原因 2: MX レコードの切り替え忘れ

メールサーバー自体を変更した場合(例: 旧レンタルサーバーのメール → Google Workspace への移行)、MX レコードの更新が必要です。

旧 MX のままだと、送信側からのメールは旧サーバーに届き、新サーバーでは受信できません。MX レコードの仕組みは[MX レコードとは](/blog/mx-record-guide)を参照。

## 原因 3: DNS 伝播待ち

DNS 変更直後(数時間以内)に「届かない」と報告される場合は、単に **DNS 伝播がまだ世界中に広がっていない**だけのこともあります。レコードの TTL が長い(例: 86400 秒 = 24 時間)と、一部の受信サーバーは古いキャッシュを参照し続けます。

[DNS の TTL の動き](/blog/dns-basics)で詳しく解説しています。

## 緊急対応の優先順位

症状によって動き方が違います。

![症状別の対応順序](/blog/site-migration-mail-broken/triage-flow.svg)

### 症状 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 設定の確認方法](/blog/dkim-verification)で詳しく扱っています。

## 復旧後の再発防止チェックリスト

次の移管時のために、以下を移管前に揃えます。

- 旧 DNS 設定の **全件スクリーンショット**(復元用)
- メール送信元の **棚卸しリスト**(レンタルサーバー、Google Workspace、SendGrid 等)
- 移管 1〜2 日前に **TTL を 300 秒に短縮**
- 移管直後の **テストメール送受信**(取引先に協力依頼)

特に「送信元の棚卸し」は重要です。**自社が把握していない送信経路**(古いマーケティングツールの自動配信、人事システムの通知メール等)が SPF 未対応になっていると、移管時に発見が遅れます。

## まとめ

- サイト移管後のメールトラブルは「SPF 未更新」「MX 切り替え忘れ」「DNS 伝播待ち」の 3 つがほぼ全て
- 症状で送信側 / 受信側 / 認証問題を判別し、優先順に対応
- 移管前に旧 DNS のスクリーンショット保存と TTL 短縮で再発防止

## まずは現状を診断

メールトラブルが起きていなくても、移管予定がある段階で[ドメイン診断](/diagnose)を叩いて、SPF / DKIM / DMARC / MX を一括確認しておくのが安全です。3 分で完了します。

緊急対応で SPF / DKIM を専門家に確認させたい場合はお気軽にご相談ください。