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 → · 邮件托管市场份额 → · 仅汇总数据。数据在欧盟境内存储与处理。