SPFチェッカー

SPF（Sender Policy Framework、RFC 7208）は、ドメインのメールを送信できるサーバーを列挙するメール認証方式です。リストは v=spf1 で始まる1つのTXTレコードとして公開されます。メッセージが届くと、受信サーバーは送信元IPアドレスをこのリストと照合します。

SPFレコードがない、または壊れていると、正規のメールが迷惑メールに入りやすくなり、アライメント付きのSPFまたはDKIM合格に依存するDMARCも弱まります。

• ドメインのTXTレコードをすべて取得し、v=spf1 で始まるものを見つけます。
• すべてのメカニズムと修飾子を解析・検証します（ip4/ip6 の範囲、include、a、mx、exists、redirect、末尾の all）。
• include と redirect を再帰的にたどってツリーを構築し、DNSクエリを伴う項目をすべて数えます。
• DNSルックアップの合計（上限10）、空のルックアップ、ループ、構文上の問題を推奨事項とともに表示します。

自社サーバーと Google Workspace から送信するドメインなら、次のように公開できます。

v=spf1 ip4:203.0.113.10 include:_spf.google.com -all

1つのIPv4アドレスと Google のメールサーバーを許可し、それ以外の送信元を拒否するよう受信側に求めます。include ごとに少なくとも1回のDNSルックアップが発生するため、サービスの数は最小限にしましょう。

受信側を悪用から守るため、SPFの評価で発生するDNSルックアップは最大10回までです。include、a、mx、ptr、exists の各メカニズムと redirect 修飾子は、入れ子のinclude内も含めてそれぞれ1回と数えます。ip4、ip6、all は数えません。合計が10を超えると恒久的エラー（permerror）となり、すべてのメッセージでSPFが失敗します。

上限超過は、新しいメールサービスを次々に追加する成長企業で最もよくあるSPFの問題です。上限内に収めるには、使っていないサービスを削除し、a と mx を明示的な ip4/ip6 範囲に置き換え、ベンダーにより狭いincludeを依頼しましょう。

• -all（fail） — 許可されていない送信元は失敗します。リストが完全なら最も厳格で推奨される終わり方です。
• ~all（softfail） — 許可されていないメールも受け入れますが、疑わしいとマークします。移行中によく使われ、DMARCとの併用でも一般的です。
• ?all（neutral） — 何も示しません。保護になりません。
• +all（pass） — すべてを許可します。誰でもあなたのドメインでメールを送れるため、絶対に使わないでください。

• 複数のSPFレコード — ドメインの v=spf1 レコードは1つだけにし、1つに統合してください。
• DNSルックアップが多すぎる — 10回を超えると permerror になります。includeを整理または削除してください。
• SPFのないドメインのinclude — 空のルックアップとして数えられ、2回を超えると恒久的エラーになります。
• ptr の使用 — 非推奨で遅く、多くの受信側で無視されます。
• all の後の項目 — all メカニズムの後にあるものは評価されません。