TXT レコード、SPF、検証
DNS とレコード
DNS ルックアップ あらゆるドメインのすべての DNS レコード A レコードルックアップ ドメインの IPv4 アドレス AAAA レコードルックアップ ドメインの IPv6 アドレス MX ルックアップ ドメインのメールサーバー NS ルックアップ 権威ネームサーバー TXT ルックアップ TXT レコード、SPF、検証 CNAME ルックアップ 正規名（エイリアス）レコード SOA ルックアップ Start of Authority レコード SRV ルックアップ サービスロケーションレコード CAA ルックアップ どの CA が証明書を発行できるか 逆引き DNS（PTR） IP アドレスからホスト名へ DNSSEC チェック ドメインは署名され検証されているか？ DNS ヘルスチェック 委任と DNS の総合診断レポートメール到達性
SPF チェック Sender Policy Framework レコードを検証 DMARC チェック DMARC ポリシーを検査・評価 DKIM チェック DKIM 公開鍵を検索・検証 ブラックリストチェック IP をメールブロックリスト（DNSBL）と照合 SMTP テスト メールサーバーに接続し STARTTLS をチェック MTA-STS チェック 受信メールに対する強制 TLS ポリシー BIMI チェック メール用のブランドロゴレコード TLS-RPT チェック SMTP TLS レポートポリシーネットワークとウェブ
SSL 証明書チェック サイトの TLS 証明書と有効期限を検査 HTTP ヘッダーチェック レスポンスヘッダー、リダイレクト、セキュリティを検査 Ping（TCP） TCP 経由での到達性と遅延 ポートチェック どの一般的なポートが開いているかドメイン
WHOIS ルックアップ ドメイン、IP、ASN の登録データTXTレコードはDNS内に任意のテキストを保持し、メール認証（SPF）、ドメイン所有権の検証、サービス設定に広く使われます。1つのドメインで一度に多数のTXTレコードを公開できます。柔軟で追加が容易なため、TXTレコードは機械可読なポリシーや証明をドメインに付加する標準的な手段となりました。
元々は自由形式のメモ用でしたが、現在のTXTレコードは他のシステムが読み取る構造化データを運びます。SPFポリシーは、どのサーバーがドメインのメールを送信してよいかを列挙します。TXTとして公開されるDKIMやDMARCのレコードは、メールを認証し報告します。Google、Microsoft、Atlassianや無数のSaaSツールからの検証文字列は、ドメインを管理していることを証明します。サイト検証、BIMI、カスタムアプリケーション設定のためのTXTレコードも見られます。それぞれ異なる利用者に対応するため、利用の多いドメインは時間とともに多くを蓄積します。
IPeekは、ドメインのすべてのTXTレコードを、それぞれ引用符付き文字列として返します。接頭辞で識別してください。v=spf1はSPFポリシー、v=DMARC1はDMARCポリシー（通常は_dmarcサブドメイン上）、google-site-verificationなどのトークンは所有権の証明を示します。引用符付きのチャンクに分割された長い文字列は、リゾルバーによって連結された1つの論理レコードです。同じ名前に2つのSPFレコードがある（無効）こと、そしてもう使っていないサービスの古い検証トークン（安全に整理できます）に注意してください。
SPF、DKIM、DMARCはすべてTXTレコードに存在し、連携してなりすましを防ぎます。SPF（v=spf1）は、どのIPやホストがドメインのメールを送信してよいかを宣言し、受信側はそれ以外を拒否またはフラグします。DKIMは公開鍵を公開し、受信側が各メッセージの暗号署名を検証できるようにします。DMARC（v=DMARC1、_dmarc上）は両者を結び付け、失敗をどう扱うか、そしてレポートをどこへ送るかを受信側に伝えます。ドメインはSPFレコードを正確に1つ持つべきですが、その横に他のTXTレコードを多数保持できます。
はい。ドメインは多数のTXTレコードを同時に公開でき、ほとんどのアクティブなドメインがそうしています。検証トークン、DMARCポリシー、アプリケーション設定が同じ名前に共存することがよくあります。1つの重要な例外はSPFで、ドメインはSPF（v=spf1）レコードを1つだけ持つ必要があります。複数のSPFレコードは無効で認証を壊すからです。
SPFレコードは、v=spf1で始まり、ドメインのメール送信を認可されたサーバーを列挙するTXTレコードです。受信サーバーはこれを確認して、受信メールが本当にあなたから来たかを判断します。ドメインのルート名に通常のTXTレコードとして保存され、ドメインは正確に1つだけ持つ必要があります。
多くのサービスは、提供される一意のトークンを含むTXTレコードを追加するよう求め、次にDNSでそれを確認してドメインを管理していることを確かめます。Google、Microsoft、ほとんどのSaaSプラットフォームがこの方法を使います。検証後、トークンは通常そのまま残しても削除しても構いません。使っていないトークンを整理するとDNSがすっきりします。
DNSは単一のTXT文字列を255文字に制限するため、より長い値は1つのレコード内で複数の引用符付きチャンクに分割されます。リゾルバーとIPeekはこれらのチャンクを1つの論理値に連結します。これは長いDKIM鍵や詳細なSPFポリシーでは通常かつ想定どおりであり、分割はレコードの読み取り方に影響しません。
3つともTXTレコードとして公開されるメール認証の仕組みです。SPFはどのサーバーがドメインのメールを送信してよいかを列挙し、DKIMは受信側が公開鍵で検証できる暗号署名を追加し、DMARCは失敗の扱いに関するポリシーを設定してレポートを要求します。組み合わせて使えば、ドメインのなりすましがはるかに困難になります。