ネームサーバー（NS）を別のDNSサービスへ切り替えると、その瞬間から世界中のキャッシュDNSは新しいDNSサービスだけを見に行きます。旧DNSに書いてあったTXTレコード（SPF・DKIM・DMARC・各種サービスの所有確認）は、新しいDNSに同じ内容を用意しておかない限り「無いもの」として扱われます。この記事では、NSを切り替える前にTXTを洗い出し、新しいDNSへ写し、権威サーバーに直接問い合わせて一致を確かめてから切り替える手順を説明します。
サブドメインの委任でTXTをどちらのゾーンに置くか、NSに複数のDNSサービスが混在している場合の揃え方は別の観点なので、この記事では扱いません。ここでは「DNSサービスの引っ越し」に絞ります。
NSとTXTはどういう関係にあるのか
NSレコードは「このドメインの情報はどのサーバーが答えるか」を示す案内板です。ドメインの登録先（レジストラ）経由で親ゾーン（.com や .jp など）に登録されたNSが、実際に使われる案内板になります。TXTレコードは、その案内先のDNSサービスの中に書かれた中身の一つです。
ゾーンの頂点（example.com そのもの）にNSとTXTが同時にあるのはごく普通の状態で、併用そのものに問題はありません。つまずくのは、案内板（NS）を新しいDNSに向け直したのに、中身（TXT）を新しいDNSへ移していなかった場合です。このときウェブサイトは表示されていても、次のような不具合がしばらくしてから出てきます。
- 送信したメールがSPF・DKIM・DMARCの検証に失敗し、迷惑メール扱いや受信拒否になる
- Google Search Console などの所有確認が外れ、確認し直しを求められる
- Let's Encrypt のDNS認証（
_acme-challenge）を使う証明書の更新が失敗する
キャッシュに古い応答が残っている間は問題が表に出ないため、切り替えから数時間〜数日たってから気付くことが多いのが厄介な点です。
手順1：今のTXTをすべて洗い出す
まず旧DNSの管理画面で、ゾーンのエクスポート（ゾーンファイルのダウンロード）ができるか確認します。多くのDNSサービスはBIND形式でのエクスポートに対応しています。画面の一覧だけを見て書き写すと、長いDKIMの値や、アンダースコアで始まる名前を見落としやすいためです。
エクスポートできない場合や、念のため外からも確かめたい場合は、旧DNSの権威サーバーへ直接問い合わせます。TXTはゾーンの頂点だけでなく、さまざまな名前の下に置かれている点に注意してください。
# 現在登録されているNSを確認
dig example.com NS +short
# 旧DNSの権威サーバー（例: ns1.old-dns.example）に直接問い合わせる
dig @ns1.old-dns.example example.com TXT +norec
dig @ns1.old-dns.example _dmarc.example.com TXT +norec
dig @ns1.old-dns.example selector1._domainkey.example.com TXT +norec
dig @ns1.old-dns.example _acme-challenge.example.com TXT +norecDNSは「名前の一覧」を外から取得できない仕組みなので、DKIMのセレクター名（selector1 の部分）は、利用しているメールサービスの管理画面や、受信したメールの DKIM-Signature ヘッダーの s= の値から調べます。ここで漏れたTXTは移行後に消えるため、エクスポートとの突き合わせが大切です。
あわせて、CNAMEで書かれた認証用レコードも洗い出しておきます。DKIMや証明書の検証では、TXTではなくCNAMEで外部サービスの値を参照する方式も一般的です。
手順2：新しいDNSにゾーンを作り、TXTを写す
新しいDNSサービスにゾーンを作り、エクスポートしたゾーンファイルを取り込むか、手作業でレコードを登録します。このとき注意したい点が3つあります。
1つ目は、旧DNSの頂点のNSレコードとSOAレコードを持ち込まないことです。新しいDNSサービスは自分のネームサーバーを頂点のNSとして自動で設定します。旧DNSのNSが混ざったまま残ると、問い合わせ先が二重になり、応答が食い違う原因になります。取り込み機能が旧NSを読み込んだ場合は、新しいサービス側のNSだけが残るように整理します。
2つ目は、長いTXTの書き方です。TXTの値は1つの文字列が255バイトまでなので、2048ビットのDKIM公開鍵などは複数の文字列に分けて書かれています。ゾーンファイルでは次のように引用符で区切られた形になります。
selector1._domainkey.example.com. 3600 IN TXT ( "v=DKIM1; k=rsa; p=MIIBIjANBgkq...前半..."
"...後半...IDAQAB" )管理画面によっては1行にまとめて貼り付ければ自動で分割してくれるもの、引用符ごと貼ると引用符まで値に含めてしまうものがあり、挙動はサービスごとに異なります。取り込んだ後に、値が元と同じ文字列として返ってくるかを手順3で確かめます。
3つ目は、同じ名前に複数のTXTがある場合です。ドメインの頂点には、SPFと複数の所有確認用TXTが並んでいることがよくあります。1つにまとめて登録してしまうと別の値として扱われるので、元と同じ数だけ個別に登録します。なお、SPF（v=spf1 で始まるもの）は同じ名前に1つだけにする決まりがあるので、移行を機に重複が見つかった場合は統合を検討してください。
手順3：切り替える前に新しいDNSへ直接問い合わせる
NSを切り替える前でも、新しいDNSサービスの権威サーバーに直接問い合わせれば、切り替え後に返る内容を先に確認できます。旧DNSと新DNSで応答を並べて比べるのが確実な確かめ方です。
OLD=ns1.old-dns.example
NEW=ns1.new-dns.example
for name in example.com _dmarc.example.com selector1._domainkey.example.com; do
echo "== $name"
diff <(dig @$OLD $name TXT +short | sort) <(dig @$NEW $name TXT +short | sort) && echo "一致"
done差分が出た場合は、引用符の扱い、余分な空白、文字列の分割位置を見直します。分割位置が違っても、受信側は連結した文字列で検証するため実害が無いこともありますが、連結した結果が元と同じになっているかは確かめておきます。
TXT以外のA・AAAA・MX・CNAMEも同じ方法で比べておくと、ウェブやメールの切り替え漏れも同時に防げます。
手順4：NSを切り替え、旧DNSはしばらく残す
レジストラの管理画面でネームサーバーを新しいDNSサービスのものに変更します。親ゾーンに登録されたNSにはTTLがあり、その値は数時間から2日程度とTLDによって異なります（2026年10月現在）。実際の値は、親ゾーンの権威サーバーに dig で問い合わせると確認できます。この間は旧DNSを見に行くキャッシュDNSと、新DNSを見に行くキャッシュDNSが混在します。
そのため、切り替え後も旧DNSのゾーンは少なくとも数日は削除せず、内容も変更しないでおきます。TXTを追加・変更する必要が出た場合は、両方のDNSに同じ変更を入れます。
もう一つ注意が必要なのが DNSSEC です。旧DNSでDNSSECを有効にしていて、レジストラにDSレコードが登録されている場合、そのままNSを切り替えると新しいDNSの応答が検証に失敗し、DNSSECを検証するリゾルバからはドメイン全体が引けなくなります。移行前にDSを外して十分に時間をおくか、移行先と旧DNSの両方の鍵を扱える手順を取るなど、DNSSECの移行は別途計画してください。
手順5：切り替え後に外から確かめる
切り替えが進んだら、公開DNSから見たNSとTXTを確認します。
dig example.com NS +short @1.1.1.1
dig example.com TXT +short @8.8.8.8
dig _dmarc.example.com TXT +short @8.8.8.8メールについては、Gmail など外部のアドレスへテストメールを送り、受信したメールのヘッダー（Gmailでは「メッセージのソースを表示」に相当する画面）にある Authentication-Results で、spf=pass、dkim=pass、dmarc=pass になっているかを見ます。DNSの応答だけでなく、実際に届いたメールで確かめるのが確実です。
Search Console などの所有確認は、サービス側が定期的にTXTを再確認するため、切り替え直後は問題が無くても後日外れることがあります。移行から1〜2週間は、管理画面で確認状態が保たれているかを見ておくと安心です。
WordPressサイトで見落としやすい点
WordPressサイトのDNSを移す場合、ウェブサイトの表示（Aレコード）だけを確認して作業を終えてしまいがちです。しかし、お問い合わせフォームや会員登録のメールは、WP Mail SMTP などのプラグイン経由で外部のメール送信サービスを使っていることが多く、そのサービスのSPFやDKIMはTXTやCNAMEで設定されています。移行後にフォームからテスト送信して、届くことと認証結果を確認してください。
また、セキュリティプラグインやCDNの導入時に追加した所有確認用のTXTも、移行対象から漏れやすいレコードです。用途の分からないTXTは削除せず、そのまま新しいDNSへ写しておき、用途を調べてから整理する順番にすると事故を防げます。
まとめ
- NSを切り替えると、旧DNSに書いたTXTは使われなくなる。新しいDNSに同じTXTを用意してから切り替える
- TXTはゾーンの頂点だけでなく
_dmarcやDKIMのセレクター名の下にもある。エクスポートとメール設定の両方から洗い出す - 旧DNSの頂点のNS・SOAは新しいゾーンに持ち込まない。長いTXTの分割や引用符の扱いは取り込み後に確かめる
- 切り替え前に新旧の権威サーバーへ直接問い合わせ、応答を比べる
- 切り替え後も旧DNSは数日残し、DNSSECを使っている場合はDSの扱いを別途計画する
- メールは実際に送って
Authentication-Resultsで認証結果を確認する