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 并非保护 → · 仅聚合数据。数据在欧盟存储和处理。