Defaults.Exposed › 报告

为什么我的SPF失败了？英国和欧盟发件人的SaaS 10次查询问题（2026年）

发布于 2026-07-09

数据截至2026-06-29 · 方法论 v7。 覆盖261百万个已评级域名的汇总普查数据。查看我们的评级方式。

当英国或欧盟企业使用SaaS工具时SPF失败，最可能的原因是一条您从未需要考虑过的RFC规则：超过10次DNS查询后，SPF不会返回”fail”——它会返回PermError，意味着该记录被视为不存在。 至少已有797,263个域名越过了这条线。另有2,119,539个域名正好处于9至10次查询的边缘——再新增一个工具就会跌入同样的深渊。

添加SaaS工具后为何SPF会出现问题？

SPF通过列出被授权代表您的域名发送邮件的邮件服务器来工作。现代企业不再运营自己的邮件服务器——他们使用Google Workspace处理内部邮件、Mailchimp用于营销活动、HubSpot用于销售序列、Pipedrive用于CRM外联。每个平台都会提供一行include:供您粘贴到DNS中。

问题在于：每个include:本身就是一次DNS查询。该include内部的每条记录也可能递归地触发更多查询。RFC 7208 §4.6.4设定了10次的硬性上限。超过10次后，接收邮件服务器将停止评估并返回PermError——PermError并非最终进入垃圾邮件的软性失败，它意味着您的SPF记录被视为不存在。邮件身份验证在SPF环节失败。

您在DNS面板中看不到这种情况。计数器仅在实时评估期间触发。您的可见记录中可能只有三行include:，但实际上可能已有12层查询深度，因为每个供应商的SPF记录都会引入自己的子-include。

已有多少域名超过了限制？

至少797,263个。 这是在解析了所有被引用100次或以上的SPF include:目标（10,842个独立目标，覆盖所有include引用的95.2%）并评估每个域名完整链路之后得出的数字。表面计数（仅计算记录中可见行的方式）约能找到7,958个。链路评估后的数字是其100倍，因为几乎所有损害都隐藏在include目标内部不可见。

最可能影响欧洲企业的情况：

欧洲托管服务商与薄弱的SPF默认设置

您最初选择的托管服务商至关重要——因为有些服务商设置的SPF默认值在您接入任何SaaS工具之前就已消耗了10次查询配额中的几次。

在我们普查中欧洲域名使用的最大托管服务商中：

IONOS尤为突出：1.0%的IONOS托管域名启用了强制DMARC，这意味着绝大多数域名根本没有任何有意义的发件人身份验证。OVH域名在SPF严格设置方面表现更好（43.7%），但在DMARC强制执行方面仍降至2.2%——没有DMARC的SPF只能保护信封，而非收件人实际看到的From:标头。

Microsoft 365是个积极的例外：85.0%的Microsoft托管域名使用严格SPF，这主要是因为Microsoft的邮件流向导默认设置为-all。Google Workspace默认设置为~all（软失败），导致其92%的域名缺乏严格保护。

如何在60秒内诊断您的SPF故障

最快的检查方法是使用能评估完整查询链（而非仅可见记录）的免费工具。在命令行运行nslookup -type=TXT yourdomain.com，计算看到的每个include:。然后查找每个记录并计算其中的数量。如果在include用完之前手指先不够用，您就处于危险区域。

更可靠的方法：在此检查您的域名——扫描器会评估完整的解析链，标记PermError，并显示哪些机制正在消耗您的查询配额。

三种诊断结果：

• PermError — 您已超过10次。发送的每封邮件都会在接收方的SPF检查中失败。
• 处于9至10次查询 — 您正处于悬崖边缘。下一个SaaS集成将使您跌落。
• Softfail (~all) 而非 hardfail (-all) — 您在限制以内，但记录设置过于宽松，无法提供真正的保护。关于-all与~all的完整说明，请参阅SPF配置错误报告。

使用多个SaaS工具时如何修复SPF

