Defaults.Exposed › 報告
哪家郵件服務商給客戶提供了最強的 SPF 默認配置？（2026）
發布於 2026-07-03
數據截至 2026-06-29 · 方法論 v7。 覆蓋 261 百萬個已評級域名的彙總普查。我們統計已發佈 SPF 記錄中確切的
include:/redirect=目標——公開 DNS，按服務商聚合；絕不針對任何單一企業的記錄。參見 我們如何評級。
每條 SPF 記錄都列明了允許為某個域名發信的服務——因此 139 百萬條 SPF 記錄也是一份服務商默認配置的普查，而這些默認配置差異極大：85.0% 包含 Microsoft 365 的域名以嚴格的 -all 結束 SPF，相比之下只有 8.0% 包含 Google Workspace 的域名如此。 第二個發現更為重要：在真正能阻止偽造的指標上——即記錄背後有一條強制執行的 DMARC 策略——沒有一家主流郵箱服務商的客戶群能超過 30% 完成配置。
排行榜：按服務商劃分的嚴格結尾與完整防護
SPF 中包含各服務商的域名；以嚴格結尾（-all）的佔比；以及具備強制執行 DMARC 的佔比——這是 能阻止偽造的組合：
| 服務商（include 目標） | 授權域名數 | 嚴格 -all 佔比 | 具備強制執行 DMARC 佔比 |
|---|---|---|---|
Google Workspace (_spf.google.com) | 12,145,313 | 8.0% | 18.5% |
Microsoft 365 (spf.protection.outlook.com) | 10,205,070 | 85.0% | 21.7% |
Namecheap forwarding (spf.efwd.registrar-servers.com) | 7,355,985 | <0.1% | 0.2% |
GoDaddy (secureserver.net) | 7,061,426 | 86.0% | 29.3% |
Hostinger (_spf.mail.hostinger.com) | 4,476,640 | 0.2% | 1.0% |
IONOS EU (_spf-eu.ionos.com) | 4,346,526 | 0.3% | 1.0% |
HostGator (websitewelcome.com) | 3,102,616 | 0.6% | 1.6% |
OVH (mx.ovh.com) | 2,132,049 | 43.7% | 2.2% |
Cloudflare Email Routing (_spf.mx.cloudflare.net) | 2,007,483 | 2.9% | 10.0% |
MailChannels (relay.mailchannels.net) | 1,870,177 | 28.4% | 10.0% |
Mailgun (mailgun.org) | 1,306,692 | 7.2% | 35.9% |
SendGrid (sendgrid.net) | 740,321 | 19.0% | 18.0% |
Zoho Mail (zohomail.com) | 662,546 | 7.3% | 9.9% |
Amazon SES (amazonses.com) | 551,446 | 28.3% | 41.9% |
Stackmail / 20i (spf.stackmail.com) | 519,246 | 98.2% | 3.3% |
如何解讀這張表——實話實說
關於這份數據是什麼、不是什麼的四點說明：
- 每一行是 include 群體，而非客戶群體。 一個同時包含 Google 和 Mailgun 的域名會同時出現在兩行中。
- 嚴格一列拍下的是各服務商的設置模板加上其客戶構成的快照。 微軟的初始配置會輸出
-all；Google 的文檔推薦~all；託管面板會在可能根本不發信的域名上自動預配記錄——這可能在無人做出任何決定的情況下拉高嚴格佔比。 - 較低的嚴格佔比並不自動等於錯誤。 Namecheap 那一行是一款郵件轉發產品——而轉發恰恰是
-all會誤傷 的場景，因此在那裡採用寬鬆模板可以說是正確的配置。那一行的暴露風險在於另一列：僅 0.2% 達到強制執行。 - 強制執行一列才是真正的排名依據。 一旦 DMARC 強制執行，嚴格與寬鬆就只是風格選擇；若沒有強制執行，兩種結尾在大多數接收方那裡都無法阻止偽造。
各列中的三個故事
- 默認即命運。 客戶絕大多數會保留嚮導給他們的配置——92% 包含 Google 的域名保留了非嚴格結尾，絕大多數是 Google 指南推薦的
~all；98.2% 的 Stackmail 域名保留了其面板寫入的-all。幾乎沒有人後來重新決定限定符。這是 整個普查 的立足觀察，被書寫了 139 百萬次。 - 終點線是由用戶跨越的，而非模板。 強制執行的領跑者是以開發者為中心的發信方——Amazon SES（41.9%）和 Mailgun（35.9%）——其客戶更偏向於會把工作做完的團隊。大型郵箱服務商的客戶群則介於 18.5% 和 29.3% 強制執行之間，無論其 SPF 模板有多嚴格。
- 暴露的主體是託管與轉發這一層。 Namecheap 轉發、Hostinger、IONOS 和 HostGator 合計覆蓋超過 19 百萬個域名，強制執行率卻在 2% 或以下——這些是運行著面板所安裝的任何配置的小企業域名，被寬鬆地圍欄且未強制執行。
該拿你自己的域名怎麼辦
- 查看你的 SPF 實際包含了哪些服務商——
dig TXT yourdomain.com，或 免費檢測。 - 不要盲目照搬嚴格結尾：梳理你的發信方，然後要麼收緊為
-all，要麼保留~all並在其背後配上 DMARCp=reject。 - 無論你的服務商給了你什麼，那都只是一份你繼承來的模板——而一次免費的 DNS 編輯就能改變它。
常見問題
哪家郵件服務商的 SPF 默認配置最安全？
按嚴格模板來看：Stackmail / 20i（98.2% 的域名以 -all 結束）、GoDaddy（86.0%）和 Microsoft 365（85.0%）。按完整防護——即 SPF 背後有強制執行的 DMARC——Amazon SES 的客戶以 41.9% 領先。這兩項指標分別獎勵的是嚴格的模板和會把配置做完的客戶群。
使用 Google Workspace 是否意味著我的 SPF 很弱？
本質上並非如此。Google 推薦的 ~all 是穩妥的做法——前提是搭配一條強制執行的 DMARC 策略——但截至 2026-06-29，只有 18.5% 包含 Google 的域名做到了這種搭配。弱點不在於 softfail；而在於止步於此。
這些數字是在評判服務商自身的安全性嗎？ 不是。它們衡量的是包含各服務商的客戶域名所發佈的 SPF 態勢——聚合的公開 DNS，受設置模板、文檔和客戶構成的影響塑造。沒有任何單一域名被公開識別或評級。
為什麼我服務商的模板決定了我的安全性？ 因為它在第一天被複製一次，而我們的普查顯示它幾乎從不被重新決定。默認配置會持續存在——這正是花 30 秒檢查你自己的配置值得的原因。
檢查你的域名繼承了什麼
無論設置嚮導寫下了什麼，它仍然躺在你的 DNS 裡。讀取它——並完成它——都是免費的。
檢測你的域名 → · 修復 SPF → · ~all 對比 -all → · 沒有 DMARC 的 SPF → · 郵件託管市場份額 → · 僅彙總數據。數據在歐盟境內存儲與處理。