すべてのレコードを解説するTXTレコード確認
ドメインまたは任意のホスト名を入力してください。すべてのTXTレコードについて、種類（SPF、DMARC、DKIM、BIMI、確認用トークン）、TTL、文字列の分割状況、修正すべき点を表示します。無料で登録も不要です。入力したデータは保存しません。
確認するドメイン
例：salesforce.com、_dmarc.salesforce.com
オプション：メール関連レコード、DKIMセレクター
セレクターは、送信したメールのヘッダー「DKIM-Signature: … s=セレクター」で確認できます。複数ある場合はカンマで区切ります。
TXTレコードとは
TXTレコードは、ドメインの情報をテキストとしてDNSで公開するためのレコードです。メールサーバーはSPF、DKIM、DMARCをここから読み取ります。GoogleやMicrosoft 365などのサービスは、TXTのトークンでドメインの所有者を確認します。
DNSはテキストを最大255オクテットの文字列単位で保存します。2048ビットのDKIMキーのような長いレコードは、複数の文字列に分割されます。SPFとDKIMは、分割された文字列をスペースなしで連結します。
- タイプ
- TXT（16）
- 文字列の上限
- 各255オクテット（RFC 1035）
- 同じ名前に複数
- 可。ただしSPFとDMARCは1つのみ
- 変更の反映
- 古いTTLが切れた後
- コマンドライン
dig TXT example.com
確認結果の読み方
確認結果は4つの項目に分かれ、緊急度の高いものから表示されます。
- 1
DNSの応答
レコードの件数と種類、リゾルバー、DNSSEC、確認した時刻。
- 2
最初に直すべき点
SPFレコードの重複、DMARCやDKIMの設置場所の誤り、文字として保存された引用符、1つのUDPパケットに収まらないサイズの応答。
- 3
全レコードの解説
種類、構成要素の表、TTL、サイズ（オクテット）、文字列の分割状況。
- 4
メール関連レコード
_dmarc、主要なDKIMセレクター、BIMI、MTA-STS、TLSレポートをまとめて確認し、それぞれ対応するチェックツールにリンクします。
TXTレコードに入るもの
このツールは、先頭の文字列でレコードの種類を判別します。
| レコード | 先頭の文字列 | 公開する場所 | 読み取る側 |
|---|---|---|---|
| SPF | v=spf1 | ドメイン自体（@） | 受信側メールサーバー |
| DMARC | v=DMARC1 | _dmarc.example.com | 受信側メールサーバー |
| DKIM | v=DKIM1; k=rsa; p=… | selector._domainkey.example.com | 受信側メールサーバー |
| BIMI | v=BIMI1 | default._bimi.example.com | Gmail、Apple Mail、Yahoo |
| MTA-STS | v=STSv1; id=… | _mta-sts.example.com | 送信側メールサーバー |
| TLSレポート | v=TLSRPTv1 | _smtp._tls.example.com | 送信側メールサーバー |
| 所有権確認トークン | google-site-verification=、MS=ms… | 通常はドメイン自体（@） | トークンを発行したサービス |
判別できる所有権確認トークン
以下のトークンは、各サービスが公開している形式で判別します。それ以外のトークンは、トークンに含まれる名前で表示します。
サービス名を表示するトークン
- Google：
google-site-verification=（Search Console、Google Workspace用）。 - Microsoft 365：
MS=msのあとに数字が続く形式。Microsoft 365管理センターで発行されます。 - Apple：
apple-domain-verification=（Apple Business用）。 - Stripe：
stripe-verification=。Stripeは後日もう一度確認するため、削除せずに残してください。 - Zoho、Brevo：
zoho-verification=とbrevo-code:（コロン付き）。 - GlobalSign、Docusign、Adobe：
globalsign-domain-verification=、docusign=、adobe-idp-site-verification=。
PardotとMarketing Cloud Nextの場合
Salesforceのヘルプで指定されているDNSレコードです（2026年10月16日に確認）。
Account Engagement（旧Pardot）
ドメイン管理画面には、送信ドメイン用のTXTレコードが2つ表示されます。検証キーと、
200608._domainkeyに置くDKIMキーです。両方をここで確認すると、反映済みかどうかが分かります。Account EngagementではSPFのincludeは不要です。Marketing Cloud Next
認証済みドメインには8つのCNAMEレコードを設定し、そのうち3つがDKIMキー（
s1-e360-…）用です。これらの名前でTXTを確認すると、CNAMEをたどってキーを表示します。
よくあるTXTレコードの問題
特によく起きる問題と、その直し方です。
- レコードがまだ表示されない。リゾルバーは、TTLが切れるまで古い応答を保持します。TTLの時間が過ぎてから「再確認」を押してください。ホスト名も確認してください。管理画面によってはドメインが自動で付け足され、_dmarc.example.comが_dmarc.example.com.example.comになります。
- SPFレコードが2つある。v=spf1で始まるレコードは、1つの名前に1つだけです。2つあると、すべてのメールでSPFが失敗します。SPFレコード作成ツールで1つにまとめてください。
- 引用符が文字として保存される。DNS管理画面の中には、引用符を自動で付けるものがあります。その場合に値を引用符付きで貼り付けると、レコードが引用符で始まってしまいます。値は引用符なしで貼り付けてください。
- レコードを置く名前が違う。DMARCは_dmarcに、DKIMはselector._domainkeyに置きます。ドメイン自体に置くと、受信側は見つけられません。
- 長いレコードが複数の文字列に分かれる。255オクテットを超える場合は正常です。SPFとDKIMは文字列をスペースなしで連結するため、分割位置にスペースを入れないでください。
- 古いトークンがたまる。トークンが増えるほど、応答は大きくなります。RFC 7208は、1つの名前のTXT応答を450オクテット未満に抑えることを推奨しています。利用をやめたサービスのトークンは削除してください。
TXTレコード確認のよくある質問
TXTレコードについてよく聞かれる質問に、短く答えます。
ドメインのTXTレコードはどう確認しますか？
上の欄にドメインを入力してください。コマンドラインではdig TXT example.comまたはnslookup -type=TXT example.comで確認できます。
TXTレコードが引用符付きの複数の部分に分かれているのはなぜですか？
DNSはテキストを最大255オクテットの文字列で保存するため、長いレコードは分割されます。SPFとDKIMは各部分をスペースなしで連結するので、直す必要はありません。
追加したばかりのTXTレコードが表示されないのはなぜですか？
リゾルバーは、TTLが切れるまで以前の応答を保持します。ホスト名も確認してください。DNS管理画面によってはホスト名にドメインが付け足されるため、ドメインより前の部分だけを入力します。
1つのドメインに複数のTXTレコードを置けますか？
はい、必要なだけ置けます。例外は2つです。SPFレコードは1つの名前に1つだけ、DMARCレコードは_dmarcに1つだけです。
ドメインの所有権確認が済んだら、所有権確認用のレコードは削除できますか？
サービスによります。後日もう一度確認するサービスもあります（Stripeはそう明記しています）。トークンは、そのサービスを使わなくなってから削除してください。
TXTのデータは大文字と小文字を区別しますか？
名前は区別しません。テキストは入力した通りに保存されます。大文字と小文字が意味を持つかは、読み取る側によります。DKIMのタグと値は区別し、SPFのメカニズム名は区別しません。
確認した名前は保存されますか？
いいえ。ブラウザが名前を私たちのサーバーに送り、サーバーが公開DNSリゾルバーに問い合わせます。何も保存せず、名前をログに残すこともありません。リゾルバーにお使いのIPアドレスが伝わることもありません。