DNS 移管でメールが止まった時の復旧手順
目次
この記事でわかること
- DNS 移管でメールが止まる主な原因 4 つと、それぞれの復旧手順
- TTL を短縮しておく理由と「浸透期間」の現実
- 旧 NS と新 NS を併用する段階的移管の進め方
DNS 事業者を切り替える「ドメイン移管」は、Web サイトを表示するレコードだけ意識して進めると、気づかないうちに会社のメールが止まります。社外からの問い合わせが届かない、社内決裁メールが消える、業務が完全に停止する——こうした被害は移管作業のたびに発生しています。社内サーバー移転に伴うメール障害は サイト移管でメールが届かない時のチェックリスト でも取り上げましたが、本記事では「DNS 事業者そのものを切り替える」場面に絞って、原因の見分け方と復旧手順をまとめます。
DNS 移管で起きる失敗パターン 4 種
メールが届かない原因は、ほぼ次の 4 つに集約されます。
パターン 1: 新 DNS で MX レコードが未設定
最も多い失敗です。Web サイトの A / CNAME レコードだけ移し、メールに使う MX レコードを忘れるケースです。新 NS への切替直後から、世界中の送信サーバーが「このドメインの MX が見つからない」と判断し、メールがバウンス（不達返送）します。MX とは何かは MX レコード入門 で詳しく解説しています。
復旧手順: 旧 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 担当者向けネームサーバー入門 を、レコード全体の構造は DNS の基本 を参照してください。
段階的併用運用の進め方
DNS 移管は、旧 NS と新 NS を一定期間共存させると安全です。以下の進め方を推奨します。
- 移管 1 週間前（D-7）: 旧 DNS の TTL を 300 秒に短縮。これでキャッシュ寿命が短くなる
- 移管 3 日前（D-3）: 新 DNS にすべてのレコードを複製し、
dig @新 NSで値が一致することを検証 - 移管日（D）: レジストラの管理画面で NS を切替
- 移管後 D+7 まで: 旧 DNS のレコードはそのまま残し、新旧どちらが参照されても同じ応答を返せる状態を維持
- D+14 を目安: 旧 DNS の参照が完全に止まったことを確認してから、旧 DNS の契約を停止
注意点として、レジストラに登録する NS リストには「旧 NS と新 NS を両方並べる」運用をしないでください。一部のリゾルバは登録された NS リストからランダムに 1 台へ問い合わせるため、新旧で値が異なるレコードがあると、応答が安定しません。混在させるのは「同じ値を返す状態」を維持する目的に限定し、NS リスト自体は新 NS だけに切り替えるのが安全です。
メールが今まさに止まっている時のチェックリスト
- レジストラ管理画面で NS が新 DNS を指しているか確認
dig MX <ドメイン> @1.1.1.1で MX レコードが返るか確認dig TXT <ドメイン> @1.1.1.1で SPF が返るか確認dig DS <ドメイン> @8.8.8.8で DS が残っていないか確認（DNSSEC 利用時）- 旧 DNS の管理画面にログインできるなら、レコード一覧を CSV エクスポートして新 DNS に再投入
それでも復旧しない場合は、無理に新 DNS で粘らず、レジストラ管理画面で NS を旧 NS に戻す「ロールバック」も選択肢です。
自社の状況を確認してみませんか
設定状況がわからない方は、無料のドメイン診断で現状をチェックできます。 DMARC・SPF・DKIM・SSL の状態が数十秒でレポートされます。 判断に迷う場合はお問い合わせからご相談ください。専門家がわかりやすくサポートいたします。