SPFレコードの検証とは、受信メールサーバーが実際に強制するルール、すなわちSender Policy Framework仕様（RFC 7208）に照らしてチェックすることです。レコードは正しく見えても拒否されることがあります。ここでは、「有効」が何を意味するのか、そしてこのバリデーターが見つける不具合をどう修正するかを解説します。
RFC 7208における「有効」の意味
有効なSPFレコードは、次のすべての条件を同時に満たします。ドメイン上で唯一のv=spf1 TXTレコードであること、v=spf1タグで始まること、認識されるメカニズムと修飾子のみを使うこと、10以下のDNSルックアップで解決すること、2つ以下のvoidルックアップしか生じないこと、そしてall修飾子で終わること。いずれか1つでも欠けると、受信者はPermErrorを返し、そのレコードを一度も公開されていないかのように扱うことがあります。
バリデーターが強制する構文ルール
- レコードは1つだけ。 RFC 7208はドメインごとに正確に1つの
v=spf1レコードを許可します。2つ目は自動的にPermErrorとなり、両方が無視されます。 - 正しい順序。
v=spf1バージョンタグが最初に、allメカニズムが最後に来なければなりません。 - 有効なメカニズムと修飾子のみ。 許可されるメカニズムは
include、a、mx、ip4、ip6、exists、allで、それぞれに+、-、~、?の修飾子を付けられます。ip:やincludes:のような誤字は失敗します。 - 文字列の長さ。 TXTレコード内の任意の単一の文字列は255文字以内、レコード全体は512バイト以内に収まる必要があります。さもないとDNSが切り詰めます。
10ルックアップと2 voidルックアップの上限
2つの数値上限が、「構文は有効なのに失敗する」レコードのほとんどを捕捉します。1つ目は、よく知られた1回の評価あたり10のDNS問い合わせメカニズムの上限です。すべてのinclude、a、mx、ptr、existsが数えられ、ネストしたincludeは再帰的に数えられます。2つ目の、あまり知られていない上限はvoidルックアップです。空のDNS応答に解決されるメカニズムは2つまでです。いずれかを超えると結果はPermErrorです。レコードが10ルックアップ上限を超えている場合、AutoSPFがincludeをクリーンに検証されるコンパクトなレコードにフラット化し、15分ごとに再スキャンします。詳しくはDNSルックアップが多すぎるをご覧ください。
非推奨および危険なメカニズム
バリデーターは、技術的には解析可能だが避けるべき2つのものについて警告します。ptrメカニズムは、遅く信頼性が低いためRFC 7208（§5.5）で非推奨とされています。ip4/ip6またはincludeに置き換えてください。そして+allは、インターネット全体にあなたのドメインとしての送信を許可し、SPFの目的を完全に台無しにします。有効なレコードは-allまたは~allで終わるべきです。
無効なSPFレコードを修正する方法
ほとんどの検証失敗は、次の4つの修正のいずれかに対応します。SPF検証のトラブルシューティング方法に関する当社のガイドが、それぞれを詳しく解説しています。
- SPFレコードが2つある？ すべての送信者を単一の
v=spf1レコードに統合します。 - 10ルックアップを超えている？ ルックアップの多いincludeを
ip4/ip6エントリに置き換えるか、AutoSPFで自動的にレコードをフラット化します。 - 非推奨の
ptr？ 削除し、代わりにそれらのホストをIPまたはincludeで許可します。 - 修飾子が欠落または間違っている？ レコードが
v=spf1で始まり-all（テスト中は~all）で終わることを確認します。
パッチを当てるより、一から再構築する方が簡単なことがよくあります。無料のSPFレコードジェネレーターは、ここで一度に検証できる、構文的にクリーンなレコードを生成します。
SPFがDKIMおよびDMARCとどこで並ぶか
有効なSPFレコードは必要ですが、それだけでは十分ではありません。DKIMはメッセージ本文に署名し、DMARCはSPFとDKIMを可視のFromドメインに結び付け、強制ポリシーを設定します。SPFレコードをチェックして検証が通ったら、無料のDMARCチェッカーとDKIMルックアップで他の2つを確認しましょう。送信サービスを追加または削除するたびにSPFを再検証し、少なくとも四半期に一度は監査してください。そして、メールを送信する各サブドメインには独自の有効なレコードが必要であることを覚えておいてください。