TXTレコードとNSレコードは、ドメインの頂点（example.com）では問題なく並べて使えます。つまずくのは、sub.example.com のようなサブドメインをNSレコードで別のDNSに委任したときで、その名前とその下のTXTは、親ゾーンではなく委任先のゾーンに書かないと応答されません。この記事では、この仕組みと、SPF・所有権確認・ACMEのDNS認証などでの具体的な置き場所、正しく応答されているかの確かめ方を説明します。
頂点での併用は通常の状態
example.com を dig で問い合わせると、NSとTXTが両方返るのは普通のことです。
dig +short example.com NS
dig +short example.com TXTns1.example.net.
ns2.example.net.
"v=spf1 include:_spf.example.net ~all"
"google-site-verification=your-verification-code"頂点のNSは「このゾーンを管理しているネームサーバー」を示すもので、同じ名前にSOA、MX、TXTなどが並びます。CNAMEと違い、NSは他のレコードと同じ名前に共存できます。頂点での併用で気をつけるのは、ネームサーバーを別のサービスに切り替えるときに、TXTを新しいサービスへ写し忘れないことです。SPFやDMARC（_dmarc.example.com）、DKIM、各種サービスの所有権確認がTXTで登録されていることが多く、写し忘れるとメールの到達やサービスの認証に影響します。
サブドメインを委任すると何が変わるか
親ゾーン example.com に次のNSレコードを置くと、sub.example.com 以下の管理は別のネームサーバーに移ります。これを委任と呼び、NSを置いた位置をゾーンの境界（ゾーンカット）と呼びます。
; 親ゾーン example.com の中
sub.example.com. 3600 IN NS ns1.other-dns.example.
sub.example.com. 3600 IN NS ns2.other-dns.example.この状態で、親ゾーンに sub.example.com のTXTを書いても、親のネームサーバーはそれを答えません。sub.example.com について聞かれると、「それは委任先に聞いてください」という紹介（リファラル）を返すだけです。親ゾーンの中で境界より下にあるデータは、親にとって管理対象外として扱われます。
整理すると、次のようになります。
- 親ゾーンに書くもの: 委任のためのNS、委任先ネームサーバーのグルー（必要な場合のA/AAAA）、DNSSECを使う場合のDS
- 委任先ゾーンに書くもの:
sub.example.com自身のSOA・NS・TXT・A・MXなど、その下の名前のレコードすべて
管理画面によっては、委任したのと同じ名前にTXTを登録しようとするとエラーになったり、登録できても応答されなかったりします。後者は気づきにくいため、次の確認手順で応答を見るのが確かです。
よくある場面ごとの置き場所
サブドメインをメール配信や別サービスに任せた
mail.example.com をメール配信サービスのDNSに委任した場合、そのサブドメインのSPFやDKIM、DMARCは委任先で管理します。多くのサービスは必要なTXTを自動で作るか、管理画面で設定する方法を案内しています。親ゾーンに同じTXTを書き足しても効きません。
なお、DMARCは送信元ドメインのDMARCが見つからないとき、組織のドメイン（example.com）のDMARCが参照される仕組みがあります。委任先にDMARCを置かない場合の扱いも、運用方針として決めておきます。
ACMEのDNS認証（DNS-01）を別のDNSに任せる
ワイルドカード証明書の自動更新などで、_acme-challenge.example.com だけを更新用のDNSに任せる構成があります。CNAMEで別名に向ける方法と、NSで委任する方法があり、Let's Encrypt はどちらもたどって検証します。NSで委任した場合、認証用のTXTは委任先のゾーンに作られる必要があります。certbot のDNSプラグインなどで自動化しているなら、プラグインが書き込む先が委任先のDNSになっているかを確かめます。
サブドメインの所有権確認
検索エンジンやクラウドサービスでサブドメイン単位の所有権確認を求められた場合も、そのサブドメインが委任されていれば、確認用TXTは委任先に置きます。
応答を確かめる手順
1. 委任されているかを確かめる
dig +short NS sub.example.com親と違うネームサーバーが返れば、委任されています。何も返らない、または親と同じなら委任はありません。
2. 親と委任先のそれぞれに問い合わせる
# 親のネームサーバーに直接（再帰なし）
dig @ns1.example.net +norecurse sub.example.com TXT
# 委任先のネームサーバーに直接
dig @ns1.other-dns.example +norecurse sub.example.com TXT親への問い合わせは、ANSWERが空で、AUTHORITYセクションに委任先のNSが並ぶのが正しい形です。委任先への問い合わせでは、ANSWERにTXTが入り、flags: に aa（権威ある応答）が付きます。委任先の応答にTXTが無ければ、書き込み先を間違えています。
3. 外から見た結果を確かめる
dig +trace sub.example.com TXT
dig @8.8.8.8 +short sub.example.com TXT+trace はルートから順に委任をたどるので、どこで紹介され、どこが答えたかが分かります。公開DNSで期待どおりの値が返れば、利用者側からも見えています。
委任の設定でつまずきやすい点
- 親と委任先でNSの内容が違う: 親に書いたNSと、委任先ゾーンの頂点に書いたNSは一致させます。食い違うと、リゾルバーによって問い合わせ先が変わり、応答が不安定になります
- 委任先にゾーンが作られていない: 親でNSを足しただけで、委任先のDNSサービスにゾーンが無いと、
REFUSEDやSERVFAILになります。委任先でゾーンを作ってから親にNSを足す順にします - SPFのTXTが複数ある: 同じ名前に
v=spf1で始まるTXTが2つ以上あると、SPFの評価がエラーになります。委任先へ移すときに旧設定を残さないようにします - 長いTXTの扱い: DKIMの公開鍵のような長い値は、1つの文字列が255バイトまでという制限から複数の文字列に分けて登録されます。DNSサービスが自動で分けるかどうかは、それぞれの仕様を確認します
DNSの変更は、管理画面のエクスポートやゾーンファイルのコピーを取ってから行い、TTLを確認して反映待ちの時間を見積もっておきます（2026年10月現在、DNSサービスの画面や入力方法は各社で異なり、変わることがあります）。
まとめ
- 頂点ではNSとTXTの併用は通常の状態で、NS切り替え時にTXTを写すことが要点
- サブドメインをNSで委任すると、その名前と下位のTXTは委任先ゾーンに書く
- 親ゾーンに残すのは委任のNS、必要なグルー、DNSSECのDSだけ
- 親と委任先に
+norecurseで問い合わせ、紹介とaa付きの応答を見分ける - 委任先のゾーンを先に用意し、親と委任先のNSをそろえる