Sender Policy Framework
検証に不合格となる宣言は、効果的な物となり得るが危険な手段でもある。そこで危険を回避するため、Failの代わりに(限られた試験期間のために作られた)SoftFailが宣言されることがある。しかしFailとなった電子メールを配送先メールサーバが拒否し、SoftFailとなった電子メールは迷惑メールの可能性がある物として受け入れることで、SoftFailはFailより以上に危険な物となり得る。
転送メールを拒否した時の挙動は明白である。その場合は、転送元のメールサーバはReturn-Pathで示されたメールアドレスにエラーメールを送信する。一般的なエラーメール(レスポンス)には、SMTPエラーの説明と配送に失敗した(転送先の)アドレスが含まれる。通常のSMTPエラーコードである「551 User not local; please try <転送先アドレス>」を模倣して、元の送信者は転送元のメールサーバを迂回し、転送先アドレスへ直接電子メールを再送することができる。
SPF実装がSPFレコードの文法エラーを検出すると、直ちに恒久的エラー(PermError)として評価を中断しなければならない。誤っている機構を読み飛ばして続けると、その結果は予想できない。したがって「include:bad.example」や「redirect=bad.example」もまた「PermError」となる。
その他の安全策としては、DNSへ問合せる機構、すなわち「ip4」「ip6」「all」以外のあらゆる機構が、SPFレコード当たり最大10までに制限されている。SPF実装では、評価が長時間に渡る場合やDNSの問合せがタイムアウトとなった際に、一時的エラー(TempError)として評価の中断ができる。もしSPFが直接または間接的に10を超える問合せを必要とした場合は恒久的エラー(PermError)を返さなければならない。「redirect=」もまたこの処理制限に数えられる。
標準的なSPF宣言である「v=spf1 a -all」は、(1)TXTレコード、(2)SPFレコード、(3)AまたはAAAAレコードのように、DNS問合せが3回必要である。この最後のDNS問合せの数は、最初の機構から制限(10)に向かって合計された物であり、今回の例では「all」がDNS問合せを必要としないため、最初の機構が最後でもある。