本文へスキップ

TXTレコード検索

ドメインやホスト名のTXTレコードをすべて表示。SPF、DMARC、DKIM、BIMI、確認用トークンを判別してチェックします。無料・登録不要。

TXTレコード確認とは

このTXTレコード検索は、1つのホスト名について公開DNSを照会し、そこに公開されたTXT文字列をすべて返して、読み取るプロトコルやサービスごとにラベルを付けます。メール認証はこれらの文字列で動いています。SPFは送信ドメインのTXTレコード、DKIM鍵はセレクタの下のTXTレコード、DMARCは_dmarcのTXTレコードで、BIMI、MTA-STS、TLS-RPTにはそれぞれ専用のホスト名があります。Google、Microsoft、Appleをはじめ多数のサービスが公開を求める確認用文字列も同じです。通常の検索は文字列を表示するだけですが、このツールは各文字列をどのプロトコルが読むか、そのプロトコルが実際に照会するホストにあるか、2つが競合していないかも示します。

結果の見方

結果意味対処法
SPFv=spf1で始まる文字列。このドメインとしてメールを送れるホストの一覧と、それ以外を受信側がどう扱うか。~allか-allで終わり、利用する全送信サービスが含まれるか確かめます。SPFチェックはDNSルックアップの数を上限10回と照合します。
DMARCv=DMARC1の文字列。_dmarc.yourdomain.co.jpでのみ意味があり、他の場所では無視されます。p=タグを読みます。noneは報告のみで、quarantineとrejectが実際にドメインを守ります。
DKIM公開鍵selector._domainkey.yourdomain.co.jpにあるv=DKIM1かp=の文字列。p=が空なら鍵は失効しています。DKIMチェックで鍵を検証します。セレクタが不明なら、主なセレクタも試します。
BIMI、MTA-STS、TLS-RPTそれぞれdefault._bimi、_mta-sts、_smtp._tlsにあるポリシーのレコード。どれも専用のチェックがあり、ロゴファイル、HTTPSのポリシー、レポートの送付先など、DNSの文字列だけでは検証できない部分を確かめます。
確認用トークン外部サービスの所有確認用の文字列。接頭辞が既知なら、ツールがサービス名を示します。対応は不要です。使っていないサービスのトークンがあれば別ですが、削除しても確認済みのものは壊れません。
SPFかDMARCが2つある1つの名前にv=spf1が複数、または_dmarcにv=DMARC1が複数ある状態です。受信側は選択ではなくエラーとして扱います。1つのレコードにまとめます。それまでSPFはpermerrorを返し、DMARCはないものとして扱われます。
TXTなし名前は解決できるがテキストレコードがない、またはまったく解決できません。綴りを確認します。メールを送るルートドメインならSPFを公開し、送らないサブドメインならこれが普通です。

各メールレコードの実際の置き場所

TXT検索で最も多い誤読は、ルートドメインで実行してDMARCがないと結論することです。受信側はそこを探さないので、そこにはありません。各プロトコルは特定のホスト名を照会し、検索では指定した名前しか表示されません。

  • SPF：yourdomain.com。エンベロープ送信者のドメイン。
  • DMARC：_dmarc.yourdomain.com
  • DKIM：selector._domainkey.yourdomain.com。署名鍵ごとに1つ。
  • BIMI：default._bimi.yourdomain.com
  • MTA-STS：_mta-sts.yourdomain.com、TLS-RPT：_smtp._tls.yourdomain.com。

どの結果にも同じドメインの他のホストをクリック1つで照会するリンクがあるため、ホスト名を5回入力しなくても、5回のクリックで全体がわかります。

この検索で証明できること

この検索で証明できるのは、入力した名前について公開DNSが返す内容と、文字列自体に見える構造上の誤りです。2つ目のSPFレコード、誤ったホストに公開されたDMARCレコード、p=タグが空のDKIM鍵、+allで終わるSPFなどです。実際のメールに対するレコードの評価はしません。SPFレコードの形式が完璧でも、請求書を送るサービスが漏れていることがあり、DNSにDKIM鍵があってもサーバーがその鍵で署名している証明にはなりません。公開を確認できたら、SPFチェック、DKIMチェック、DMARCチェックでそれぞれのレコードをタグごとに検証できます。

レコードを読むことから、正しく保つことへ

検索は1つのホスト名のその時点の記録です。メールが信頼されるかを決めるレコードは変わっていきます。部署が新しい送信ツールを導入してSPFが対応しなくなり、送信サービスがDKIMセレクタをローテーションし、誰もレポートを読まないままDMARCポリシーが1年間p=noneのまま、ということが起きます。PalisadeはDMARCの集計レポートを優先順位付きのワークフローに変えます。担当者はドメインとして送信する全送信元を特定し、それぞれに必要なレコードを把握して、推測ではなく根拠をもってドメインのポリシーを強化できます。

MSP向けにはマルチテナントで設計。全顧客ドメインのSPF、DKIM、DMARCレコードのチェック、修正、ポリシー強化を1つの管理画面で行えます。顧客ドメイン単位の料金は管理数が増えるほど単価が下がります。

