Sender Policy Framework
SPFの実装は2つの部分から成る。
ドメインが彼らを代表して電子メールを送信するために正式に認めたメールサーバを特定する。ドメインは彼らの既存のDNS情報へこの付加情報を追加する。配送先メールサーバはSPF情報を要求しそれを用いることができる。メールサーバは普段どおりのDNS問合せを使い、一般的にはDNSの性能向上のためにキャッシュされる。配送先メールサーバはSPFに記載された情報を解釈し、その結果に従い行動する。
このように、ドメインが設定し配送先メールサーバが用いる、新しいDNS情報の仕様がSPFの核心である。SPFレコードは下記のように標準的なDNS構文で設定される。example.jp. IN TXT "v=spf1 a mx -all"
「v=」は使用されたSPFのバージョンを定義する。以下の語は、あるドメインが電子メールを送信する資格があるかどうかを、決定するために用いる機構(Mechanism)を規定する。「a」および「mx」は、所定のドメインのために電子メールを送信することが許可されたコンピュータシステムを示す。SPFレコードの最後にある「-all」は、もしそれまでの機構が一致しなければ、メッセージは拒否されるべきということを示す。
またSPFはこれらのメールアドレス詐称を防止するものではない。
スパマーは、送信者ポリシーが記載されているドメインのアカウントを持っていたり、そのドメイン下の危殆化したシステムを不正利用することで、SPFの検証に合格(Pass)する電子メールを送信できる。また、登録ユーザーに対して任意の送信者アドレスからのSPF認証を合格させるようなサービスを提供する不正な認証サーバーを経由することでも、SPFの検証に合格する電子メールを送信できる。しかしながら、そうして作られた迷惑メールは、送信元メールサーバを容易に特定できる。
SPF の主な利点は、Return-Path の詐称にメールアドレスが使われる人々にもたらされる。彼らは頼んでもいない膨大なエラーメールやその他の自動返信メールが送りつけられ、それが電子メールを普通に使うことを難しくしている。もしそのような人々が、正規の送信IPアドレスと同時に、検証に不合格(Fail)するそれ以外の全IPアドレスをSPFレコードに明示すれば、SPFを検証する配送先メールサーバが詐称メールを拒否できるようになり、後方散乱メールの総量が減少する。
SPFは、迷惑メールの身元確認の助けとなる域を越えて、利益をもたらす可能性がある。特に送信者がSPF情報を提供する場合は、配送先メールサーバはSPFの検証に合格した結果を、既知の信頼できる送信者を識別するためのホワイトリストに結合して使うことができる。しかし、危殆化したシステムや共有メール送信システムのようなものは、この使い方を制限するだろう。
2004年1月5日、スティーヴン M. ベロヴィン(Steven M. Bellovin)は長い電子メールを書き、SPFに関する幾つかの懸念について議論した。それは次のような内容だった。
SPFはDNSのTXTレコードを使うが、TXTレコードは特別な意味を持たない自由形式の文章であることが想定されている。SPFの支持者は、SPF用に明確に指定されたレコードを持つ方が良いと直ちに肯定するが、その選択はSPFの迅速な実装を可能にした。2005年7月、IANAはSPFにtype 99の資源レコードを割り当てた。SPFを宣言する者は両方のレコード型で宣言する可能性があり、SPFの検証ソフトはそれぞれの型を検証する可能性がある。全てのDNSソフトがこの新しいレコードに完全に対応するまで、何年も掛かることが予想される。
彼がこの声明文を書いた時は、これが正しい方法であるという合意はなかった。幾つかの主要なメールサービス業者はこの理論に同意しなかった。多くの利用者を抱える主要なメールサービス業者が対応するまで、それらのメールサービスを直接利用する者や、それらのメールサービスのドメインを詐称した電子メールを受け取る者に対して、SPFはあまり効果を上げることができない。SPFに対する関心が高まった時から、特にAOLがSPFを採用した点に注目する価値がある。
ベロヴィンの最も強い懸念は、SPFの根底にある前提(SPFの「意味論モデル」)に関連する物であった。