什麼是 SPF 的 ptr 機制——為什麼至今仍有 950,631 條記錄在用它？（2026）

發布於 2026-07-03

數據截至 2026-06-29 · 方法論 v7。 對 261 百萬個已評級域名的彙總普查。所有數據均為彙總統計——絕不涉及任何單個企業的記錄。參見我們如何評級。

ptr 是一種 SPF 機制，它通過反向 DNS 查詢來授權發件方——而 SPF 標準本身自 2014 年起就明確表示「不要使用它」。12 年後，仍有 950,631 個域名在發佈它。這意味著，在互聯網上 139 百萬條 SPF 記錄中，大約每 146 條就有 1 條攜帶著一個在其中某些域名註冊之前就已被規範棄用的機制。

ptr 本應做什麼

ptr 的含義是：「接受來自任何反向 DNS 能解析回我域名的服務器的郵件。」這聽起來很優雅——無需維護 IP 列表。但實際上，它要求接收方對連接的 IP 做一次反向查詢，然後對返回的每一個主機名做正向確認。RFC 7208（§5.5）用直白的措辭將其棄用：該機制*「速度慢，在出現 DNS 錯誤時不如其他機制可靠，並且對 .arpa 域名服務器造成巨大的資源負擔」*——並明確指出它**「不應被使用（SHOULD NOT be used）」**。

為什麼它在 2026 年仍是一個陷阱

一個 12 年前就被棄用的機制，至今仍值得關注，有三個原因：

它消耗你的查詢額度。 每個 ptr 都會計入 SPF 每次校驗最多 10 次 DNS 查詢的硬性上限——一旦超出這個上限，整條記錄就會因 PermError 而失效。一個什麼可靠功能都不提供的機制，仍在佔用你真正的 include: 機制所需的額度。
它會不可預測地失敗。 反向 DNS 是大多數網路中維護最差的一個角落。當 ptr 查詢超時，或正向確認失敗時，你的合法郵件就會失去它本指望的那個 SPF pass。
有些接收方乾脆跳過它。 因為標準已將其棄用，一些實現直接忽略 ptr——所以它本該授權的那些發件方，從一開始就根本沒有得到保護。

它從何而來

如今幾乎沒有人會主動選擇 ptr。它是通過繼承而來的：一份寫於 2009 年的配置指南，一個從舊服務器配置裡複製來的模板，一條歷經三次託管遷移而原封不動的「能用」的記錄。這正是我們的普查在每一個已棄用卻仍存在的機制中所看到的模式：舊建議不會消亡，它只是被不斷複製粘貼。 攜帶 ptr 的域名並非粗心大意——他們只是在遵循 12 年前就已退役的指示。

如何修復它——免費，五分鐘

找到你的 SPF 記錄（dig TXT yourdomain.com，或免費檢測）。
如果其中包含 ptr，弄清楚哪些服務器曾依賴它。
用精確的形式替換 ptr：對你自己控制的服務器使用 ip4:/ip6: 塊，或使用你的服務商所記載的 include:。
既然你已經在改，順便確認記錄以一個真正的限定符結尾——參見 ~all 與 -all。

常見問題

SPF 記錄中的 ptr 是什麼意思？ 它會授權任何反向 DNS 能解析進你域名的服務器。RFC 7208 §5.5 在 2014 年以「慢且不可靠」為由將其棄用，並指出它不應被使用——然而截至 2026-06-29，仍有 950,631 個域名在發佈它。

SPF 的 ptr 機制有任何時候是有效的嗎？ 它仍然能被解析，一些接收方也仍會評估它——但標準在所有情況下都建議不要使用它，一些接收方會忽略它，而且它會消耗你十次 DNS 查詢中的一次。沒有任何現代配置會讓 ptr 成為正確答案。

我應該用什麼來代替 ptr？ 對你自己控制的服務器使用 ip4:/ip6: 塊，或使用你服務商所記載的 include:。兩者都是確定性的、快速的、可靠的——恰恰是 ptr 所不具備的一切。

ptr 會計入 SPF 的 10 次查詢上限嗎？ 會——每個 ptr 至少會消耗接收方在放棄並返回 PermError 之前所執行的十次 DNS 查詢中的一次。在一條已經堆滿 include: 機制的記錄上，這個失效的機制很可能就是把你推過上限的那一個。

檢查你的記錄裡有沒有「幽靈」

一個 12 年前就被棄用、卻仍安坐在你 DNS 裡的機制，正是那種沒人會去主動排查的東西。而排查它只需半分鐘。

檢測你的域名 → · 修復 SPF → · 兩條 SPF 記錄 = 零條 → · SPF 成熟度模型 → · 僅為彙總數據。數據在歐盟境內存儲和處理。