関連するチェックと用語

DNS検索（全レコード）SPFチェックDKIMチェックDMARCチェックBIMIチェックMTA-STSチェックTXTレコードとはDigとnslookupでのTXT検索
DMARCとは？メール認証をわかりやすく解説

実務まで担うDMARCソフトウェア

PalisadeはDMARCレポートの証拠を、優先順位付きの送信元とレコードの作業に整理します。検索で表示されるSPF、DKIM、DMARCの文字列が、すべてあるべきものになります。

今すぐ開始デモを予約

ドメイン診断は無料・カード不要。カード登録で15日間のトライアル開始。

メール認証ナレッジベース

TXTレコード確認とは

このTXTレコード検索は、1つのホスト名について公開DNSを照会し、そこに公開されたTXT文字列をすべて返して、読み取るプロトコルやサービスごとにラベルを付けます。TXTレコードには、SPFポリシー、DKIM公開鍵、DMARCポリシー、BIMIの参照先、Google WorkspaceやMicrosoft 365などのサービスがドメインの管理権の証明に使う確認用トークンが入ります。このツールはその照会を実行し、各文字列をどのシステムが読むかでラベル付けします。

ドメインを検索してもDMARCレコードが出ないのはなぜ？

DMARCはドメイン自体には公開されないからです。受信側はホスト名_dmarc.yourdomain.co.jpから読み取るため、yourdomain.co.jpの検索では返りません。ここで_dmarc.yourdomain.co.jpを入力するか、結果の下の関連ホストのリンクを使ってください。DKIMも同様にselector._domainkey.yourdomain.co.jpに、BIMIはdefault._bimi.yourdomain.co.jpにあります。

digやnslookupでTXTレコードを確認するには？

macOSやLinuxではdig TXT example.comを実行し、値だけを表示するには+shortを付けます。Windowsではnslookup -type=TXT example.com、PowerShellならResolve-DnsName -Name example.com -Type TXTを実行します。example.comは、_dmarc.example.comのように必要な正確なホスト名に置き換えてください。出力はこのツールが表示するのと同じ生の文字列で、分類はありません。リゾルバーの指定やPowerShellの書き方を含むコマンドの詳細は、下のdigとnslookupのガイドにあります。

TXTレコードはいくつ置ける？

DNS自体には1つの名前に置けるTXTレコードの数に上限はありませんが、それを使うプロトコルにはあります。SPFはv=spf1で始まるレコードを1つだけ（RFC 7208）、DMARCは_dmarcにv=DMARC1のレコードを1つだけ（RFC 7489を置き換えたRFC 9989）認めます。SPFレコードが2つあるとpermerrorになり、DMARCはそれをSPF失敗と数えます。DMARCレコードが2つあると受信側は照会を破棄し、ドメインをポリシーなしとして扱います。確認用トークンにはそうした上限がなく、利用の多いドメインでは10個以上あることもよくあります。

TXTが複数の引用符付き文字列に分かれる理由は？

TXTの1文字列は、RFC 1035で255オクテットが上限です。それより長いものは1つのレコード内の複数の文字列として公開する必要があり、リゾルバーや受信側がつなぎ直します。長いSPFレコードや2048ビットのDKIM鍵ではよく必要になります。多くのDNSプロバイダーは長い値を自動で分割します。このツールは各レコードがいくつの文字列で公開されたかを表示するため、正しく分割されたレコードと途中で切れたレコードを区別できます。

この検索はどのDNSリゾルバーを使いますか？

照会はGoogleの公開リゾルバー8.8.8.8を通し、予備にCloudflareの1.1.1.1を使います。そのため、社内のリゾルバーがキャッシュした内容ではなく、独立した第三者が見る内容に近いものがわかります。また、直前に行った変更は、それらのリゾルバーでレコードのTTLが切れるまで表示されないことがあります。

TXTレコードにある多数の確認用トークンは何？

google-site-verification=...、MS=ms...、apple-domain-verification=...のような文字列は、所有確認用のトークンです。サービスが公開を求め、それを読み取ってドメインの管理権を確認します。残しても害はなく、このツールは一般的なものについてサービス名を示します。過去にこのドメインにつないだサービスの、目立たない一覧にもなります。

TXT検索で、メールが認証されているかわかりますか？

わかるのは何が公開されているかで、必要ではあっても十分ではありません。完璧なSPFレコードでも、記載されていないサーバーから送ったメールには役立たず、DNSにDKIM鍵があってもメールサーバーがその鍵で署名している証明にはなりません。ここでの指摘はレコード自体の構造上の問題です。実際のメールがパスするかはDMARCの集計レポートで決まり、Palisadeはそれを読み取ります。

TXTレコードが出ないのはなぜ？

ホスト名の綴りが誤っている、ドメインが未登録、ネームサーバーが応答しない、または本当に何も公開していないかのいずれかです。TXTレコードのないルートドメインにはSPFがなく、メールを送るなら問題です。サブドメインになければ普通ですが、そのサブドメイン名義でメールを送るなら別です。まず綴りを確認してください。_dmarcのアンダースコア抜けが最も多い原因です。