2026年6月14日

TXTレコードとNSレコードを併用する設定｜TXTを追加する前にNSで有効なDNSを確かめる

DNS・名前解決

TXTレコードは、NSレコードが指しているDNSサービスに登録したときだけ外部から見えます。レジストラ、レンタルサーバー、Cloudflare など複数の管理画面にDNSの設定欄がある場合、NSが向いていない画面にTXTを足しても、保存はできるのに応答されません。この記事では、NSから「今効いているDNSサービス」を特定し、そこにTXTを追加して、権威サーバーの応答で確認するまでの手順を説明します。

サブドメインをNSで別のDNSに委任している場合の置き場所は、委任先のゾーンになります。この記事ではドメイン全体（example.com）のTXTを扱います。

なぜ「どこに書くか」でつまずくのか

ドメインを取得したレジストラは、多くの場合DNSの管理画面も用意しています。レンタルサーバーにもDNSの設定画面があり、Cloudflare を使えばそこにもDNSの画面があります。どの画面でもTXTを登録できますが、インターネットから実際に問い合わせが届くのは、レジストリに登録されたNSが指すネームサーバーだけです。

たとえばNSを Cloudflare に向けているのに、レンタルサーバーの画面にSPFや所有権確認のTXTを追加すると、次のような症状になります。

管理画面にはレコードが表示されているのに、Google Search Console のドメイン所有権の確認が通らない
SPFを追加したはずなのに、受信側の検査で「SPFレコードが見つからない」と判定される
Let's Encrypt のDNS認証（DNS-01）が、TXTが見つからないという理由で失敗する

設定内容が正しくても、置き場所が違えば結果は「レコードが無い」と同じです。値を見直す前に、まず置き場所を確かめます。

手順1：レジストリに登録されたNSを調べる

最初に、ドメインのNSを確認します。

dig +short NS example.com

ada.ns.cloudflare.com.
bob.ns.cloudflare.com.

この結果はキャッシュDNSを通した答えです。NSを変更した直後などで結果が怪しいときは、親であるTLDのネームサーバーに直接聞くと、レジストリに登録されている値そのものが分かります。

# .com の場合（gTLDのネームサーバーに直接聞く）
dig @a.gtld-servers.net example.com NS +norecurse

# .jp の場合
dig @a.dns.jp example.jp NS +norecurse

TLDのサーバーは委任の情報を返すので、結果はANSWERではなくAUTHORITYセクションに並びます。Windows では nslookup -type=NS example.com でも確認できます。

手順2：NSのホスト名からDNSサービスを特定する

NSのホスト名を見れば、どのサービスが応答しているかがおおむね分かります。

*.ns.cloudflare.com で終わる: Cloudflare
ns-数字.awsdns-数字.com などの形: Amazon Route 53
レンタルサーバーやレジストラのドメイン名を含む: そのサービスのDNS

ホスト名の付け方は各社のマニュアルに載っています。見慣れない名前なら、そのホスト名で検索するか、契約しているサービスの案内と照らし合わせます。ここで特定したサービスの管理画面が、TXTを書き込む先です。ほかの画面にある同じ名前のTXTは、今は使われていません。紛らわしい場合は、使っていない画面の古いレコードを整理しておくと、次の作業で迷わずに済みます（削除する前に内容は控えておきます）。

手順3：特定したDNSサービスでTXTを追加する

管理画面でTXTを追加するときに確認する点は次のとおりです。画面の項目名はサービスごとに異なり、変更されることもあります（2026年10月現在）。

名前（ホスト）欄: ドメインそのものに付けるなら @ や空欄を指定する方式が多く、_dmarc のような下位の名前はその部分だけを入力します。_dmarc.example.com と入力すると、ドメイン名が自動で付け足されて _dmarc.example.com.example.com になる画面があります
値の欄: 前後のダブルクォーテーションは自動で付くことが多いので、案内された値をそのまま貼ります。余分なクォーテーションや空白が入ると、別の文字列として扱われます
既存のTXTは消さない: 同じ名前に複数のTXTを並べるのは普通のことで、所有権確認のトークンやSPFが共存します。新しい値を追加するときは、既存のレコードを上書きしないようにします
SPFは1つにまとめる: v=spf1 で始まるTXTが同じ名前に2つあると、SPFの評価がエラーになります。送信サービスを増やすときは、既存のSPFに include: を足して1行にまとめます
TTL: 試行錯誤する間は短め（300秒程度）にしておくと、入力を直したときに早く反映されます

