DNS・ネームサーバー移行チェックリスト｜サイトとメールを止めない手順

ネームサーバーを別のサービスへ移すと、そのドメインの名前解決は、移行先のDNSに登録されている内容だけで行われるようになります。移行先に必要なレコードが1つ欠けていれば、その分の機能がそのまま止まります。

特に見落とされやすいのがメールです。サイトは開いて確認できますが、メールは「届かなくなったこと」に気づくまで時間がかかることがあります。

この記事は、すでにサイトやメールで使っているドメインのDNSを移すときのチェックリストです。新しく取得したばかりで何にも使っていないドメインの場合は、独自ドメイン取得後にやることの手順で足ります。

記事の中の実例は、Web支度室の運営元Movanceが運営する別サイト「AI議事録ナビ」で、2026年10月7日に行ったConoHa WINGからCloudflareへの移行準備の記録をもとにしています。IPアドレスや認証用の値などの固有情報は掲載していません。

DNSの変更は影響が大きい作業です。 事業者ごとに管理画面や仕様が異なるため、この記事の内容がすべての環境にそのまま当てはまるわけではありません。実際の作業では、利用しているサービスの公式ドキュメントを必ず確認してください。

なぜDNS移行でメールが止まるのか

DNSには、サイト用のレコードとメール用のレコードが同じ場所に登録されています。

役割	主なレコード	欠けたときに起きやすいこと
サイト	A / AAAA / CNAME	サイトが表示されない
メールの受信	MX（＋メールサーバー名のA / CNAME）	メールが届かない
メールの送信元認証	TXT（SPF・DMARC）、DKIM（TXTまたはCNAME）	送ったメールが迷惑メール扱いされる、受け取りを拒否される
各種サービスの所有確認	TXT / CNAME	連携しているサービスで確認が外れる

ネームサーバーを切り替えると、移行元のDNSに登録されていたレコードは使われなくなります。移行先に同じ内容がそろっていないと、サイトが表示されていてもメールだけが止まる、といった状態が起こります。

Cloudflareの公式ドキュメントでも、ネームサーバー変更前のレコード確認では、ゾーン頂点（wwwなしのドメイン）やサブドメインに加えて、メール関連のレコード（MX・SPF・DKIM・DMARC）に特に注意するよう案内しています（Cloudflare公式：フルセットアップ、2026-10-07確認）。

変更前

まず、移行元のDNSに登録されているレコードを、1件ずつ書き出します。 管理画面の一覧を見るだけでなく、名前・種類・値・TTLを表にしておくと、移行先との比較に使えます。

DMARCやCAAのように、ドメインによっては存在しないレコードもあります。「ないこと」を確認したうえで記録しておけば、移行後に「消えた」のか「元からなかった」のかで迷いません。

また、DNSの管理画面に表示されていない名前がある場合や、移行先が自動で読み取ったレコードに漏れがある場合もあります。AI議事録ナビでは、Cloudflareにドメインを追加したときに既存のレコードが自動で取り込まれましたが、移行元と1件ずつ照合した結果、次の差分が見つかりました。

メールサーバーと同じ接続先を向くサブドメインのAレコードが1件、取り込まれていなかった
取り込まれたAレコード（apex・www・メールサーバー用）が、すべてプロキシ有効の状態になっていた
TTLが移行元の値ではなく、移行先の自動設定になっていた

MX・Googleの所有確認TXT・SPF・DKIMは、値が一致していることを確認しました。DKIMは長い値なので、目視ではなく、公開されているDNSの値と全文が一致するかで照合しています。

TTLを下げる

TTLは、DNSの応答がキャッシュされる時間です。TTLが長いと、変更してもしばらく古い情報が使われ続けます。Cloudflareの公式ドキュメントでも、TTLは変更が反映される速さに関わると説明されています（Cloudflare公式：TTL、2026-10-07確認）。

そこで、切り替えの前に、移行元でTTLを短くしておくことがあります。こうしておくと、切り替え後に問題があって元へ戻すときも、古い情報が残る時間を短くできます。

AI議事録ナビでの実例：移行元のConoHaで、apexと www のAレコードのTTLを3600秒から300秒に下げました。下げたあとも、それまでの3600秒分のキャッシュが残っている可能性があるため、TTLの変更から少なくとも1時間はネームサーバーの切り替えを行わない、という条件を決めています。

TTLをいくつにするかに決まった正解はありません。300秒はAI議事録ナビで採用した値です。利用しているDNSサービスで設定できる範囲も確認してください。

