SPFレコード確認・SPFチェック

結果の見方：includeのツリー

判定は、レコードに記載のない送信元に対して受信サーバーが得る結果を示します：末尾とともに有効（~allならsoftfail、-allならfail）、原因つきのpermerror、またはDNSが応答しなかった場合の「確認できませんでした」です。

紺色の列はルックアップの予算です：DNSルックアップ1回につき1つのセルで、それを消費したincludeごとに色分けし、10回に対する累計と、voidルックアップを輪で表示します。10回目を過ぎるとセルが赤くなり、受信サーバーが止まる枝に印が付きます。

ツリービューでは、読み取り結果を失敗が先になる順に、RFCのセクションと修正方法とともに並べ、続いてすべてのルックアップを受信サーバーが問い合わせる順に表示します。

voidルックアップとは

voidルックアップとは、レコードが1件も返らなかった問い合わせのことです：名前が存在しない（NXDOMAIN）か、名前はあっても求めたレコードがありません。受信サーバーは2回までを許容すべきで、3回目はpermerrorです（RFC 7208 §4.6.4）。

存在しなくなったホストを指す項目、たとえばa:old.example.comは、それだけではエラーではありません：一致せず、voidが1回数えられるだけです。exists:%{i}._spf.mta.salesforce.comも、Salesforceが記載していないすべての送信元について同じ扱いになり、そのためincludeの順序が重要です。

サーバーの障害やタイムアウトはvoidではありません：temperrorであり、受信サーバーはたいてい後で再試行します。

~all と -all の違い（DMARCとの関係）

最後の項目は、記載のないすべての送信元をどう扱うかを示します。-allはfailで最も強い表明、~allはsoftfailで「おそらく違う」、?allはneutralで受信サーバーはSPFなしと同じに扱い、+allは誰でもpassにするため、決して公開してはいけません。

~allと-allのどちらにも、間違いはありません。Googleは Google Workspace に~all、Microsoftは Microsoft 365 に-allを案内しています。DMARCを強制ポリシーで運用している場合、~allならDMARCがDKIMで判定します：受信サーバーによっては、DMARCがpassするDKIM署名を確認する前に-allを理由に拒否するため、転送されたメールが返送されることがあります（RFC 9989 §7.1）。

Gmail、Yahoo、Microsoftが求めるSPFの要件

2024年2月から、GmailとYahooはすべての送信者にSPFまたはDKIMの設定を求めています。一括送信者には両方に加え、少なくともp=noneのDMARCレコードと、そのどちらかとアラインしたFrom:ドメインが必要です。Outlook.comは大量送信者にSPFとDKIMの両方を求め、2025年5月5日からは、それらがないメールを拒否しています。

Gmailのしきい値は個人アカウントへ1日5,000通を超える場合で、Yahooはしきい値を公表していません。SPFだけでメールが「アラインした」ことにはなりません：MAIL FROMのドメインは、プロバイダーのバウンスドメインではなく、自分のものでなければなりません。