Sender Policy Framework（RFC 7208）。当該ドメインの正規送信元として許可されている IP アドレス範囲を DNS の TXT レコードで宣言し、受信側が SMTP セッションの送信元 IP と照合して検証するメール認証の基礎仕様。
SPF レコードの形式
example.com TXT "v=spf1 include:_spf.google.com -all"| 構成 | 意味 |
|---|---|
v=spf1 | バージョン |
include: | 別ドメインの SPF を取り込み（クラウドメールで頻用） |
ip4: / ip6: | 具体的な IP アドレス・範囲 |
a / mx | A / MX レコードを許可 |
-all | 一致しない送信元は ハードフェイル（拒否） |
~all | ソフトフェイル（受信は許可、ヘッダーで警告） |
?all | 中立（評価しない） |
ハードフェイル vs ソフトフェイル
| 値 | 意味 | 推奨タイミング |
|---|---|---|
~all（ソフトフェイル） | 失敗してもメールは届く | 運用開始直後 / メール基盤切替直後。意図しない送信経路が残っていてもメール消失しない |
-all（ハードフェイル） | 失敗したらメール拒否 | 運用が安定し、想定外の送信経路がないことを DMARC レポートで確認後 |
切替直後にいきなり -all にすると、忘れていた CRM・問い合わせ自動返信・古いマーケツール経由のメールが全て消失する事故が起きるため、最初は ~all で開始するのが定石。
10 lookup 制限の罠
SPF は仕様上 1 つの SPF 評価で DNS lookup を 10 回までしか行えない（include: のネストも含む）。クラウドメール SaaS を複数 include: しているとすぐ上限に達して 全 SPF 評価が PermError で FAILする。include:_spf.google.com だけでも 3〜4 lookup 消費するため、SaaS が増えてきたら SPF フラット化サービス（SPF Surge 等）の検討が必要。
DKIM / DMARC との関係
| 仕様 | 検証対象 | 弱点 |
|---|---|---|
| SPF | 送信元 IP | メール転送で IP が変わると FAIL（DKIM で救済できる） |
| DKIM | 署名 | 鍵管理が必要 |
| DMARC | SPF / DKIM の結果統合 | SPF / DKIM が前提 |
SPF 単独では転送メールに弱いため、現代では DKIM・DMARC とのセット運用が必須。
関連用語
- DKIM — 署名ベースの認証
- DMARC — SPF / DKIM の結果を統合するポリシー
- Google Workspace —
include:_spf.google.comで利用 - Microsoft 365 —
include:spf.protection.outlook.comで利用