DNS切り替え後に確認すること｜Web・メール・SSLのチェックリスト

DNS の切り替えは、設定を変えた瞬間に全部がきれいに新環境へそろう作業ではありません。
トップページは見えていても、問い合わせフォームだけ旧環境を向いていたり、メールだけ前の設定が残っていたり、CDN やキャッシュの影響で一部ユーザーだけ違う表示になったりします。

特に小規模サイトや受託案件では、表示されたので完了 と判断して旧サーバーを止めてしまい、そのあとで問い合わせ消失や証明書エラーに気づくことがあります。
ここは、切り替え作業そのものより、切り替え後の確認手順の方が大事になることもあります。

この記事では、DNS 切り替え後に確認することを、Web、メール、SSL、CDN、サブドメイン、ログの観点から、実務で使いやすいチェックリストとして整理します。
サーバー移転全体の流れから見たい場合は、既存ドメインを別サーバーへ移す方法は？手順・DNS切り替え・注意点を解説 もつながりやすいです。 カットオーバー という言葉そのものの意味や、本番切り替え全体の進め方から整理したい場合は、カットオーバーとは？本番切り替え・移行日・確認手順の基本を整理 もあわせて読むと流れがつかみやすいです。

結論：切り替え後は「Web・メール・SSL・旧環境」の4本を優先確認する

DNS 切り替え後に最低限確認したいのは、次の4本です。

DNS切り替え後の確認チェックリスト

最初に全体像を一覧で見ます。

1. まずはWebの実表示を確認する

DNS を切り替えた直後に最初に見るのは、管理画面ではなく実際の表示です。
Google Search Central でも、ホスティング変更では新環境のテスト、DNS 切り替え、新旧トラフィック監視、旧環境停止の順で進めるよう案内されています。

最低限、次を確認します。

• トップページ
• 主要な下層ページ
• ログイン画面や管理画面
• 問い合わせフォーム送信
• 301 / 302 リダイレクト
• CSS や画像が正しく出るか

2. メール設定は Web より事故に気づきにくい

DNS 切り替え後でいちばん怖いのは、Web よりメールです。
Web はブラウザで見れば気づけますが、メールは 届かなかった と言われて初めて気づくことがあります。

最低限、次を確認します。

3. SSL/TLS はブラウザ表示だけでなく内部通信も見る

SSL や TLS の確認では、鍵マークが出るか だけだと少し足りません。
実務では次も見ます。

• https:// で証明書エラーが出ないか
• www あり / なし の両方で問題ないか
• API や webhook の接続先で証明書エラーが出ていないか
• 混在コンテンツが出ていないか
• CDN やプロキシ利用時に origin 側の証明書も整っているか

4. TTLとキャッシュの影響を前提にして確認する

TTL を短くしていても、切り替え直後に全員が同時に新環境を見るわけではありません。
Cloudflare の TTL ドキュメントでも、レコード変更の体感にはローカル DNS キャッシュの影響が残ることが説明されています。

そのため、切り替え後は次を意識します。

5. CDNやプロキシを使っているならDNS onlyとの違いも確認する

CDN や Cloudflare のようなプロキシを挟む構成では、DNS 切り替え後の見え方が単純ではありません。
Cloudflare Docs でも、A / AAAA / CNAME は proxy status により HTTP/HTTPS トラフィックが中継される一方、MX や TXT は常に DNS-only だと案内されています。

つまり、次のようなズレが起きます。

• Web は Cloudflare 経由で見える
• でもメール系レコードは別で確認が必要
• 所有権確認用 CNAME はプロキシ対象外が必要なことがある
• キャッシュの都合で旧表示が残ることがある

このため、Web が通っても DNS 全体が正しい とは言えません。
特にメール、SaaS の検証用 TXT/CNAME、API 用サブドメインは別で確認した方が安全です。

6. サブドメインと周辺機能を忘れない

実案件では、本番ドメイン本体より周辺の方が漏れやすいです。
よくある確認漏れは次です。

• www
• mail
• api
• admin
• staging
• 画像配信サブドメイン
• 計測タグや外部SaaS用の CNAME / TXT

7. 旧環境をすぐ止めない

Google Search Central でも、旧環境のログがゼロに近づいたことを見てから停止する流れが案内されています。
ここは本当に大事で、旧環境を早く止めるほど事故に弱くなります。

最低限、次を確認してから止めます。

DNS切り替え後の実務チェック順

迷ったら、次の順で見ると整理しやすいです。

この順なら、見えるけど使えない 状態を拾いやすいです。

DNS切り替え後の確認のよくある質問

Q. DNS 切り替え後どれくらい待つべきですか？

A. 目安は変更したレコードの TTL です。リゾルバのキャッシュは最長で TTL の秒数だけ残るので、事前に TTL を 300秒まで下げておけば、多くの利用者はその程度の時間で新しい値を見るようになります（ただし TTL どおりに更新しないキャッシュもあるので余裕を見ます）。ネームサーバー自体を変える場合は、上位（TLD）側に登録された NS レコードの TTL も効くため、1〜2日程度は見込みます。

Q. 切り替えが完了したかどうかを確認するには？

A. dig @8.8.8.8、dig @1.1.1.1 で複数のパブリックリゾルバから新IPが返るか、whatsmydns.net で世界各地の浸透状況を確認します。

Q. メールが届かない場合の対処は？

A. MX、SPF、DKIM、DMARC レコードを順に確認します。新サーバーの IP が SPF に含まれていないと迷惑メール扱い、DKIM 署名が古いと検証失敗、などが典型原因です。

Q. SSL/TLS のエラーが出る場合は？

A. 新サーバー側の証明書が そのドメイン用に発行されているか、証明書の有効期限、中間証明書を含めているか、SSL Labs テスト で総合的にチェックします。

Q. CDN を使っている場合の特殊な確認は？

A. CDN キャッシュの purge、エッジでの TLS 終端、オリジン接続の確認、CDN 管理画面でのドメイン認証、を確認します。CDN が古いキャッシュを返している場合、強制 purge で解決します。

Q. サブドメインの設定漏れを防ぐには？

A. 切り替え前に全レコードを CSV エクスポートし、新ネームサーバー側に1つ1つ移植します。www、mail、api、認証用 TXT、メール送信 SPF / DKIM、すべて漏れなく設定します。

Q. 切り替え失敗時に旧環境に戻せますか？

A. 変更したレコード（またはネームサーバー）を元の値に戻せば戻せます。ただし、新しい値を覚えたキャッシュは TTL の間残るため、全員がすぐ旧環境に戻るわけではありません。旧環境のアクセスログが落ち着くまでは停止せず、並行稼働させておくのが安全です。

まとめ

DNS 切り替え後に確認することは、Web の表示確認だけでは足りません。
実務では、Web、メール、SSL、CDN、サブドメイン、旧環境ログまで見て、初めて 切り替え完了 と言いやすくなります。

特に事故になりやすいのは、MXレコード の見落とし、TTL とキャッシュの読み違い、CDN やプロキシ経由の挙動差、旧環境停止の早すぎです。
メール系レコードの役割分担をまとめて確認したい場合は、MXレコード・SPF・DKIM・DMARCの違いとは？メールDNS設定の基本を整理 もあわせて見ると抜け漏れを減らしやすいです。
切り替え前に確認項目を用意し、切り替え後は Web → メール → SSL → 旧環境 の順で潰していくと、かなり落ち着いて進めやすくなります。

参考リンク

• Google Search Central: Changing your hosting
• Cloudflare Docs: Time to Live (TTL)
• Cloudflare Docs: Proxy status
• Google Workspace Admin Help: DNS basics