任意のドメインをこのSPFチェッカーにかけると、ライブのレコードを取得し、すべてのメカニズムを展開し、あなたのドメインが現在メール送信を信頼しているIPアドレスの完全なリストを表示します。そのリスト外のものはすべて、受信サーバーが問い合わせたり拒否したりする対象です。この概念に初めて触れる方は、まずSPFルックアップとは何か、そしてそれがなぜ重要かから始めましょう。
SPFレコードの見た目
SPFレコードは、あなたのDNSレコードに公開される単一のTXTエントリで、どのメールサーバーがあなたのドメインを代表してメッセージを送信できるかを受信者に伝えます。典型的なレコードは次のようになります。
v=spf1 include:_spf.google.com ip4:192.0.2.0/24 -all
各要素はメカニズムです。include:メカニズムは別のドメインの許可された送信者を取り込み、ip4:は特定のIPアドレスまたはIP範囲を許可し、最後の-allはそれ以外のすべての送信者を拒否します。このSPFチェッカーを実行すると、各メカニズムを展開し、構文をSender Policy Framework（SPF）仕様（RFC 7208）に照らして検証し、あなたのドメインが現在許可するすべてのIPアドレスを一覧表示します。
よくあるSPFエラーとその意味
チェッカーがあなたのレコードを分析すると、結果はいくつかのSPFの結果のいずれかに落ち着きます。認識しておくべきエラーは次のとおりです。
- PermError（ツール出力では
PermErrorと表示）- レコード自体の恒久的な失敗。ほぼ常に構文の誤りか、DNSルックアップ上限を超えるレコードです。受信者はそのレコードを存在しないものとして扱います。構文を修正するか、ネストしたincludeを減らして解消します。 - TempError（
TempError）- 一時的なDNS解決の問題で、多くの場合、遅いまたは到達不能なネームサーバーが原因です。数分後に再テストしてください。続く場合はDNSプロバイダーを確認します。 - softfail（
~all修飾子）- 送信者は許可されていませんが、受信者はメッセージを受け入れて疑わしいものとしてマークすべきです。ハードフェイルに切り替える前の移行期の設定でよく見られます。 - hardfail（
-all修飾子）- 送信者は許可されていないため、受信者はメッセージを完全に拒否します。すべての正規の送信者を把握できたら設定したい設定です。 - none - ドメインがSPFレコードをまったく公開していないため、受信者は送信者を照合する対象がなく、多くの場合そのメールを信頼できないものとして扱います。
- neutral（
?all修飾子）- ドメインが許可について明示的に何も主張しないケースです。noneと同様に扱われます。
各結果は異なる修正に対応します。構文エラー、欠落したTXTレコード、許可されていない送信者は、チェッカー上で別々のエラーカテゴリとして表面化するので、生のDNS応答を掘り下げることなく対処できます。
SPFがDKIMおよびDMARCとどう連携するか
SPFは、協調して機能する3つのメール認証標準の1つなので、SPFチェックが単独で全体像を語ることはめったにありません。SPFは送信サーバーを検証し、DKIMはメッセージが転送中に改ざんされていないことを証明する暗号署名を追加し、DMARCはその2つを結び付けます。DMARCは、SPFまたはDKIMが可視の「From」アドレスのドメインとアライメントしているかをチェックし、認証が失敗したときに受信者がどうすべきかを伝えます。Gmail、Yahoo、Microsoftは現在、大量送信者にこの3つすべてを要求しているので、合格するSPFレコードは、残りのメール認証、そしてなりすましやメール詐欺に対する防御を築く土台です。
このSPFチェッカーが表面化させた問題を解消したら、同時にDKIMとDMARCも再チェックしてください。技術的に有効なSPFレコードでも、DMARCポリシーとアライメントしていなければ失敗することがあり、他の送信者を網羅する前にSPFを-allに強化すると正規のメールをブロックしてしまいます。
10 DNSルックアップ上限
include、a、mx、ptr、existsメカニズムが10 DNSルックアップ上限に加算されます。それを超えるとレコードはPermErrorで失敗します。Sender Policy Framework仕様は、1回の評価あたりのDNSルックアップを10に制限しています（RFC 7208、セクション4.6.4）。各include:、a、mx、ptr、existsメカニズムが上限に加算され、ネストしたincludeは再帰的に加算されます。レコードが10 DNSルックアップ上限を超えると、受信者はPermErrorを返し、レコードの他の部分がどれほど正しくても、あなたのメッセージは迷惑メールに振り分けられる可能性があります。ルックアップ上限が10を超えた瞬間、列挙したすべてのIPアドレスは無意味になります。
チェッカーは、サードパーティのinclude:ディレクティブの内部に隠れたものも含め、レコードが引き起こすすべてのルックアップを数えます。10を超えている、あるいは近い場合、AutoSPFがあなたのSPFレコードを自動的にフラット化し、許可されたIPアドレスを保持しながら、ネストしたルックアップを単一の有効なSPFレコードに集約します。
SPFチェックを実行すべきタイミング
メールプロバイダーを追加または削除したとき、プラットフォームを移行したとき、あるいはメッセージが迷惑メールに振り分けられているのに気づいたときは、SPFチェックを実行してください。こうしたSPFレコードのチェックは日常的な衛生管理なので、少なくとも四半期に一度はレコードを監査しましょう。あなたのドメインのメール送信者を変更するたびに、SPFルックアップは、レコードが依然として解決し、10ルックアップ上限内に収まり、信頼するサーバーだけを列挙していることを確認します。このようなツールは、手作業のdigセッションを10秒のチェックに変え、DMARCチェッカーやDKIMルックアップと組み合わせることで、メール認証の全体像を把握できます。サブドメインも別途チェックしてください。サブドメインは親ドメインのSPFレコードを継承しないため、メールを送信するすべてのサブドメインには独自のレコードが必要です。