Defaults.Exposed › 報告
僅發佈 SPF 還不夠：電子郵件安全的虛假安全感（2026）
發布於 2026-06-29
數據截至 2026-06-29 · 方法論 v7。 聚合的普查數據，跨 261 百萬個已評級域名按域名彙總各項檢查。“強制執行”= DMARC 策略為
quarantine或reject。參見我們如何評級。
在電子郵件安全中最危險的處境，就是感覺受到了保護。32.4% 的域名發佈了 SPF，卻完全沒有 DMARC——而 45.7% 的域名雖有 SPF，卻沒有強制執行作為後盾。 這些所有者做了點什麼，看到“SPF：已配置”便停了下來。但僅靠 SPF 並不能阻止他人偽造你可見的“發件人”地址——只有強制執行的 DMARC 才能做到。截至 2026-06-29，僅有 3.87% 的域名實現了完整的郵件保護。
“已配置”與“受保護”之間的差距
SPF 檢查哪些服務器可以為你發送郵件。它並不管控人們實際看到的“發件人”地址，也不告訴收件方在驗證失敗時該怎麼做。那是 DMARC 的職責。因此，沒有強制執行的 DMARC 策略的 SPF，就像一把鎖，後面卻沒有門：
| 狀態 | 域名佔比 | 真的受保護嗎？ |
|---|---|---|
| 已發佈 SPF，完全沒有 DMARC 記錄 | 32.4% | 否 |
| 已發佈 SPF，DMARC 未強制執行 | 45.7% | 否 |
| 完整郵件保護（SPF + 強制執行的 DMARC） | 3.87% | 是 |
再讀一遍中間那一行：所有域名中有 45.7% 擁有 SPF 卻沒有強制執行——接近半數的互聯網處於虛假安全的區域。對攻擊者而言，它們是可被偽造的——而整體上有 89.4% 的域名都是如此。
最糟的情形：郵件進得來，門口卻無人把守
對於真正接收郵件的域名，情況更為尖銳。42.7% 的域名接收郵件（它們有 MX 記錄），卻完全沒有可用的郵件身份驗證——既無 SPF 強制執行，也無 DMARC。這些是活躍、在用的域名，其所有者每天收發郵件，卻完全可被冒充。正是這種活躍，使它們成為發票欺詐和供應商詐騙的誘人目標。
為什麼“我們有 SPF”成了陷阱
SPF 更古老、更簡單，也是大多數設置指南首先提及的——所以它就成了被勾選的那一項。DMARC 出現得更晚，聽起來更高級，並且需要有意識地逐步推進到強制執行。結果是龐大的群體採用了第一步，卻從未邁出第二步，隨後繼續相信工作已經完成。這次普查首次讓這一誤解的規模變得可見：32.4% 擁有 SPF 卻完全沒有 DMARC。
如何真正獲得保護
- 保留你的 SPF，但不要只依賴它。（修復 SPF。）
- 添加 DKIM，讓你的郵件得到簽名。（修復 DKIM。）
- 發佈 DMARC 並將其推進到強制執行（
p=none→quarantine→reject）。這一步將“已配置”轉變為“受保護”。（修復 DMARC。）
常見問題
僅靠 SPF 足以阻止郵件偽造嗎？ 不能。SPF 不保護可見的“發件人”地址，也不告訴收件方拒收偽造郵件——只有強制執行的 DMARC 策略才能做到。45.7% 的域名擁有 SPF 卻沒有這種強制執行。
我有一條 SPF 記錄——我受保護了嗎？
單憑它並不夠。只有當 SPF（最好還有 DKIM）由設為 quarantine 或 reject 的 DMARC 作後盾時，你才算受保護。僅有 3.87% 的域名達到了這一點。
還有多大比例的域名可能被冒充？ 89.4%——因為它們缺乏強制執行的 DMARC，無論是否發佈了 SPF。
為什麼有郵件（MX）卻無身份驗證尤其危險？ 42.7% 的域名積極收發郵件，卻沒有可用的身份驗證——這些是活躍、受信任的域名，任何人都能偽造，而這正是詐騙者所尋找的。
檢查你是否真的受到保護
“我們有 SPF”並不等於受保護。免費且私密地檢查你的域名——看看你的郵件是否仍可被偽造。
檢查你的域名 → · 修復 DMARC → · 域名暴露評分 → · p=none 並非保護 → · 僅聚合數據。數據在歐盟存儲和處理。