新DNS側にrecordsを再現

移行先のDNSに、書き出したレコードをすべて用意します。

書き出した一覧と、移行先のレコードを1件ずつ照合する
移行先にない（MISSING）レコードを追加する
移行元にない（EXTRA）レコードが勝手に増えていないか確認する
値が違う（DIFFERENT）レコードを直す
長い値（DKIMなど）は全文で一致を確認する

AI議事録ナビでは、照合の結果を「一致」「差分あり」「不足」「余分」の4つに分けて記録し、最終的に不足0件・余分0件になったことを確認してから次へ進みました。残った差分は、TTLの値の扱い（移行先は自動設定）のみでした。

メール用recordをproxyしない

Cloudflareを使う場合に特有の注意点です。CloudflareのDNSでは、A・AAAA・CNAMEレコードに「Proxied（プロキシ有効）」と「DNS only」の設定があります。

公式ドキュメントによると、プロキシできるのはIPアドレスの解決に使うA・AAAA・CNAMEだけで、MXやTXTは常にDNS onlyです。また、メールのルーティングやサードパーティの所有確認に使うレコードのように、Webのトラフィックを扱わないレコードはDNS onlyにすることが勧められています（Cloudflare公式：プロキシ状態、2026-10-07確認）。

つまり、注意が必要なのはMXが指しているメールサーバー名などを、自分のドメインのA・CNAMEで定義している場合です。これがプロキシ有効になっていると、メールの通信がそのサーバーに届かないおそれがあります。

MXの向き先が、自分のドメイン内の名前（例：mail.example.com）かどうか確認する
その名前のA / CNAMEが、DNS onlyになっているか確認する
所有確認に使うCNAMEがプロキシ有効になっていないか確認する

AI議事録ナビでは、メールサーバーの接続先を向く2つのサブドメインのAレコード（取り込み漏れで追加した1件を含む）をDNS onlyに設定しました。あわせて、apexと www のAレコードも、切り替えの時点ではまだ移行元のサーバーを向けたままにするため、DNS onlyに設定しています。

どのレコードをDNS onlyにすべきかは、メールサービスや構成によって異なります。「メール関連はすべて同じ扱い」とは考えず、1件ずつ用途を確認してください。

Nameserver変更

移行先のレコードがそろったら、レジストラの管理画面でネームサーバーを移行先のものに変更します。

移行先が割り当てたネームサーバー名を、コピーして正確に入力する
DNSSECが有効になっていないか確認する
TTLを下げてから、決めた待ち時間が過ぎているか確認する
作業の開始時刻を記録する

DNSSECについて、Cloudflareの公式ドキュメントは、DNSSECが有効なままネームサーバーを変更するとドメインに到達できなくなるおそれがあるとして、変更前にレジストラ側で無効にするよう案内しています。また、ネームサーバーの変更はレジストラ側の反映に最大24時間かかることがあるとしています（Cloudflare公式：フルセットアップ、2026-10-07確認）。

AI議事録ナビでは、移行準備の時点でDNSSECが無効であることを確認し、移行中も無効のままにする方針にしました。

authoritative NSを確認

ネームサーバーを変更したら、権威ネームサーバー（authoritative NS）が実際に切り替わったかを確認します。管理画面で「変更した」ことと、外から見て「切り替わった」ことは別です。

Cloudflareの公式ドキュメントでは、ダッシュボードでActiveになったかを確認する方法のほか、次のコマンドでの確認方法が紹介されています。

# macOS / Linux
dig ns example.com @1.1.1.1

# Windows
nslookup -type=ns example.com 1.1.1.1

同じドキュメントでは、多くの確認ツールはキャッシュされた結果を使うため、更新後のネームサーバーが表示されるまで時間がかかることがある、とも書かれています。

NSの照会結果が移行先のネームサーバーになったか
移行先のDNSから、書き出したすべてのレコードが同じ値で返るか（DNS parity）
MX・SPF・DKIM・メールサーバー名のAレコードが、移行前と同じ値で返るか

Web配信先はすぐ変えない

ネームサーバーの移行と、サイトの配信先（ホスティング）の変更を、同じタイミングで行う必要はありません。

AI議事録ナビでは、次のように段階を分ける計画にしました。

DNSの権威を移す：サイト用のレコードは移行元のサーバーを向けたまま、ネームサーバーだけをCloudflareへ変更する
旧サーバーのままで確認する：サイトとメールが、移行前と同じように動くことを確認する
サイトの配信先を切り替える：問題がないことを確認したあとで、Cloudflare Pagesへ切り替える

