Defaults.Exposed › 報告
SPF +all：任由整個互聯網冒名發信的那些域名（2026）
發布於 2026-07-03
數據截至 2026-06-29 · 方法論 v7。 對 261 百萬個已評級域名的彙總普查。所有數據均為彙總統計——絕不針對某個企業的單條記錄。參見我們如何評級。
36,014 個域名的 SPF 記錄以 +all 結尾——這是一份已公開、可被機器讀取的聲明，表示互聯網上的每一台服務器都獲准以它們的名義發送電子郵件。 這是最罕見的 SPF 錯誤配置（佔發佈者的 0.03%），也是最自毀的一種：缺失記錄只是讓接收方各憑啟發式判斷，而 +all 卻是明確地告訴他們冒名者是合法的。
SPF 記錄中的 +all 是什麼意思？
末尾的 all 機制帶有一個限定符——它決定了對不在你名單上的發件人應作何裁決。-all 拒絕他們，~all 懷疑他們——而 +all 批準他們。當接收方拿一封偽造郵件去核對一條 +all 記錄時，會返回一個乾淨的 SPF 通過。一句話就是這樣的危害：你的防護反倒替冒名者作了擔保。而且由於 SPF 通過能滿足 DMARC 的 SPF 一側，這個通過還能幫助一封仿冒郵件穿過那個原本就是為了攔住它而建立的系統。
分佈圖：「歡迎墊」聚集在哪裡
+all 到處都有，但極為稀薄——不過其比率因後綴而有明顯差異。計數來自普查；比率 = 每 10,000 個該 TLD 的 SPF 發佈者中的 +all 記錄數：
| TLD | +all 域名數 | 每萬個的比率 |
|---|---|---|
| .be | 1,399 | 22.5 |
| .nl | 1,965 | 8.8 |
| .eu | 672 | 6.6 |
| .fr | 1,147 | 6.2 |
| .net | 1,640 | 3.6 |
| .org | 1,392 | 2.8 |
| .com | 16,636 | 2.4 |
| .de | 732 | 1.3 |
比荷盧—法國這一簇尤為突出：一個 .be 的 SPF 發佈者帶有 +all 的可能性大約是 .com 發佈者的 9 倍（每萬個 22.5 對 2.4）。如此集中的模式很少意味著成千上萬個各自獨立的失誤——最合理的解釋是存在一個共同源頭：某個區域性的託管面板、註冊商模板或教程文章附帶了 +all，然後被複製沿用了許多年。同樣的指紋也出現在嚴重程度低一檔的地方：.za 有 22.6% 的 SPF 記錄以中立的 ?all 結尾，這個全國性的異常值指向的是同一個方向。
一個域名怎麼會落到 +all 的地步？
三條途徑，都很無辜：
- 那個永遠沒結束的調試。
+all會讓每一個 SPF 問題都消失——郵件暢通，報錯停止。有人為了打通一次上線把它設成了這樣，而這條記錄在事件結束後依然存活了下來。 - 誤讀了語法。 如果你從沒見過限定符對照表，
+看起來就像是「允許我的名單」的意思。本意是-all，那個字符卻把它反了過來。 - 繼承來的模板。 正如分佈圖所暗示的，有些記錄一到手就已經是壞的，來自某個面板或指南。
只需改一個字符的修復
把 +all 改成 -all——或者改成 ~all，並在其背後配上強制執行的 DMARC。一條 TXT 記錄裡的一個字符，免費，而且只要 DNS 更新就會生效——通常在一小時內。沒有比這更快的安全改進能在一個域名上實現了。
常見問題
SPF 記錄中的 +all 是什麼意思？ 它授權互聯網上的每一台服務器以你的域名發送電子郵件——與 SPF 的目的正好相反。截至 2026-06-29，有 36,014 個域名發佈了它。
+all 比根本沒有 SPF 記錄更糟糕嗎？
在最要緊的那一點上，是的：沒有記錄只是讓接收方去猜，而 +all 卻能把一封偽造郵件轉化為一個乾淨的 SPF 通過——這個通過甚至還能幫它穿過 DMARC。有些過濾器還會把 +all 本身當作垃圾郵件信號，所以它連你的合法郵件也可能一併傷害。
我該如何檢查自己的域名是否有 +all？
讀取你的 TXT 記錄（dig TXT yourdomain.com），或者運行免費檢查——一個寬鬆的限定符會被立即標記出來。
為什麼會有模板默認用 +all？ 最合理的解釋是它不會產生任何支持工單——每一次投遞都「成功」，包括那些欺詐性的。我們數據中的區域聚集現象，與其說是成千上萬個個人選擇，不如說更符合模板默認值的特徵，儘管普查看到的是記錄，而非它們的作者。
檢查你的結尾
大多數把「歡迎墊」擺在門外的域名所有者，壓根不知道它在那裡。讀一讀你自己的門墊只要半分鐘，而重寫它只花一個字符。
檢查你的域名 → · 修復 SPF → · ~all 對 -all → · 錯誤配置名人堂 → · 僅彙總數據。數據在歐盟境內存儲和處理。