Sender Policy Framework
あるドメインが検証に不合格となるSPFレコードを宣言した場合、そのドメインから送信され、配送先メールサーバから第三者へ転送された正当な電子メールは、以下の条件で配送が拒否され、エラーレスポンスが返されることがあり得る。 (1)メーリングリストと異なり、転送元メールサーバがReturn-Pathを書き換えない (2)転送先メールサーバのホワイトリストに転送元メールサーバが存在しない (3)転送先メールサーバがSPFを検証する これは必要にして明確なSPFの特徴である。配送先の「境界」メールサーバ(メールエクスチェンジャ〈MX 〉)の背後では、SPFを直接検証することはできない。
SPFの検証に不合格となる宣言をする者は、潜在的な問題を受け入れなければならない。彼らは全ての配送先メールサーバが転送処理を変更することを要求することはできない。つまり少なくともここに挙げた三つの重大な条件の内一つは明白である。
センダー・リライティング・スキーム (SRS) と呼ばれる手法は、メール転送サービスがこの問題を回避するための方法である。
「境界」メールサーバ(メールエクスチェンジャ〈MX 〉)の背後でSPFを検証することは不可能ではない。通常、検証に関係する情報は、配送された電子メールにメールエクスチェンジャが追加した、Receivedヘッダ行に記される。しかしこの場合、検証不合格メールを拒否するのは非常に時間が掛かり、検証地点においては原則として検証不合格メールを削除することだけ可能である。
専門家はこの権利を得られるべきだが、プラグ・アンド・プレイができる状況ではない。したがってSPF仕様では、メールエクスチェンジャの後ではなく、SMTPセッション中のメールエクスチェンジャだけが、SPFの検証をすることが推奨されている。もしSPFレコードの宣言者が彼らの方針の改善を計画する時に、一緒にDNSキャッシュの満了を考慮して慎重に計画しないと、メールエクスチェンジャの後でSPFを検証することは予想外の結果を得ることもある。