Sender Policy Framework
変更子はSPFの将来の拡張を考慮する。これまでのところ、RFC 7208で定められた2つの変更子については、広く展開された。
「exp=some.example.jp」は、DNSのTXTレコードにドメイン名を挙げる。それはSMTPエラーコードに加え失敗(Fail)の説明(一般的にはURL)を得るためにSPFのマクロ言語を用いて解釈される。この過度に装飾的な機能はほとんど使われない。
「redirect=some.example.jp」は、他ドメインのSPFレコードに「all」を結び付ける代わりに使うことができる。この変更子は幾らか類似した機構である「include」を理解するより簡単である。
SPFを使う時、どのように電子メールが送信されることが許されるのかということを、SPFのDNSレコードは決定する。つまり電子メールの送信方法についてドメインの所有者が制御することになる。(例えば、医師や弁護士などの専門家に対して作られたメールアドレスなど)個人が移動する先々で使える「携帯型」のメールアドレスを使う人は、メール送信に用いるメールサーバのドメインを送信者アドレスとして使うことが必須となっている。しかしその送信者アドレスはすでに存在しないかも知れない。それらの「携帯型」メールアドレスを提供している組織は、その組織が自らMail Submission Agent(MSA)(RFC 4409)やVirtual Private Network(VPN)を用意するということもあり得る。またSPFはメール送信を許されたMSAにSMTPのReturn-Pathを関係付けるだけであり、利用者が別の場所で発行された自分のメールアドレス(RFC 2822)を使うことは自由なままである。
Jonathan de Boyne Pollardは、SPFが電子メールに関するRFCと矛盾するという議論において、SPFに反対して別の痛烈な非難を書いた。ISPの顧客に特定の方法で電子メールを使用させることをISPに押し付けることと、転送時の問題がSPFの能力である。
インターネット上の電子メールに用いられる「SMTP」は、差出人のメールアドレスを誰でも自由に名乗ることができる。これが事実上の標準として普及したため、セキュリティ上の欠陥として表面化することになった。これにより、迷惑メール送信者、いわゆる「スパマー」による差出人アドレスの詐称が世界各地で行われ、利用者を悩ませてきた。
そのため、議論は次第に本格化し、対策のひとつとして、SPFが登場した。これは、IPアドレスの詐称は難しいという前提のもとに策定されており、原則として、DNSサーバ上に記載される情報を取得するだけで、認証を完了できる。SPF対応したドメインにするには、そのドメインが属するDNSサーバ内のゾーンファイルに、 SPFレコードと呼ばれる構文を追記することで容易に実装できる。
SPFは、全ての迷惑メールを防御できるわけではない。SPFが行うのは、あくまで「差出人アドレスに記載されたドメイン名を読みとり、正しいメールサーバから送信されているかどうかを検出すること」である。そのため、例えば大企業や政府などのドメインになりすました電子メールを経由したフィッシング詐欺などには効果があるものの、差出人アドレスを詐称していない迷惑メールは検出できない。また、同一ドメイン内で、アカウント部分のみを詐称してメール送信ができる場合、SPFでは検出ができない。
しかし、SPFは、ドメイン所有者側での対応が比較的容易であることもあり、普及は進んでいると言える。日本においては、携帯電話事業者を中心に、電子メールで用いられるフィルタリングサービスのひとつとして提供されており、「ドメイン認証」のほか「なりすましメール対策」などと称されて急速に普及している。