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

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

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

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

この記事では、2026年4月22日時点で Google Search Central の Changing your hosting、Cloudflare DNS Docs の TTL と Proxy status、Google Workspace Admin Help の DNS basics を確認しながら整理しています。Google はホスティング変更時に、新旧環境の監視と旧環境停止のタイミング確認を重視しています。Cloudflare は TTL と proxy status の違いを明示しており、Google Workspace は TTL が次回以降の変更反映速度にも影響すると案内しています。ここでは、特定ベンダー専用ではなく、DNS 切り替え後の一般的な確認手順としてまとめます。

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

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

1. Web が新環境で正しく表示されているか
2. メール受信と送信が想定どおり動いているか
3. SSL/TLS エラーが出ていないか
4. 旧環境にまだアクセスやメールが残っていないか

ここを見ないまま旧サーバーや旧メール設定を止めると、表面上は成功に見えても、あとから事故になりやすいです。

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

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

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

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

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

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

このとき大事なのは、トップページだけ見ない ことです。
DNS 切り替え後は、一部サブドメイン、画像配信先、フォーム送信先、API 向き先だけ別になっていることがあります。

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

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

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

• MXレコード が意図したメールサービスを向いているか
• SPF が想定どおりか
• DKIM が残っているか
• DMARC のポリシーや集計先にズレがないか
• 実際に外部から受信テストできるか
• フォーム通知メールが届くか

Google Workspace の DNS basics でも、TTL は MXレコード や CNAME など各レコードごとに影響し、今の TTL は次の変更反映速度にも関わると説明されています。
そのため、切り替え前に Web 用レコードだけ見て満足せず、メール系も別で確認した方が安全です。

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

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

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

Cloudflare の proxy status や SSL/TLS モードを使う構成では、ブラウザから見える証明書と、オリジンサーバー側の構成がずれることがあります。
つまり、見た目は開いても、外部連携や管理系通信だけ失敗することがあります。

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

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

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

• 自分のPCだけで確認して終わらせない
• モバイル回線と固定回線で差がないか見る
• CDN キャッシュを消すべきか判断する
• 前の表示が出る人が一部残る時間 を見込む

ここで 自分は見えたから大丈夫 と判断すると、一部利用者だけ旧環境を見ている事故を拾えません。

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

本体だけ開いても、サブドメインが古い向き先のままだと、ログイン、API、メール、画像配信だけ壊れることがあります。

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

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

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

• 旧サーバーのアクセスログが十分減っている
• 旧メール設定へ流れていない
• ボットや外部サービスのアクセスが新環境へ移っている
• フォームや webhook の送信先が新環境で動いている
• 証明書更新や cron の実行先が新環境へ移っている

見た目は新しいサイトになった と 旧環境を止めてよい は別です。

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

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

1. Web 表示と主要下層ページ
2. 管理画面ログインと問い合わせフォーム
3. MXレコード、SPF、DKIM、実メール受信
4. SSL/TLS エラー、混在コンテンツ、API接続
5. サブドメインと外部連携
6. CDN / プロキシ / キャッシュ挙動
7. 旧環境ログと停止可否

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

まとめ

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

特に事故になりやすいのは、MXレコード の見落とし、TTL とキャッシュの読み違い、CDN やプロキシ経由の挙動差、旧環境停止の早すぎです。
切り替え前に確認項目を用意し、切り替え後は Web → メール → SSL → 旧環境 の順で潰していくと、かなり落ち着いて進めやすくなります。

参考リンク

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