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

- DNS 移管でメールが止まる主な原因 4 つと、それぞれの復旧手順
- TTL を短縮しておく理由と「浸透期間」の現実
- 旧 NS と新 NS を併用する段階的移管の進め方

DNS 事業者を切り替える「ドメイン移管」は、Web サイトを表示するレコードだけ意識して進めると、気づかないうちに会社のメールが止まります。社外からの問い合わせが届かない、社内決裁メールが消える、業務が完全に停止する——こうした被害は移管作業のたびに発生しています。社内サーバー移転に伴うメール障害は [サイト移管でメールが届かない時のチェックリスト](/blog/site-migration-mail-broken) でも取り上げましたが、本記事では「DNS 事業者そのものを切り替える」場面に絞って、原因の見分け方と復旧手順をまとめます。

## DNS 移管で起きる失敗パターン 4 種

メールが届かない原因は、ほぼ次の 4 つに集約されます。

![DNS 移管の正常フローと失敗パターン](/blog/dns-migration-recovery-mail/migration-flow.svg)

### パターン 1: 新 DNS で MX レコードが未設定

最も多い失敗です。Web サイトの A / CNAME レコードだけ移し、メールに使う MX レコードを忘れるケースです。新 NS への切替直後から、世界中の送信サーバーが「このドメインの MX が見つからない」と判断し、メールがバウンス（不達返送）します。MX とは何かは [MX レコード入門](/blog/mx-record-guide) で詳しく解説しています。

**復旧手順**: 旧 DNS から `dig MX example.jp @旧 NS` で MX を控え、新 DNS に同じ値で投入する。優先度（preference）の数値も合わせる。

### パターン 2: SPF / DKIM / DMARC レコードが未反映

MX は移したが、TXT レコードである SPF / DKIM / DMARC を忘れるパターンです。メールは到達しますが、受信側で認証が失敗し、迷惑メールフォルダに入る・拒否されるといった症状になります。とくに DMARC の `p=quarantine` 以上を運用している場合、未反映状態は致命的です。

**復旧手順**: 旧 DNS の TXT レコードをすべてエクスポートし、新 DNS に投入する。DKIM の場合、CNAME 形式で送信ベンダーのレコードを参照している構成があるため、CNAME も忘れずに移す。

### パターン 3: TTL が長く、旧 DNS のキャッシュが残る

TTL（Time To Live、キャッシュ保持秒数）を 86400 秒（1 日）のまま NS を切替すると、世界中の DNS リゾルバが旧 NS の情報を最大 1 日キャッシュし続けます。新 DNS にレコードを正しく入れていても、旧 NS にだけ存在するレコードを参照する顧客のサーバーから見ると、しばらく旧情報のまま見えてしまいます。

**復旧手順**: 移管完了後しばらくは旧 DNS のレコードもそのまま残し、両方で同じ値を返す状態を維持する。これが後述の「段階的併用運用」です。

### パターン 4: DNSSEC の DS レコード不整合

DNSSEC（DNS の電子署名）を使っているドメインで、移管時に旧 NS の鍵が登録された DS レコードを残したまま NS を切り替えると、検証エラーで全名前解決が失敗します。Web もメールも全滅という最悪のパターンです。

**復旧手順**: レジストラ管理画面から DS レコードを一旦削除し、新 NS の鍵で再登録する。DNSSEC を再開するまでの間、検証エラーは発生しないため、緊急対応としてはまず DS の削除が安全です。

## TTL 戦略と「浸透期間」の現実

「DNS の浸透期間は 24〜72 時間」とよく言われますが、技術的には浸透という現象は存在しません。実際は各 DNS リゾルバが TTL の間だけ古い値をキャッシュしているだけで、TTL を超えれば即座に新値を返します。したがって、移管 1 週間前から TTL を 300 秒（5 分）に短縮しておけば、切替後の情報伝播は 5 分単位で進みます。逆に TTL を縮めずに切り替えると、丸 1 日「一部の顧客にだけ届かない」状態が続きます。

ネームサーバーそのものの動きは [Web 担当者向けネームサーバー入門](/blog/nameserver-basics-smb) を、レコード全体の構造は [DNS の基本](/blog/dns-basics) を参照してください。

## 段階的併用運用の進め方

DNS 移管は、旧 NS と新 NS を一定期間共存させると安全です。以下の進め方を推奨します。

![DNS 移管時の段階的併用運用タイムライン](/blog/dns-migration-recovery-mail/parallel-timeline.svg)

1. **移管 1 週間前（D-7）**: 旧 DNS の TTL を 300 秒に短縮。これでキャッシュ寿命が短くなる
2. **移管 3 日前（D-3）**: 新 DNS にすべてのレコードを複製し、`dig @新 NS` で値が一致することを検証
3. **移管日（D）**: レジストラの管理画面で NS を切替
4. **移管後 D+7 まで**: 旧 DNS のレコードはそのまま残し、新旧どちらが参照されても同じ応答を返せる状態を維持
5. **D+14 を目安**: 旧 DNS の参照が完全に止まったことを確認してから、旧 DNS の契約を停止

注意点として、レジストラに登録する NS リストには「旧 NS と新 NS を両方並べる」運用をしないでください。一部のリゾルバは登録された NS リストからランダムに 1 台へ問い合わせるため、新旧で値が異なるレコードがあると、応答が安定しません。混在させるのは「同じ値を返す状態」を維持する目的に限定し、NS リスト自体は新 NS だけに切り替えるのが安全です。

## メールが今まさに止まっている時のチェックリスト

1. レジストラ管理画面で NS が新 DNS を指しているか確認
2. `dig MX <ドメイン> @1.1.1.1` で MX レコードが返るか確認
3. `dig TXT <ドメイン> @1.1.1.1` で SPF が返るか確認
4. `dig DS <ドメイン> @8.8.8.8` で DS が残っていないか確認（DNSSEC 利用時）
5. 旧 DNS の管理画面にログインできるなら、レコード一覧を CSV エクスポートして新 DNS に再投入

それでも復旧しない場合は、無理に新 DNS で粘らず、レジストラ管理画面で NS を旧 NS に戻す「ロールバック」も選択肢です。

## 自社の状況を確認してみませんか

設定状況がわからない方は、無料の[ドメイン診断](/diagnose)で現状をチェックできます。
DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。
判断に迷う場合は[お問い合わせ](/contact)からご相談ください。専門家がわかりやすくサポートいたします。