TXTレコードの検証は、「DNSが登録した値を返しているか」と「その値が用途の書式として正しいか」の2段階に分けると、どこに問題があるかを切り分けやすくなります。この記事では、権威DNSサーバーとキャッシュDNSでTXTの値を取り出す方法、dig の表示の読み方、SPF・DKIM・DMARC・サービスの所有権確認それぞれで確かめる点、実際のメールで結果を見る方法を説明します。
検証は2段階に分ける
TXTレコードは、文字列を入れておくだけの汎用のレコードです。DNSは中身の意味を気にしないため、書式が間違っていても登録はでき、問い合わせにもそのまま答えます。そのため、「DNSで見えた」ことと「SPFとして正しい」ことは別の問題です。
- 届いているか：権威サーバーとキャッシュDNSが、登録した値を返すか
- 中身が正しいか：その値が、SPFやDMARCなど、使う側が求める書式と内容になっているか
1段階目でつまずいている場合は、名前欄の書き方や、編集したDNSサービスが実際に使われているかを先に確かめます。
段階1：権威サーバーとキャッシュDNSで値を取り出す
# ネームサーバーを調べ、権威サーバーに直接問い合わせる
dig NS example.com +short
dig @ns1.example-dns.net example.com TXT +norecurse +noall +answer
# キャッシュDNSから見える値
dig @1.1.1.1 example.com TXT +short
dig @8.8.8.8 _dmarc.example.com TXT +shortWindowsでは PowerShell の Resolve-DnsName が使えます。
Resolve-DnsName example.com -Type TXT
Resolve-DnsName _dmarc.example.com -Type TXT -Server 1.1.1.1権威サーバーで値が見えず、キャッシュDNSでも見えない場合は、名前欄の誤りが多い原因です。DNSサービスの管理画面には、名前欄にドメイン名を自動で付け足すものがあり、_dmarc.example.com と書くと _dmarc.example.com.example.com になってしまうことがあります。dig で意図した名前を問い合わせ、見つからなければ二重になった名前でも試してみると原因が分かります。
段階2：表示の読み方を押さえる
dig はTXTの値を二重引用符で囲んで表示します。この引用符は表示上の区切りで、値の一部ではありません。
example.com. 3600 IN TXT "v=spf1 include:_spf.example-mail.net ~all"
example.com. 3600 IN TXT "google-site-verification=your-verification-token"確かめる点は次のとおりです。
- 1行が1レコード：同じ名前に複数のTXTがあるのは普通です。所有権確認とSPFが並んでいても問題ありません。
- 1つのレコードに複数の文字列：TXTの1つの文字列は255バイトまでのため、長いDKIMの公開鍵などは
"v=DKIM1; k=rsa; p=MIIB..." "...続き..."のように分かれて表示されます。SPFやDKIMでは、これらはすき間なしにつなげて解釈されます。管理画面が自動で分割する場合と、自分で分ける必要がある場合があるため、使っているDNSサービスの説明を確かめます。 - 余計な引用符や空白：管理画面に値を貼り付けるとき、引用符まで含めて入力すると、値の中に引用符が入ってしまうことがあります。表示が
"\"v=spf1 ...\""のようになっていれば、引用符が二重です。
用途別に中身を確かめる
SPF
SPFはドメインの頂点（または送信に使うドメイン名）にあり、v=spf1 で始まります。
v=spf1で始まるTXTが同じ名前に1つだけか。2つあると、受信側の評価はエラー（permerror）になります（RFC 7208）。追加するサービスがあるときは、既存のレコードにinclude:を足して1つにまとめます。- DNSの問い合わせを伴う指定（
include、a、mx、ptr、exists、redirect）が、たどった先も含めて10回を超えていないか。ip4:やip6:は数に入りません。 - 末尾が
~all（ソフトフェイル）か-all（フェイル）か、意図どおりか。
DKIM
DKIMの公開鍵は セレクター._domainkey.ドメイン という名前にあります。セレクター名は送信サービスごとに決まっているので、サービスの案内か、送ったメールの DKIM-Signature ヘッダーの s= の値で確かめます。
dig selector1._domainkey.example.com TXT +shortv=DKIM1 と p= に続く公開鍵が返れば登録されています。サービスによってはTXTではなく、サービス側の名前へのCNAMEを置く方式なので、その場合はCNAMEの先でTXTが返るかを見ます。p= の後ろが空なら、その鍵は失効扱いです。
DMARC
DMARCは _dmarc.ドメイン にあり、v=DMARC1 で始まって、p= でポリシーを指定します。
dig _dmarc.example.com TXT +shortv=DMARC1 が先頭にあるか、p=none・quarantine・reject のいずれかがあるか、レポートの送り先（rua=mailto:...）のアドレスが正しいかを確かめます。同じ名前にDMARCのTXTが2つあると、正しく評価されません。
サービスの所有権確認
検索エンジンの管理ツールやメール配信サービスなどは、指定された文字列をTXTに置かせて、ドメインの持ち主かを確かめます。名前（頂点か、指定されたサブドメインか）と、文字列が一字一句同じかを確かめます。確認が済んでも、TXTを消すと所有権の確認が外れるサービスがあるので、確認後も残しておくのが一般的です。
実際のメールで結果を確かめる
DNSの値が正しく見えても、実際の評価は受信側で決まります。自分宛てに送ったメールのヘッダーを開き、Authentication-Results を確かめます。
Authentication-Results: mx.example.net;
spf=pass smtp.mailfrom=example.com;
dkim=pass header.d=example.com;
dmarc=pass header.from=example.comspf=pass、dkim=pass、dmarc=pass がそろっていれば、TXTの設定は受信側でも有効に働いています。WordPressからのメールを確かめるなら、問い合わせフォームやパスワードリセットのメールなど、実際にサイトから送られるメールで見ると、送信経路の違いによる見落としを防げます。メールソフトでヘッダーを表示する方法は、ソフトやWebメールごとに異なり、画面の表記も変わることがあります（2026年10月現在）。
よくある不備と直し方
- SPFが2つある：1つにまとめ、もう1つを削除します。削除前に、両方の内容を控えておきます。
- 名前が二重になっている：名前欄を、ドメイン名を除いた部分（例：
_dmarc）だけに直します。 - 値に引用符が入っている：管理画面で値を入力し直します。
- 権威サーバーは正しいのにキャッシュDNSが古い：TTLの残り時間が過ぎるまで待ちます。
まとめ
- TXTの検証は、「DNSが値を返すか」と「値の中身が用途として正しいか」を分けて確かめます。
- 権威サーバーに直接問い合わせ、名前の二重化や編集先の取り違えがないかを先に見ます。
digの引用符は表示上の区切りです。長い値の分割表示と、余計な引用符の混入を見分けます。- SPFは1つにまとめ、DNS問い合わせの回数に注意します。DKIMはセレクター、DMARCは
_dmarcの名前を確かめます。 - 最後は実際に送ったメールの
Authentication-Resultsで、受信側の評価を確かめます。