按永久性从高到低，有三种方法：

1. 审计和清理。 首先列出当前记录中的所有include:。删除任何您不再使用的平台——旧的ESP、以前合同中的CRM工具、测试后放弃的平台。这是免费的，通常可以恢复几次查询配额。每删除一个include:可能消除1至3个子查询。

2. 压平您的SPF记录。 SPF压平将所有include:目标解析为底层IP范围，并将其直接以ip4:和ip6:机制写入您的记录。IP机制不触发查询，因此压平后的记录可以列出数十个发件来源，查询次数仍为零。缺点是：每当供应商更新其发件IP时您需要重新压平，而这种更新不会提前通知。大多数企业使用付费的SPF压平服务（PowerDMARC、EasyDMARC、Dmarcian等均提供此服务）或构建监控工作流。

3. 使用SPF宏。 RFC 7208宏允许您构建每次检查只执行一次DNS查询并动态响应的记录，而非采用include链式结构。宏需要DNS托管支持和一定的实施工作，但对于拥有大量SaaS发件人的组织来说，这是架构上最干净的解决方案。

修复SPF后，将其与DMARC强制执行配合使用——没有DMARC的SPF只能验证信封发件人，而非收件人看到的From:标头地址。

常见问题

为什么我的SPF记录通过了DNS工具测试，却仍在邮件标头中失败？ 大多数DNS查询工具只计算您自己记录中可见的机制，而不计算这些机制触发的子查询。您可能只有两行include:，但如果每个供应商的记录中还包含更多，您同样会超过限制。只有链路评估工具（或接收邮件服务器）才能计算完整深度。检查您的域名以查看真实的链路计数。

SPF失败是否意味着我的邮件会进入垃圾邮件？ PermError（查询次数过多）意味着身份验证的SPF环节返回无结果——实际上相当于缺失。DMARC同时评估SPF和DKIM；如果DKIM通过，即使SPF出现PermError，DMARC仍可能通过。如果两者均未通过，DMARC失败，结果取决于您的DMARC策略。p=none时，邮件仍会投递但失败会被记录。p=quarantine或p=reject时，邮件会被过滤或退回。请修复SPF，不要仅依赖DKIM。

典型的SaaS技术栈会使用多少次查询？ 我们普查中的p99 SPF记录已处于9次查询——在添加任何内容之前就已接近限制。Google Workspace记录增加3至4次查询；Mailchimp增加1至2次；HubSpot根据其当前配置增加1至3次。三个主流工具加上托管服务商的默认设置，往往足以突破10次。

SPF压平安全吗？ 只要保持更新就是安全的。压平将include:链转换为静态IP范围——如果供应商轮换其发件IP而您未重新压平，您将开始拒绝其邮件。大多数组织使用能监控IP变更的托管压平服务，而非手动维护。

我的SPF多年来一直如此——为何突然失败？ 因为您的供应商更新了他们的SPF记录，而非您的记录。每当SaaS平台添加新的发件IP范围或嵌套另一个include时，您这边无需任何变更，链路成本就会上升。10次查询限制是在消息接收时实时评估的，因此供应商周二上午的更改可能在周二下午就会破坏您的SPF。

修复SPF能提高邮件送达率吗？ 它消除了身份验证失败的一个来源，这是保持稳定送达的先决条件——尤其是自Google和Yahoo开始对批量发件人强制执行DMARC对齐以来更为重要。SPF本身不是全部：将其与DKIM和DMARC配合使用，实现完整的邮件身份验证。

免费检查您的SPF

如果您不确定SPF记录是否超过了查询限制——或者设置过于薄弱而无法保护您的域名——请运行免费检查。它会评估完整的解析链，并准确显示查询配额的消耗位置。

检查您的域名 → · 修复SPF → · SPF PermError报告 → · SPF配置错误报告 → · SPF采用成熟度模型 → · 修复DMARC → · 仅使用汇总数据。数据在欧盟境内存储和处理。