Defaults.Exposed › 報告
SPF 錯誤配置報告：多數 SPF 記錄設置得過於寬鬆（2026）
發布於 2026-06-29
數據截至 2026-06-29 · 方法論 v7。 針對發佈 SPF 記錄的 138,927,207 個域名的彙總普查數據，來自 261 百萬個已評級域名。參見我們如何評級。
擁有 SPF 與正確設置 SPF 並不是一回事——而且大多數發佈 SPF 的域名都設置得太弱，起不了多大作用。 在擁有 SPF 記錄的 139 百萬 個域名中，有 55.8% 以 ~all（softfail，軟失敗）結尾——這是一種寬鬆設置，它告訴接收方”這可能是偽造的，但仍然投遞它”。只有 39.3% 使用嚴格的 -all。SPF 被廣泛採用，但多數情況下被削去了利爪。
“all” 機制：SPF 成敗的關鍵所在
每條 SPF 記錄都以一個 “all” 機制結尾，它規定了如何處理來自不在你列表中的服務器的郵件。這正是 SPF 的全部意義所在——也是它最常被削弱的地方：
| 結尾 | 含義 | 擁有 SPF 的域名 |
|---|---|---|
-all（hardfail，硬失敗） | 拒絕未列出的發件人——嚴格的、本應採用的設置 | 39.3% |
~all（softfail，軟失敗） | “可能是偽造的，但仍然接受它” | 55.8% |
?all（中立） | 不表態——實際上沒有任何保護 | 3.0% |
+all | 授權整個互聯網以你的名義發送郵件 | 36,014 個域名 |
| 其他 / 無 | redirect/include-only 或沒有結尾的 all | 1.8% |
頭條結論是：softfail（~all）是最常見的設置，佔 55.8%——比 hardfail 還多。單憑其本身，softfail 提供的保護很弱：它請求接收方不要信任未列出的郵件，但又不拒絕它。
危險的邊緣情況
+all—— 36,014 個域名。 這是最糟糕的 SPF 取值：它明確告訴全世界，任何服務器都被允許以該域名的名義發送郵件。這幾乎總是複製粘貼的失誤，而且嚴格來說比根本沒有 SPF 還要糟。- DNS 查詢過多 —— 7,958 個域名。 SPF 最多允許 10 次嵌套 DNS 查詢；超過後，該記錄就成了接收方視為損壞的 “permerror”。它比人們擔心的要罕見（佔 SPF 記錄的 0.01%），但一旦發生，就會悄無聲息地使你的整個 SPF 失效。
softfail 真的是個問題嗎？
如果有 DMARC 作為後盾就不是。現代最佳實踐是 ~all 加上 quarantine 或 reject 的 DMARC 策略——這種搭配既能給你嚴格的強制執行，又不會破壞轉發的郵件。問題在於大量域名使用 ~all 卻背後沒有強制執行的 DMARC——只有10.59% 的所有域名強制執行 DMARC——這使得 softfail 幾乎毫無作用。設置為 ~all 的 SPF 是達成目的的手段；沒有 DMARC，它只是一個建議。
常見問題
SPF 中 ~all 和 -all 有什麼區別？
-all（hardfail）告訴接收方拒絕來自不在你列表中的服務器的郵件。~all（softfail）告訴它們仍然接受郵件，但標記為可疑。55.8% 擁有 SPF 的域名使用 ~all；39.3% 使用 -all。
使用 ~all（softfail）安全嗎？
安全——但只有在與強制執行的 DMARC 策略（quarantine 或 reject）配合使用時才安全。單憑其本身，softfail 提供的保護很弱。
+all 有什麼作用？
+all 授權互聯網上的每一臺服務器以你的域名發送郵件——比沒有 SPF 還糟。36,014 個域名有此設置，幾乎都是出於失誤。
SPF 的”查詢過多”錯誤是什麼？ SPF 最多允許 10 次嵌套 DNS 查詢；超過後，記錄就以 “permerror” 失敗並被忽略。它影響 7,958 個域名。
檢查你的 SPF 是否設置正確
發佈 SPF 只完成了一半工作；嚴格地設置它並用 DMARC 作為後盾才是另一半。私密且免費地檢查你的域名。
檢查你的域名 → · 修復 SPF → · 修復 DMARC → · 為什麼我的郵件進了垃圾箱 → · 僅彙總數據。數據在歐盟存儲和處理。