SPFレコード確認ツール（無料）

任意のドメインのSPFレコードを検索してテストします。構文を検証し、ネストしたincludeをたどってDNSルックアップ回数を数えます。無料・登録不要。

SPFとは

SPF（Sender Policy Framework）は、エンベロープFrom（MAIL FROM）にそのドメインを使ってよい送信システムをDNSで宣言する、メール認証の仕組みです。公開レコードからわかるのは、受信側が参照できるポリシーまでです。個々のメールがSPF認証に成功したことや、認証ドメインがDMARCのアライメントを満たしたことまでは証明できません。

SPFチェック結果の見方

結果	意味	対処法
SPFが有効	入力したドメインに、解釈できるSPFポリシーが1件見つかりました。	各メカニズムが稼働中の送信元のものか確認し、実際のメールは別途検証してください。
SPF未設定	入力したドメイン自体にv=spf1ポリシーが見つかりません。	MAIL FROMのドメインを確認し、実際にメールを送るシステムが案内するレコードを公開してください。
SPFレコード重複	同じドメイン名にv=spf1のポリシーが複数あり、PermError（恒久的エラー）になります。	許可している送信元をすべて洗い出し、メカニズムを1つのポリシーにまとめてください。
DNS参照9〜10回	RFC 7208の上限か、その目前です。送信サービス側の変更に耐える余裕がほぼありません。	PermErrorになる前に、不要な送信元を削除し、ネストしたincludeを確認してください。
PermError／10回超	構文の誤り、レコードの重複、参照先の不具合、DNS処理の過多により、ポリシーを確実に評価できません。	表示された原因を直して再テストしてください。再送を繰り返しても、恒久的なポリシーエラーは解消しません。
~all／-all	~all（softfail）と-all（fail）は意味が異なりますが、最終的な扱いは受信側のシステムが決めます。	限定子を厳しくする前に正規の送信元をすべて洗い出し、その上で本番メールとDMARCアライメントを検証してください。

SPFを正しく確認する手順

1. SPFの評価対象ドメインを特定する。 配信されたメールのヘッダー全文を開き、SPF結果の横で受信側が付加した smtp.mailfrom の値を探します。プロバイダー管理のReturn-Pathや独自のサブドメインは、ヘッダーFromのドメインと異なる場合があります。
2. そのドメインを入力する。 @より前の部分、プロトコル、パスは付けず、ドメイン名だけを入力します。まだ送信したメールがない場合は、送信サービスの最新の設定手順にあるドメインを使います。結果は本番メールのテストではなく、設定の確認として扱ってください。
3. メカニズムと修飾子を記述順に読む。 対象は ip4, ip6, a, mx, include, exists, all、あれば redirectも含みます。includeは送信元名ではなく、別のポリシーを評価します。
4. 再帰的なDNS処理を確認する。 RFC 7208では、DNSルックアップを伴う項目は評価全体で最大10個までです。ネスト先の項目も同じ上限を消費するため、表に見えるincludeだけを数えても足りません。

このツールで確認できること

このツールでわかるのは、入力したドメイン名への公開DNSの応答、SPFポリシーを1つ解析できるか、メカニズム（ネスト先を含む）がDNSルックアップ上限をどう消費するかです。解釈は RFC 7208に準拠します。非公開の送信元一覧は確認できず、受信側が評価した識別子も指定がない限りわかりません。受信トレイへの到達も保証しません。

Google Workspaceの場合は、信頼できるヘッダーに記録された独自ドメインのMAIL FROMを使います。Googleの SPFトラブルシューティングでも同様に、公開DNSのチェックと実際のメールの結果を区別しています。

修正したら、実際のメールで再テスト

まず、社内メール、マーケティングツール、トランザクションメール、チケット管理、請求システム、各種機器を棚卸しします。メカニズムの追加やincludeのフラット化より先に、使わなくなった送信元を削除してください。上限を超えている場合は、 SPF PermErrorの修正手順に従い、参照先ごとに担当者を決めてください。

権威DNSサーバーが変更後のレコードを返すようになったら、このチェックを再実行します。次に、変更した本番の送信経路ごとに新しいメールを送り、信頼できるAuthentication-Resultsヘッダーで評価された識別子、接続元IP、SPF結果、ヘッダーFromのドメインを確認します。 DMARC は別途確認してください。アライメントしないReturn-PathでSPFが成功しても、DMARCの成功にはなりません。

SPFチェックで特定メールを検証できますか？

いいえ。ドメイン単位のSPFチェックは、公開DNS上のポリシーを読むだけです。特定のメールを検証するには、受信側が付加した信頼できるAuthentication-Resultsヘッダーで、評価されたsmtp.mailfrom、接続元IP、SPF結果を確認してください。

ルートとサブドメインのどちらを確認しますか？

送信経路で実際に使われるMAIL FROMまたはHELOのドメインを確認してください。Return-Path用の独自サブドメインは組織ドメインと別のSPFポリシーを持てるため、ルートドメインが正しい確認先とは限りません。

SPFレコードが有効ならDMARCも成功しますか？

いいえ。DMARCには、SPFで認証されたドメインとヘッダーFromのドメインの一致、または一致したDKIM署名の検証成功が必要です。公開SPFレコードが有効なだけでは、個々のメールのSPF結果やDMARCアライメントは証明できません。

ルックアップ過多の対策は、常にSPFフラット化が正解ですか？

いいえ。まず使わなくなった送信元を削除し、管理の担当を整理してください。フラット化はプロバイダーのIP範囲をレコードに書き写すため、範囲が変わると古くなるおそれがあります。確実な監視と、更新の担当者が欠かせません。

10回のルックアップ上限に数えられるSPFの項目は？

DNSルックアップを消費するのは、include、a、mx、ptr、existsの各メカニズムとredirect修飾子です。ネスト先の対象項目も同じ上限を使います。ip4、ip6、allの各メカニズムとexp修飾子は、10回の上限に数えません。