Defaults.Exposed › 报告

SPF ~all 与 -all：软失败还是硬失败——139 百万条记录的选择（2026）

发布于 2026-07-03

数据截至 2026-06-29 · 方法论 v7。 覆盖 261 百万个已评级域名的普查汇总数据。所有数据均为汇总——我们从不公布任何单个企业的记录。参见我们如何评级。

每一条 SPF 记录都以某个 “all” 机制结尾——它是对来自你名单之外任何地方的邮件所下的裁定——而整个互联网压倒性地选择了温和的那个：在发布 SPF 的 139 百万个域名中，55.8% 以 ~all（软失败）结尾，相较之下只有 39.3% 以 -all（硬失败）结尾。 一个字符之差，就把”拒绝伪造邮件”和”很可能是伪造邮件——但还是投递吧”区分开来。哪一个适合你，取决于第二项设置——一项大多数域名所有者从未配置的设置。**

~all 和 -all 到底在告诉接收方什么？

• -all（硬失败）： “拒绝来自其他任何地方的邮件。” 一个坚决的”不”。
• ~all（软失败）： “来自别处的邮件很可能不合法——接收它，也许标记一下。” 一个耸肩。
• ?all（中立）： “没有意见。” 被 3.0% 的发布者选用；徒有保护之名。
• +all： “任何人都可以冒充我发送。” 由 36,014 个域名发布，比没有记录还糟——这个”欢迎门垫”问题有专门的报告。

那么 ~all 就是错的吗？只有在它孤军奋战时才是——而它几乎总是孤军奋战

软失败在现代有一个站得住脚的理由：Google 的发件人指南，以及大多数与之一致的投递实践，都汇聚到 ~all 搭配一条强制执行的 DMARC 策略（p=reject） 上。这种搭配在每一个评估 DMARC 的接收方——如今这包括所有主流邮箱服务商——都能提供与 -all 同等的保护，同时又不会硬性退回合法的转发邮件，而那正是 -all 的典型受害者。在这种配置下，那个耸肩就有了牙齿：DMARC 提供了 SPF 拒绝下达的裁定。

但关键就在于这种搭配，而普查在这里补充了配置指南给不出的信息：在互联网上的 77,484,057 条软失败记录中，只有 7.1 百万条——约 11 分之一——背后有一条强制执行的 DMARC 策略。 对于其余的 70.4 百万个域名，~all 就是它字面上的意思。它们的记录识别出了伪造邮件，然后挥手放行。

2024 年的强制规定难道没有解决这个问题吗？

没有——而且这个区别比大多数报道所暗示的更为重要。Google 和 Yahoo 于 2024 年 2 月开始要求批量发件人进行身份验证，Microsoft 随后于 2025 年 5 月跟进：需要通过且对齐的 SPF 或 DKIM，外加一条 最低为 p=none 的 DMARC 记录。这些强制规定并未走到要求强制执行那一步——一个拥有 ~all、一条 p=none 记录和对齐 DKIM 的域名就完全合规，却仍然可以被完全伪造。这些强制规定使文书工作变成了常态，而非保护。 那个未强制执行的中间地带——合规、已发布、可伪造——正是本次普查所测量的缺口，也是电子邮件安全领域中规模最大的群体。

那么你的记录应该以什么结尾？

1. 你会发送邮件且转发很重要（新闻通讯、邮件列表、别名）：~all 搭配 DMARC p=reject 在其背后——即上文推荐的搭配。
2. 你从一个严格受控的环境中发送邮件： -all 可行，并且在记录本身中就声明了策略。请先梳理清楚你的发件方——在一条未梳理的记录上使用严格结尾会破坏真实邮件，甚至更糟。
3. 该域名从不发送邮件： 今天就用 -all 加 p=reject。没有任何合法邮件需要保护，因此也就没有什么会被破坏。

无论你选择哪种结尾，普查那一句话的教训都成立：限定符的意义，只取决于是什么在强制执行它。 你处在这个阶梯的哪一级是可测量的。

常见问题

SPF ~all 和 -all 哪个更好？ 没有一个普遍更好。~all 搭配一条强制执行的 DMARC 策略是 Google 指南推荐的模式——在评估 DMARC 的接收方提供同等保护，又不破坏转发邮件。-all 适合严格受控的发件方。单独的 ~all——除了 11 分之一以外所有软失败域名所处的状态——才是薄弱的选择。

SPF 软失败是什么意思？ ~all 告诉接收方，来自未列出服务器的邮件很可能不合法，但仍应接收，通常带着疑虑。只有当一条 DMARC 策略对失败采取行动时，它才成为真正的保护；参见没有 DMARC 的 SPF。

硬失败 -all 会破坏我的转发邮件吗？ 有可能：转发会从转发方的服务器重新发送你的邮件，而你的 SPF 并未列出该服务器，硬失败会招致在 DKIM 或 DMARC 参与判定之前就被拒收。这种风险正是 ~all + p=reject 搭配存在的原因。

Google 和 Microsoft 现在要求 -all 吗？ 不要求。批量发件人强制规定要求对齐且通过的身份验证，以及一条最低为 p=none 的 DMARC 记录——不要求强制执行，也不指定具体的限定符。Google 对不合规批量邮件的拒收已经生效；Microsoft 一直在将失败邮件投入垃圾箱，并正朝着彻底拒收迈进。合规不等于保护。

检查你的记录以什么结尾——以及背后有什么在支撑

两次查询，免费，30 秒内就能同时告诉你这两点。如果你是那 70.4 百万个未强制执行的”耸肩”之一，修复的方法是一条 DNS 记录，而不是一笔购买。

检查你的域名 → · 修复 SPF → · 修复 DMARC → · SPF 成熟度模型 → · +all 地图 → · 仅汇总数据。数据在欧盟境内存储和处理。