ネームサーバーの変更は、ドメインのDNS情報を管理する場所そのものを引っ越す作業です。サイトのAレコードだけを意識して切り替えると、メールが届かなくなる、サイトが一部の環境で見えなくなる、といったトラブルが起きがちです。この記事では、変更前に準備すること、切り替えの瞬間に気をつけること、変更後の確認方法を、起きやすい失敗とあわせて整理します。具体的な操作手順ではなく、事前に知っておきたい落とし穴を中心にまとめています。
ネームサーバー変更で何が切り替わるのか
ネームサーバーを変更すると、そのドメインに関するすべての問い合わせが新しいDNSサービスへ向かうようになります。サイトのAレコードだけでなく、メールのMX、SPFやDMARCのTXT、サブドメイン、各種サービスの所有権確認用レコードなども、新しいDNS側に登録されている内容で答えが返るようになります。
言い換えると、新しいDNSに入っていないレコードは、切り替えた瞬間に「存在しない」扱いになります。ネームサーバー変更のトラブルの多くは、このレコードの移し漏れが原因です。
変更前の準備
現在のレコードをすべて書き出す
最初に、今のDNSに登録されているレコードを一覧にします。管理画面にゾーンファイルの書き出し機能があれば利用し、無ければ画面を見ながら記録します。dig で主要なレコードを確認しておくのも有効です。
dig +short example.com NS
dig example.com A +noall +answer
dig example.com AAAA +noall +answer
dig www.example.com +noall +answer
dig example.com MX +noall +answer
dig example.com TXT +noall +answer
dig _dmarc.example.com TXT +noall +answerdig では名前を指定したものしか調べられないため、サブドメインや DKIM（セレクタ名._domainkey の形の名前）は管理画面の一覧で漏れなく確認します。特に移し漏れが多いのは次のものです。
- MX・SPF・DKIM・DMARC：メールの受信と送信元認証。抜けるとメールが届かない、迷惑メール扱いになる
- 所有権確認用のTXT：Google Search Console などの確認用の値。消えると再確認を求められることがある
- サブドメイン：ステージング環境、メール配信サービス用、CDN用のCNAMEなど
- CAA：SSL証明書を発行できる認証局を制限している場合、移し忘れると証明書の更新に影響することがある
新しいDNSに先にレコードを登録する
ネームサーバーを切り替える前に、新しいDNSサービス側へすべてのレコードを登録しておきます。切り替え前でも、新しいネームサーバーに直接問い合わせれば登録内容を確認できます。
dig @new-ns1.example.net example.com MX +noall +answer旧DNSと新DNSに同じ質問をして、答えがそろっていることを確かめてから次に進みます。
TTLを短くしておく
レコードのTTLを前もって短くしておくと、移行中に問題が見つかったときの修正が早く広まります。ただし、ネームサーバー自体の情報は .com や .jp などの上位のレジストリ側でもキャッシュされており、こちらのTTLは所有者が変更できません。.com では2日（172800秒）が一般的で、切り替えには最大で数日程度かかると見込んでおきます。
DNSSECを有効にしている場合は特に注意
旧DNSで DNSSEC を有効にしている場合、そのまま別の事業者のネームサーバーへ切り替えると、DNSSECの検証を行うキャッシュDNSでは名前解決に失敗し（SERVFAIL）、サイトにもメールにもつながらなくなる恐れがあります。上位に登録されているDSレコードが、旧DNSの署名鍵を指したままになるためです。
一般的には、次のどちらかで対応します。
- 切り替え前にレジストラ（ドメイン登録業者）でDSレコードを削除し、そのTTLが切れるのを待ってからネームサーバーを変更する。新DNSで安定してから改めて DNSSEC を有効にする
- 新旧の事業者が対応している場合に限り、署名鍵を引き継ぐ移行方法を使う
どちらが使えるかは事業者によって異なるため（2026年10月現在）、移行先のDNSサービスのドキュメントを確認してください。DNSSECを使っているかどうかは dig example.com DS +short で何か返るかで分かります。
切り替え時の注意
旧DNSと旧サーバーはすぐに止めない
ネームサーバーの切り替え中は、キャッシュの状況によって旧DNSに問い合わせる利用者と新DNSに問い合わせる利用者が混在します。この期間に旧DNSの契約を解約したり、旧DNSのレコードを消したりすると、旧DNSを参照している利用者からは見えなくなります。
切り替え後少なくとも数日間は、旧DNSを残し、内容を新DNSと同じに保っておきます。移行期間中にレコードを変更する必要が出たら、新旧の両方に同じ変更を入れます。サーバー移転を兼ねている場合は、旧サーバーのサイトやメールボックスも同じ期間残しておくと、取りこぼしを防げます。
ネームサーバーの変更はレジストラで行う
ネームサーバーの設定を変更するのは、DNSサービスの画面ではなく、ドメインを登録しているレジストラ（またはドメインを管理しているサーバー会社）の管理画面です。新しいDNSサービスが指定するネームサーバー名を、すべて正確に入力します。ネームサーバーを1台しか登録しない、旧DNSと新DNSのネームサーバーを混ぜて登録する、といった状態は、問い合わせ先によって答えが変わる原因になるため避けます。
自分のドメイン名を使ったネームサーバー（例: ns1.example.com）を使う場合は、上位へのグルーレコードの登録も必要になります。
WordPressサイトで見落としやすい点
- メールの送信設定：WordPress から SMTP プラグイン経由でメールを送っている場合、SPF や DKIM のレコードが新DNSにそろっていないと、問い合わせフォームの通知などが届きにくくなる
- SSL証明書：サーバー側で Let's Encrypt などの証明書を自動更新している場合、DNSの向き先が変わると更新に失敗することがある。切り替え後に証明書の有効期限と更新状況を確認する
- CDNのプロキシ機能：Cloudflare などにネームサーバーを移してプロキシを有効にすると、SSLの設定の組み合わせによってはリダイレクトが繰り返される場合がある。サーバー側の証明書の状態とCDN側のSSL設定を合わせる（設定名は変わることがあるため、公式ドキュメントで確認する）
作業前には、WordPress のファイルとデータベースのバックアップを取っておきます。DNSの変更そのものはサイトのデータに触れませんが、サーバー移転やプラグイン設定の変更を同時に行うことが多いためです。
変更後の確認
上位のレジストリに新しいネームサーバーが登録されたかは、キャッシュを通さずに確認できます。
# 上位からたどってNSを確認（途中経過にTLDが返すNSが表示される）
dig +trace example.com NS
# 公開DNSで見えているNS
dig @8.8.8.8 example.com NS +short
dig @1.1.1.1 example.com NS +short新しいネームサーバー名が返るようになったら、サイトの表示、メールの送受信（外部のアドレスとの往復）、サブドメイン、所有権確認が必要なサービスを順に確かめます。数日たって旧DNSへの問い合わせがなくなったと判断できたら、旧DNSの契約を整理します。
まとめ
- ネームサーバー変更では、新DNSに無いレコードは切り替えた瞬間に「存在しない」扱いになる
- MX・SPF・DKIM・DMARC・所有権確認用TXT・サブドメイン・CAA を漏れなく書き出し、先に新DNSへ登録する
- DNSSEC を使っている場合は、DSレコードの扱いを決めてから切り替える
- 上位のNS情報は所有者が短くできないため、移行期間は数日見込み、旧DNSを同じ内容で残す
- 変更後は
dig +traceと公開DNSでNSを確認し、サイト・メール・証明書を順に点検する