TXTレコードを追加したのに反映されないときは、「追加した場所（DNSサービス）が正しいか」「名前が意図どおりか」「権威サーバーが返しているか」「値の書き方が正しいか」「キャッシュが残っているだけか」の順に確かめると、多くの場合は原因を絞り込めます。この記事では、ドメインの所有権確認、Let's Encrypt のDNS認証（DNS-01）、SPF・DKIM・DMARCなど、TXTレコードを使う代表的な場面を念頭に、それぞれの段階での検証コマンドと、見つかった原因の直し方を説明します。
まず症状を2つに分ける
「反映されない」には、性質の違う2つの状態があります。
- TXTが返ってこない:
digで問い合わせても、追加した値が出てこない - TXTは返るが、確認や認証に通らない: 値は見えているのに、サービス側の確認や、メールの認証結果が失敗になる
前者はDNSのどこかで止まっている状態で、後者は値の中身や、同じ名前の他のレコードとの関係に問題があることが多い状態です。以下では、前者の確認から順に進めます。
検証1：追加したDNSサービスが使われているか
もっとも多い原因が、実際には使われていないDNSサービスにTXTを追加しているケースです。ドメインを取得した会社と、DNSを管理しているサービス（CDNやレンタルサーバー）が別になっていると起こります。
# 実際に使われている権威サーバーを確認
dig +short NS example.com表示されたネームサーバーのホスト名から、どのサービスがDNSを管理しているかを判断します。TXTを追加した管理画面と一致しなければ、表示されたサービスの側に追加し直します。サブドメインを別のサービスに委任している場合は、そのサブドメインのNSも同じように確かめます。
検証2：名前が意図どおりか
管理画面の「ホスト名」欄に何を入れたかで、実際の名前が変わります。多くの管理画面では、入力した値の後ろにドメイン名が自動で付け足されます。そのため、_dmarc.example.com と入力すると、_dmarc.example.com.example.com という名前で登録されていることがあります。
# 意図した名前
dig +short _dmarc.example.com TXT
# ドメイン名が二重に付いた名前で登録されていないか
dig +short _dmarc.example.com.example.com TXT後者で値が返ってきたら、ホスト名の欄を _dmarc だけに直します。逆に、頂点（example.com そのもの）に追加するときは、空欄にするのか @ を入れるのかがサービスによって違うので、資料で確かめます（2026年10月現在）。
検証3：権威サーバーが返しているか
名前が正しければ、権威サーバーに直接問い合わせます。キャッシュDNSを通さないので、DNSサービスに登録された内容そのものが分かります。
# 権威サーバーに直接問い合わせる（ns1.example.net は検証1で調べたホスト名に置き換える）
dig @ns1.example.net _acme-challenge.example.com TXT +norecurse
# すべての権威サーバーで同じ答えか確かめる
for ns in $(dig +short NS example.com); do
echo "== $ns"
dig @$ns _acme-challenge.example.com TXT +norecurse +short
doneWindowsでは、PowerShellの Resolve-DnsName で同じ確認ができます。
Resolve-DnsName -Name _acme-challenge.example.com -Type TXT -Server ns1.example.net権威サーバーでも返らない場合は、管理画面で保存が完了していない、別のゾーンに追加している、自前のDNSサーバーならゾーンの再読み込みやシリアル番号の更新を忘れている、といった原因が考えられます。権威サーバーの一部だけが古い場合は、セカンダリへの転送が遅れています。
同じ名前にCNAMEがないか
権威サーバーに問い合わせたとき、TXTではなくCNAMEが返ってくることがあります。CNAMEがある名前には他のレコードを置けないため、その名前のTXTは無視され、問い合わせはCNAMEの向け先へ進みます。Let's Encrypt のDNS認証では、_acme-challenge をCNAMEで別のドメインに向けて運用する方法があり、その場合はTXTを向け先の名前の側に置く必要があります。以前に設定したCNAMEが残っていないかを確かめます。
検証4：値の書き方が正しいか
TXTが返ってくるのに確認や認証に通らない場合は、値の中身を確かめます。
- 余分な引用符や空白: 管理画面によっては、値を
"で囲んで入力すると、引用符そのものが値の一部として登録されます。digの出力で"\"v=spf1 ...\""のように引用符が二重になっていないかを見ます - 長い値の分割: TXTの1つの文字列は255バイトまでです。2048ビットのDKIM公開鍵のように長い値は、1つのレコードの中で複数の文字列に分けて登録します。分割を自動で行う管理画面と、利用者が分ける必要がある管理画面があります。分けた文字列は、受け取る側で区切りなしにつなげて読まれるため、分割の位置に空白を入れないようにします
- SPFが2つある: 同じ名前に
v=spf1で始まるTXTが2つ以上あると、SPFの評価はエラー（permerror）になります（RFC 7208）。複数のメール送信サービスを使う場合は、1つのレコードにinclude:を並べてまとめます - 確認用の値の取り違え: 所有権確認の値は、サービスや確認のたびに発行し直されることがあります。管理画面に表示されている最新の値と、1文字ずつ照らし合わせます
同じ名前に複数のTXTがあること自体は問題ありません。所有権確認の値とSPFを頂点に並べて置くのは、よくある構成です。
検証5：キャッシュが残っているだけか
権威サーバーが正しい値を返していれば、残っているのはキャッシュです。公開DNSに問い合わせて、TTL欄の残り秒数を見ます。
dig @8.8.8.8 _dmarc.example.com TXT +noall +answer +authority古い値が返っていれば、TTLの秒数が0になった後に新しい値に変わります。値が返らず、AUTHORITYセクションにSOAが表示されている場合は、追加する前に誰かがこの名前を問い合わせて「存在しない」という答えがキャッシュされています。その残り時間は、表示されたSOAの横のTTLです。
確認を行うサービス側も、独自のキャッシュDNSを使っていることがあります。権威サーバーと公開DNSで正しい値が見えているのに確認に失敗する場合は、しばらく時間を置いてから確認をやり直します。何度もやり直すと、サービスによっては一時的に確認を受け付けなくなることがあるので、間隔を空けて試します。
直した後の確かめ方
修正したら、権威サーバー、公開DNS、確認を行うサービスの順に結果を確かめます。メールの認証に使うTXT（SPF・DKIM・DMARC）は、自分宛てにテストメールを送り、受信したメールのヘッダー（Authentication-Results）で spf=pass や dkim=pass になっているかを見ると、実際に効いているかが分かります。
WordPressサイトで問い合わせフォームや通知メールを送っている場合は、メール送信用のプラグインやサーバーの設定と、SPFに含めた送信元が一致しているかもあわせて確認します。DNSのレコードを削除・変更する前には、現在の設定をエクスポートや画面の控えで残しておきます。
まとめ
- 「TXTが返らない」と「返るが確認に通らない」を分けて考える
dig +short NSで、TXTを追加したDNSサービスが実際に使われているかを確かめる- ホスト名の欄でドメイン名が二重に付いていないか、同じ名前にCNAMEがないかを見る
- 引用符の二重登録、255バイトを超える値の分割、SPFの重複を確かめる
- 権威サーバーで正しければ、残りはキャッシュ。TTL欄と、ネガティブキャッシュならSOAのTTLで待ち時間を読む