SPF記錄

這裡的SPF不是防曬指數，而是指Sender Policy Framework。翻譯過來就是發信者策略架構，比較拗口，通常都直接稱為SPF。

SPF是為了防範垃圾郵件而提出來的一種DNS記錄類型，它是一種TXT類型的記錄，它用於登記某個域名擁有的用來外發郵件的所有IP位址。例如:
dig TXT 21cn.com
21cn.com. 27970 IN TXT "v=spf1 ip4:202.105.45.0/24 ip4:61.140.60.0/24 ip4:202.123.79.206 ip4:220.232.167.218 ip4:221.192.129.0/24 ip4:59.36.102.0/24 -all"
按照SPF的格式在DNS記錄中增加一條TXT類型的記錄，將提高該域名的信譽度，同時可以防止垃圾郵件偽造該域的發件人傳送垃圾郵件。
SPF是跟DNS相關的一項技術，它的內容寫在DNS的txt類型的記錄裡面。MX記錄的作用是給寄信者指明某個域名的郵件伺服器有哪些。SPF的作用跟mx相反，它向收信者表明，哪些郵件伺服器是經過某個域名認可會傳送郵件的。
由定義可以看出，SPF的作用主要是反垃圾郵件，主要針對那些發信人偽造域名的垃圾郵件。
例如：當Coremail郵件伺服器收到自稱發件人是[email protected]的郵件，那么到底它是不是真的gmail.com的郵件伺服器發過來的呢？那么我們可以查詢gmail.com的SPF記錄
關於SPF的一些知識
當前市場上很多郵件系統和供應商都已經開始支持SPF，比如163.com，那么該如何得到163.com的SPF值呢？在CMD環境中，鍵入：
nslookup
set type=txt
163.com
就會得到以下的結果：
163.com text =
"v=spf1 ip4:220.181.12.0/22 ip4:202.108.9.128/25 ip4:202.108.5.0/24 ~all"
163.com nameserver = ns3.nease.net
163.com nameserver = ns.nease.net
ns.nease.net internet address = 202.106.185.75
ns3.nease.net internet address = 220.181.28.3
其中："v=spf1 ip4:220.181.12.0/22 ip4:202.108.9.128/25 ip4:202.108.5.0/24 ~all"就是163.com的SPF值。這個數據中說明了163.com有效合法伺服器都有哪些！
那么我們該如何創建呢？
進入域名解析創建一條txt記錄填寫正確的SPF數據就可以生效了。
在mdaemon7.x中啟用SPF功能，並作適當調整就可以了。
另外8.x版本新增加了一個DomainKey簽名，不過MDaemon已經自動幫你創建。
另外給大家一個網址，很實用
http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/
這個網址是一個創建SenderID的嚮導網站，他能幫你創建一個SenderID值。
SenderID （寄件人身份識別技術）。
SPF（SenderPolicyFramework，寄件人政策架構）。
SenderID技術與SPF一樣，都是一種以IP（網際網路協定）位址認證電子郵件寄件人身份的技術。
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 記錄進行檢查。
結論
你可能覺得 SPF 的實施有點難以理解。不過這確實不算複雜，而且還有一個不錯的嚮導來幫你完成這個轉換(參見參考文獻)。
如果你被垃圾郵件所困擾的話，SPF 將可以幫助你，保護你的域名免受偽造郵件地址的影響，你所要做的僅僅是在域名伺服器上添加一行文本並配置你的電子郵件伺服器而已。
SPF 的優點有很多。不過，像我對一些人所說的，這不是一夜之間就可以達到的，SPF 的好處將通過日積月累來表現出來，當其他人都使用它的時候就能明顯地看到了。
我也提到了 Sender ID，這和 SPF 有關，但我沒有去解釋它。可能你已經知道原因了，微軟的策略一向如此---軟體專利。在參考文獻中，你可以看到 openspf.org 對於 Sender ID 的立場聲明。
解決MT傳送郵件通知給GMail遇到的SPF校驗問題
blog系統有一個很有用的功能就是郵件傳送留言通知：但是傳送到GMail信箱的通知信十有八九都會被標記為垃圾郵件。原因就是SPF：Sender Policy Framework (SPF) 要做傳送人校驗，而MT設定的發信人是留言者的郵件地址，而退信地址是MT系統所在伺服器的信箱。
Received-SPF: neutral (google.com: 60.195.249.163 is neither permitted nor denied by domain of [email protected])
我的WEB伺服器上沒有任何郵件系統。所以無法通過SPF校驗，有嚴格的SPF校驗這也是GMail相對Spam比較少的原因。
如何解決呢：
1 增加郵件系統，設定MX記錄等，需要學不少東西；
2 簡單的就是先發到不支持SPF校驗的郵件系統上，然後再轉發給GMail，這時候的退信地址已經轉發信箱了：
Received-SPF: pass (google.com: domain of #####@yeah.net designates 60.12.227.137 as permitted sender)
您的域管理員或託管公司僅需在域名系統 (DNS) 中發布 SPF 記錄。這些簡單的文本記錄標識了經過授權的電子郵件傳送伺服器（通過列出這些伺服器的 IP 地址）。電子郵件接收系統會檢查郵件是否來自經過正確授權的電子郵件傳送伺服器。檢查步驟如下，傳送人向接收方傳送一封電子郵件後，郵件接收伺服器接收電子郵件並執行如下操作：
• 檢查哪一個域聲稱傳送了該郵件並檢查該域的 SPF 記錄的 DNS。
• 確定傳送伺服器的 IP 地址是否與 SPF 記錄中的某個已發布 IP 地址相匹配。
• 對電子郵件進行打分：如果 IP 地址匹配，則郵件通過身份驗證並獲得一個正分。如果 IP 地址不匹配，則郵件無法通過身份驗證並獲得一個負分。然後，對現有的防垃圾郵件篩選策略和啟發式篩選套用這些結果。