こうすると、問題が起きたときに「DNSの移行が原因か」「配信先の変更が原因か」を切り分けやすくなります。1回の作業で変える範囲を小さくするための方法です。

2026-10-07時点の進み具合：AI議事録ナビでは、レコードの棚卸し、移行先でのレコード再現と照合、TTLの短縮、メール用レコードのDNS only設定までを完了しています。手順1のネームサーバー変更は承認済みですが、この記事の確認時点では実行前で、権威ネームサーバーは移行元のままでした。そのため、この記事で紹介している「切替後」の確認項目は、AI議事録ナビでまだ実施していません。

切替後

ネームサーバーや配信先を切り替えたあとに確認する項目です。

メールの送受信は、DNSの照会結果だけでは確かめられません。実際に送って、届くことを確認してください。GA4とSearch Consoleの確認方法は、GA4・Search Consoleの初期設定チェックリストで詳しく整理しています。

Rollback

切り替え後に問題が起きたときの戻し方を、作業の前に決めておきます。

DNSの権威を戻す：レジストラで、ネームサーバーを移行元のものに戻します。そのためには、移行元のDNSのレコードが消されずに残っている必要があります。
配信先だけを戻す：DNSの権威はそのままで、サイト用のレコードを移行元のサーバーへ向け直します。

どちらの場合も、戻した内容が行き渡るまでの時間は、TTLやキャッシュに左右されます。切り替え前にTTLを短くしておくのは、この時間を短くするためでもあります。

AI議事録ナビでは、ロールバック先として、移行元のネームサーバー名、サイトの接続先、メールサーバーの接続先を、切り替え前に記録しています。

48時間残すもの

切り替えが済んでも、移行元のホスティングやDNSの設定をすぐに解約・削除しないことをおすすめします。

キャッシュの関係で、しばらくは移行元のDNSやサーバーを参照する利用者が残ることがあります
問題が見つかったときに、すぐ戻せる先が必要です
メールの送受信の問題は、切り替え直後ではなく、少し時間がたってから分かることがあります

AI議事録ナビでは、移行元のConoHaのホスティングとDNSを、ロールバック先として、切り替え後少なくとも48時間は残す方針にしています。

この「48時間」は、業界で決まった標準ではありません。Movanceが安全のための余裕として採用した期間です。TTLの長さ、メールの使い方、移行元の契約期間などをふまえて、それぞれの状況に合わせて決めてください。

この記事の確認方法

確認日：2026-10-07

Movanceの移行作業で実際に確認したこと（AI議事録ナビ）

移行元のDNSに、サイト用・メール用のAレコード、MX、所有確認のTXT、SPF、DKIMが登録されていたこと
Cloudflareに自動で取り込まれたレコードと移行元を照合し、メールサーバーと同じ接続先を向くサブドメインのAレコード1件の不足、Aレコードのプロキシ有効、TTLの違いを見つけたこと。MX・所有確認TXT・SPF・DKIMは値が一致したこと
移行元でapexと www のTTLを3600秒から300秒へ下げたこと
Cloudflare側でメールサーバーの接続先を向く2件を含むAレコードをDNS onlyにし、不足0件・余分0件を確認したこと
DNSSECが無効であること
2026-10-07時点で、権威ネームサーバーが移行元のままで、サイトも移行元のサーバーから配信されていること（作業記録と、公開DNSへの照会による）

以上は作業記録にもとづきます。ネームサーバー切り替え後の確認（メールの実際の送受信を含む）は、この記事の確認時点では実施していません。

公式情報で確認したこと

ネームサーバー変更前のレコード確認、DNSSECの注意、反映時間、NSの確認方法：Cloudflare公式：フルセットアップ
プロキシできるレコードと、DNS onlyが勧められるレコード：Cloudflare公式：プロキシ状態
TTLの役割：Cloudflare公式：TTL

編集上の判断

チェックリストの項目と順番、「DNSの権威の移行と配信先の変更を分ける」進め方は、上記の作業記録と公式情報をもとにしたWeb支度室編集部の整理です。
TTL 300秒と、移行元を48時間残す方針は、AI議事録ナビで採用した値です。一般的な基準として示すものではありません。
IPアドレス、メールサーバー名、DKIMの値、アカウント情報、割り当てられたネームサーバー名などの固有情報は掲載していません。

DNS・ネームサーバー移行でサイトとメールを止めないチェックリスト