手順4：権威サーバーに直接問い合わせて確認する

追加したら、手順1で確認したNSのそれぞれに、再帰なしで直接聞きます。キャッシュの影響を受けないので、登録がすぐ反映されているかを確かめられます。

dig @ada.ns.cloudflare.com example.com TXT +norecurse
dig @bob.ns.cloudflare.com example.com TXT +norecurse

ANSWERセクションに追加したTXTが入り、flags: に aa（権威ある応答）が付いていれば、置き場所も値も正しく登録されています。ここで見えなければ、まだ手順3の画面を疑います。

権威サーバーで見えるのに外部の検査ツールで見えない場合は、キャッシュDNSが以前の「レコードが無い」という答えを覚えている可能性があります。この否定の答えは、SOAレコードに書かれた時間だけ保持されます。公開DNSの結果を確認し、しばらく待ってから再確認します。

dig @8.8.8.8 +short example.com TXT
dig @1.1.1.1 +short example.com TXT

NSそのものがおかしいときの直し方

手順1の段階で、NSの状態に問題が見つかることもあります。代表的なものと対処は次のとおりです。

2つのサービスのNSが混ざっている

レジストラの設定で、1つ目はAサービス、2つ目はBサービスのネームサーバー、という状態になっていることがあります。移行の途中で片方だけ書き換えた場合によく起こります。この状態では、問い合わせがどちらに届くかで答えが変わり、TXTが「見えたり見えなかったり」します。どちらか一方に統一し、使うサービスにレコードをそろえてからレジストラのNSを書き直します。

NSの先にゾーンが無い

NSが指すサービスで、ドメインのゾーン（DNSの設定一式）が作られていない、または契約が終わって削除されていると、問い合わせは REFUSED や SERVFAIL になります。この状態ではTXTに限らず、Webサイトやメールの名前解決も失敗します。応答しているサービスでゾーンを作り直すか、レジストラのNSを正しいサービスに戻します。

レジストリのNSとゾーン内のNSが違う

TLDに登録されたNSと、ゾーンの頂点に書かれたNSレコードは一致させるのが原則です。マネージドDNSでは頂点のNSを自動で管理していることが多いので、自前のDNSサーバーやゾーンファイルを使っている場合に確認します。

WordPress運用で関係する場面

WordPressサイトでTXTを追加する場面は、主に次の3つです。

Google Search Console でドメインプロパティを登録する
WP Mail SMTP などでメール送信サービスを使うために、SPF・DKIM・DMARCを設定する
ホスティング会社やCDNで、独自ドメインの所有確認や証明書の発行を行う

レンタルサーバーで「無料SSLの設定」や「メールの認証設定」を画面から有効にすると、そのサーバーのDNSに自動でレコードが作られることがあります。NSを Cloudflare など外部に向けている場合、自動で作られたレコードは効かないので、同じ内容を外部のDNSに手で追加する必要があります。サーバー側の設定を変えたときは、DNSの画面にも作業が要るかを確認する習慣を付けておくと安心です。

DNSのレコードを変更する前には、管理画面のエクスポート機能や画面の控えで現在の内容を保存しておきます。

まとめ

TXTは、NSが指しているDNSサービスに登録したときだけ応答される
dig NS とTLDのサーバーへの +norecurse の問い合わせで、レジストリに登録されたNSを確かめる
NSのホスト名から、書き込むべき管理画面を特定する
追加後は権威サーバーに直接問い合わせ、aa 付きの応答にTXTがあるかを見る
NSの混在、ゾーンの不在、レジストリとゾーンのNSの不一致は、TXT以前に直す