SPF — 送信者ポリシーフレームワーク
このRFCが存在する理由
SMTPは1980年代初頭に設計されたもので、送信者検証機能がありませんでした。どのサーバーも任意のドメインからメールを送信していると主張できます。基本プロトコルにはそれを防ぐ仕組みがないのです。これにより、メールスプーフィングは簡単になりました。スパマーやフィッシング詐欺師は、銀行、同僚、または信頼できるブランドになりすますため、エンベロープ送信者アドレスを偽造できました。
RFC 7208で標準化されたSPF（Sender Policy Framework）は、ドメイン所有者がDNS TXTレコードを公開して、そのドメインからメールを送信することを明示的に許可されているIPアドレスとサーバーをリストアップできるようにすることで、この問題を解決しています。受信メールサーバーはSMTPトランザクション中にこのレコードをクエリし、権限のないソースからのメッセージを拒否またはフラグ付けできます。
RFC 7208は初期の実験的なRFC 4408に取って代わり、SPFを完全なインターネット標準に昇格させ、処理ルールを明確にしてDNSルックアップ制限をより厳しくしました。
動作方法
SPFはメッセージヘッダーレベルではなく、エンベロープレベルで動作します。チェックされるドメインは、MAIL FROMコマンド（Return-Pathまたはエンベロープ送信者とも呼ばれます）内のドメインであり、ユーザーが見るFrom:ヘッダーではありません。
SPFチェックフロー
- 送信サーバーが受信者に接続し、
MAIL FROM:<user@example.com>を発行します。 - 受信者はエンベロープ送信者から
example.comドメインを抽出します。 - 受信者は
v=spf1で始まるexample.comのDNS TXTレコードをクエリします。 - 受信者はSPFレコードのメカニズムを接続元IPアドレスと照合して評価します。
- 結果は次のいずれかです：
pass、fail、softfail、neutral、none、temperror、またはpermerror。
SMTPトランザクション例
S: 220 mx.receiver.com ESMTP ready
C: EHLO mail.example.com
S: 250-mx.receiver.com Hello
S: 250 OK
C: MAIL FROM:<alice@example.com>
# 受信者が確認します：example.comのSPFレコードは198.51.100.25を許可していますか？
# DNSルックアップ：example.com TXT "v=spf1 ip4:198.51.100.0/24 -all"
# 198.51.100.25はip4:198.51.100.0/24に一致 => 結果：pass
S: 250 OK
C: RCPT TO:<bob@receiver.com>
S: 250 OK
重要な技術的詳細
SPFレコード構文
SPFレコードはバージョンタグv=spf1で始まるDNS TXTレコードで、その後に一連のメカニズムと各々のオプション修飾子が続きます。レコードは左から右に評価され、最初に一致するメカニズムが結果を決定します。
メカニズム
| メカニズム | 説明 |
|---|---|
ip4:<range> |
送信者のIPが指定されたIPv4 CIDRレンジ内にある場合に一致します。 |
ip6:<range> |
送信者のIPが指定されたIPv6 CIDRレンジ内にある場合に一致します。 |
a |
送信者のIPがドメインのA/AAAAレコードと等しい場合に一致します。 |
mx |
送信者のIPがドメインのMXホストの1つのA/AAAAレコードと等しい場合に一致します。 |
include:<domain> |
別のドメインのSPFレコードを再帰的に評価します。インクルードされたドメインからのpassは一致と見なされます。 |
exists:<domain> |
指定されたドメインのDNS Aレコードが存在する場合に一致します（高度なマクロに使用）。 |
redirect=<domain> |
修飾子：現在のSPFチェック全体を別のドメインのレコードで置き換えます。 |
all |
すべてに一致します。通常、レコードの末尾で-allまたは~allとして使用されます。 |
修飾子
| 修飾子 | 結果 | 意味 |
|---|---|---|
+（デフォルト） |
pass | 許可された送信者 |
- |
fail | 許可されていない — メッセージを拒否 |
~ |
softfail | おそらく許可されていない — 受け入れるがマーク |
? |
neutral | アサーションなし |
10ルックアップ制限
DNS乱用を防ぐため、RFC 7208はSPF評価が、メカニズム解決につながる10を超えるDNSルックアップを必要としないことを定めています。ルックアップをトリガーするメカニズムは：include、a、mx、exists、redirect、およびptr（非推奨）です。生のip4およびip6メカニズムはカウントされません。10ルックアップを超えるとpermerror結果が生じ、通常はSPF保護が全くないことを意味します。
MXルックアップ制限
さらに、mxメカニズムは10を超えるMX名をクエリするべきではなく、それぞれは10を超えるA/AAAAアドレスに解決されるべきではありません。ptrメカニズムは明示的に非推奨です。
マクロ展開
SPFは評価中にコンテキスト固有の値に展開されるマクロをサポートしています。一般的なマクロには%{s}（送信者）、%{l}（ローカルパート）、%{d}（ドメイン）、および%{i}（IPアドレス）が含まれます。これらは主に複雑なユーザーごと、またはIP単位のポリシーのためのexists:メカニズムで使用されます。
DNSレコード例
基本：単一IPレンジ
一般的：サードパーティESP + Google Workspace
メールを送信しないドメイン
redirectを使用
一般的な間違い
-
複数のSPFレコード： ドメインには正確に1つのSPF TXTレコードが必要です。2つを公開すると
permerrorが発生します。複数のソースを組み合わせる必要がある場合は、それらを1つのレコードにマージしてください。 -
10ルックアップ制限を超える： 各
include:は1つのルックアップとカウントされ、インクルードされたレコード独自のメカニズムは合計にカウントされます。複数のESPからのインクルードチェーンはすぐに制限を消費します。レコードをフラット化するか、サブドメインを使用してください。 -
-allの代わりに~allを使用： softfail（~all）は受信者にメッセージが疑わしいことを伝えますが、拒否しないよう指示します。強力な保護（およびDMARC実施を有効にする）については、-allを使用してください。 -
Return-Pathドメインを忘れる： SPFは
From:ヘッダーではなく、エンベロープ送信者をチェックします。ESPが独自のReturn-Pathドメインを使用する場合、ドメインのSPFレコードはSPFチェックに関係ありません。カスタムReturn-Pathアラインメント、またはDKIM + DMARCのいずれかが必要です。 -
非推奨の
ptrメカニズムを使用： RFC 7208はptrを明示的に非推奨としています。これは遅く、信頼性が低く、逆DNSインフラストラクチャに負荷をかけるためです。 - SPF型（99）レコードを使用： 専用SPF DNSレコード型はRFC 4408で定義されましたが、RFC 7208で非推奨になりました。常にTXTレコードを使用してください。
配信性への影響
SPFはメール認証の3つの柱の1つです（DKIMとDMARCと並んで）。配信性への影響は重大です：
- 主要プロバイダーで必須： Gmail、Yahoo、Microsoft、AppleはすべてSPFを評価しています。2024年2月以降、GmailとYahooは全送信者のSPFまたはDKIM、および一括送信者の両方の合格を必須としています。
-
DMARCアラインメント： SPFはDMARCと組み合わせるとはるかに強力になります。DMARCは、SPF認証されたドメインが
From:ヘッダードメインと一致していることをチェックします。DMARCなしでは、SPFだけではヘッダーFromスプーフィングを防ぐことはできません。 - 転送によってSPFが破損： メールがメーリングリストや.forwardルールを通じて転送されると、送信IPが変更されますが、エンベロープ送信者はしばしば同じままです。これにより正当なメールのSPFが失敗します。これがDKIMとARCが存在する理由の1つです。
-
レピュテーション信号： 適切に設定されたSPFレコード（
-all付き）は、受信者にメールセキュリティを真摯に受け止めていることを信号し、悪い行為者がドメインを乱用することをより難しくします。