SPF 誕生於2003年，它的締造者 Meng Weng Wong 結合了反向 MX 域名解析(Reverse MX) 和 DMP (Designated Mailer Protocol) 的優點而付予了 SPF 生命。

SPF 使用電子郵件頭部信息中的 return-path (或 MAIL FROM) 字段，因為所有的 MTA 都可以處理包含這些字段的郵件。不過微軟也提出了一種叫做 PRA (Purported Responsible Address)的方法。PRA 對應於 MUA (比如 thunderbird) 使用的終端用戶的地址。

這樣，當我們把 SPF 和 PRA 結合起來的時候，就可以得到所謂的「Sender ID」了。Sender ID 允許電子郵件的接收者通過檢查 MAIL FROM 和 PRA 來驗證郵件的合法性。有的說法認為，MAIL FROM 檢查由 MTA 進行，而 PRA 檢查由 MUA 來完成。

事實上，SPF 需要 DNS 以某種特定的方式來工作。也就是必須提供所謂的「反向 MX 解析」記錄，這些記錄用來解析來自給定域名的郵件對應的發送主機。這和目前使用的 MX 記錄不通，後者是用來解析給定域名對應的接收郵件的主機的。 
SPF 有哪些需求？

要想用 SPF 來保護你的系統，你必須：
配置 DNS，添加 TXT 記錄，用於容納 SPF 問詢的信息。
配置你的電子郵件系統(qmail, sendmail)使用 SPF，也就是說對服務器上每封進入的郵件進行驗證。

上述第一步要在郵件服務器所屬的域名服務器上進行調整，下一節中，我們將討論這個記錄的細節內容。你首先需要確定的一點是你的域名服務器(bind，djbdns)所使用的語法。但別擔心，SPF 的官方網站提供了一個很好用的嚮導來指導你如何添加記錄。 
SPF 的 TXT 記錄

SPF 記錄包含在一個 TXT 記錄之中，格式如下：
  v=spf1 [[pre] type [ext] ] … [mod]
每個參數的含義如下表所示： 參數 描述
v=spf1  SPF 的版本。如果使用 Sender ID 的話，這個字段就應該是 v=spf2
pre  定義匹配時的返回值。

可能的返回值包括：  返回值 描述
+  缺省值。在測試完成的時候表示通過。
-  表示測試失敗。這個值通常是 -all，表示沒有其他任何匹配發生。
~  表示軟失敗，通常表示測試沒有完成。
?  表示不置可否。這個值也通常在測試沒有完成的時候使用。

type  定義使用的確認測試的類型。

可能的值包括：  候選值 描述
include  包含一個給定的域名的測試
以 include:domain 的形式書寫。

all 終止測試序列。
比如，如果選項是 -all，那麼到達這條記錄也就意味著測試失敗了。但是如果無法確定，可以使用」?all」來表示，這樣，測試將被接受。

ip4 使用 IPv4 進行驗證。
這個可以以 ip4:ipv4 或 ip4:ipv4/cidr 的形式使用。建議使用這個參數，以減少域名服務器的負荷。

ip6 使用 IPv6 進行驗證。

a 使用一個域名進行驗證。
這將引起對域名服務器進行一次 A RR 查詢。
可以按照 a:domain, a:domain/cidr 或 a/cidr 的形式來使用。

mx 使用 DNS MX RR 進行驗證。
MX RR 定義了收信的 MTA，這可能和發信的 MTA 是不同的，這種情況基於 mx 的測試將會失敗。
可以用 mx:domain, mx:domain/cidr 或 mx/cidr 這些形式進行 mx 驗證。

ptr 使用域名服務器的 PTR RR 進行驗證。
這時，SPF 使用 PTR RR 和反向圖進行查詢。如果返回的主機名位於同一個域名之內，就驗證通過了。
這個參數的寫法是 ptr:domain

exist 驗證域名的存在性。
可以寫成 exist:domain 的形式。
ext  定義對 type 的可選擴展。如果沒有這個字段，那麼僅使用單個記錄進行問詢。
mod  這是最後的類型指示，作為記錄的一個修正值。
 修正值  描述
redirect  重定向查詢，使用給出的域名的 SPF 記錄。
以 redirect=domain 的方式使用。

exp 這條記錄必須是最後一條，允許給出一條定制的失敗消息。

IN TXT 「v=spf1 mx -all exp=getlost.example.com」

getlost IN TXT 「You are not authorized to send mail for the domain」

=======================================================

嘿！我是 ISP

ISP 實施 SPF 可能對於他們處於漫遊狀態(roaming)的用戶帶來一些麻煩，當這些用戶習慣使用 POP-before-Relay 這樣的方式處理郵件，而不是 SASL SMTP 的時候問題就會出現。

嗯，如果你是一個被垃圾郵件、地址欺騙所困擾的 ISP 的話，你就必須考慮你的郵件策略、開始使用 SPF 了。

這裡是你可以考慮的幾個步驟。
首先設置你的 MTA 使用 SASL，比如，你可以在端口 25 和 587 使用它。
告訴你的用戶你已經使用了這個策略(spf.pobox.com 給出了一個通知的例子，參見參考文獻)。
給你的用戶一個寬限期，也就是說，把你的 SPF 記錄加入到域名服務器之中，但使用「軟失敗」(~all)而不是「失敗」(-all)。

這樣，你就保護了你的服務器、你的客戶和整個世界免受垃圾郵件之類的困擾了。

SPF 的官方站點上有很多信息，還等什麼呢？ 
有什麼需要擔心的?

SPF 是一個對於欺騙的完美保護。但它有一個局限：傳統的郵件轉發方式不再有效了。你不能僅僅從你的 MTA 接受郵件並簡單地重新發送它了。你必須重寫發送地址。常見的 MTA 的補丁可以在 SPF 的網站找到。換句話說，如果你把 SPF 記錄加入到了域名服務器，你就必須更新你的 MTA 來進行發送地址改寫，即使你還沒有對 SPF 記錄進行檢查。