域名身份验证 · 2026 年 9 月 21 日

SPF 扁平化：解决 10 次查询上限问题

告别 DNS 查询过多导致的“permerror”。了解 SPF 扁平化的原理、10 次查询上限存在的原因，以及如何理顺 include 链以提升送达率。

10 次查询上限详解

当收件邮件服务器需要执行超过 10 次 DNS 查询才能解析您的 SPF 记录时，SPF（发件人策略框架）会以 permerror 失败。这是由嵌套的 include 语句造成的：如果您的记录 include 了某个服务商，而该服务商又 include 了另一项服务，每一步都会计入上限。要解决这一问题，您需要使用 SPF 扁平化，用一份静态的 IP 地址列表替代这些递归查询。

作为负责送达率的工程师，我发现这个问题最常出现在“供应商蔓延”的时候。公司一开始只用一家事务性邮件服务商，后来加了营销工具，又加了 CRM，SPF 记录突然就变成了纸牌屋。一旦触发第 11 次查询，收件服务器就会停止查找并返回永久性错误。这意味着您的邮件不只是被标记为垃圾邮件，还可能因为身份验证检查从根本上失败而被直接拒收。

查询上限的工作原理

根据 RFC 7208，设置这一上限是为了防止针对 DNS 基础设施的拒绝服务（DoS）攻击。如果没有上限，恶意攻击者可以构造循环引用或超长的 include 链，迫使收件服务器为一封邮件执行数百次查询。

哪些操作算作一次查询？

SPF 记录中并非每种机制都是“免费”的。以下机制会触发 DNS 查询：

include：最常见的罪魁祸首。它让服务器去查看另一个域名的 SPF 记录。
a：查询该域名的 A 记录。
mx：查询该域名的 MX 记录。
ptr：查询反向 DNS（该机制已被弃用，应避免使用）。
exists：查询某个特定域名是否存在。

ip4 和 ip6 这类机制不产生查询，因为 IP 地址已明确写在记录中。

查询链的构成

来看下面这条假设的 SPF 记录：

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendhq.cc ~all

表面上看只有 3 次查询。但如果 _spf.google.com 中还包含三条 include 语句，spf.protection.outlook.com 中包含四条，您就已经达到了 10 次查询。如果 SendHQ 的记录中也有一个 include，您就触及上限了。这就是所谓的“include 链”。

识别 permerror

如果您不确定是否已触及上限，可以使用 SendHQ 邮件 DNS 检查工具验证您的记录。在原始日志或邮件头分析工具中，您会看到类似下面的结果：

spf=permerror (too many DNS lookups)

这与 softfail（~all）或 fail（-all）不同。permerror 表示 SPF 检查无法完成。出现这种情况时，收件方无法验证发件方是否获得授权，这往往会导致邮件被丢弃，或被严格的过滤器标记。

什么是 SPF 扁平化？

SPF 扁平化是指将所有 include、a 和 mx 机制解析为一份扁平的 ip4 和 ip6 地址列表的过程。

示例：扁平化前后对比

扁平化前（递归）：

v=spf1 include:_spf.example.com include:_spf.vendor.com ~all

（假设 _spf.example.com 解析为 1.2.3.4，_spf.vendor.com 解析为 5.6.7.8）

扁平化后：

v=spf1 ip4:1.2.3.4 ip4:5.6.7.8 ~all

将记录转换为 IP 列表后，查询次数从 2 次（或更多）降为 0 次。收件服务器能直接看到这些 IP，无需进一步的 DNS 查询即可验证发件方。

扁平化的代价

扁平化是一种很有效的修复手段，但它会带来相当大的维护负担。

1. IP 过时问题

使用 include 语句时，您是把 IP 地址的管理委托给了服务商。如果 Amazon SES 或 SendGrid 为其基础设施新增了 IP 段，它们会更新自己的 SPF 记录，您的邮件就能照常发送。

如果您把这些记录扁平化到自己的 DNS 中，这些 IP 就由您来负责了。如果服务商更换了某个 IP，而您没有更新扁平化后的列表，您的邮件就会无法通过 SPF 身份验证。这正是手动扁平化对大批量事务性邮件来说十分危险的主要原因。

2. 记录长度限制

DNS 记录有最大长度限制。TXT 记录中的单个字符串最多 255 个字符。虽然可以拼接多个字符串，但一些较老的 DNS 解析程序难以处理很长的记录。如果您扁平化了太多服务商，SPF 记录可能会大到无法被正确处理。

如何修复 include 链

如果您触及了 10 次查询上限，请按照以下由最安全到最激进的顺序依次尝试解决方案。

第 1 步：审查并精简

检查记录中是否有遗留的服务商。很多团队仍保留着三年前就已停用的服务的 include 语句。请移除所有不再代表您发信的服务商。

第 2 步：为不同流量使用子域名

这是最专业的架构层面修复方案。与其把所有服务都放在根域名上，不如按功能拆分：

根域名（example.com）：企业邮箱（Google Workspace/Outlook）。
事务性邮件子域名（mail.example.com）：SendHQ 或 Amazon SES。
营销邮件子域名（news.example.com）：Mailchimp 或 Klaviyo。

每个子域名都有自己的 SPF 记录和自己的 10 次查询上限。这样可以隔离风险，避免某个营销工具复杂的 SPF 链破坏您关键的事务性邮件。

第 3 步：动态 SPF 扁平化

动态扁平化是一种服务，它实时监控各服务商的 include 链，并自动用当前的 IP 地址更新您的 DNS 记录。它通过 API 自动完成更新流程，从而解决“IP 过时”问题。

现代邮件投递中的 SPF

需要明白的是，SPF 只是身份验证拼图中的一块。要确保您的邮件被收件服务器接受，必须让 SPF 与 DKIM 和 DMARC 协同配合。您可以在 SendHQ 的 DKIM、SPF 和 DMARC 指南中找到这些关系的详细解析。

受理、投递与收件箱送达

作为工程师，我会区分以下三个阶段：

受理：收件服务器接受连接和邮件。SPF permerror 可能导致服务器在 SMTP 层就拒收邮件，也就是说邮件根本不会被受理。
投递：邮件被接受并放入用户的邮箱（或某个文件夹）。
收件箱送达：邮件进入主收件箱，而不是垃圾邮件文件夹。

SPF 扁平化解决的是受理问题，并不能保证收件箱送达。收件箱送达取决于发件人信誉、内容和互动指标。

AI 智能体的特殊注意事项

随着越来越多的 AI 智能体通过 API 发送邮件，SPF 问题的风险也在增加，因为智能体可能会跨多个域名触发大量邮件。在构建智能体工作流时，请把发送邮件视为一种外部副作用。

幂等与审批

在没有安全机制的情况下，智能体绝不应循环发送邮件。请使用幂等键，确保智能体中的重试逻辑不会把同一封事务性邮件给客户发送十次。此外，对于高风险邮件，请在调用 API 之前加入人工审批步骤。

发信服务商成本分析

在选择要加入 SPF 记录的服务商时，请考虑您发送量对应的成本。基于 2026 年 9 月的价格：

Amazon SES：按量计费为每 1,000 封邮件 0.10 USD（Amazon SES 价格）。50,000 封邮件约为 5 USD。2026 年 7 月 21 日推出的新分级套餐包括 Essentials（每 1,000 封 0.16 USD）、Pro（每 1,000 封 0.22 USD，另加 105 USD/月/区域）和 Enterprise（每 1,000 封 0.23 USD，另加 500 USD/月）。
Postmark：每月 15 USD、含 10,000 封邮件，超出部分每 1,000 封 1.80 至 1.20 USD（Postmark 价格）。在 Postmark 的套餐下，50,000 封邮件约需 66 USD。
Resend：免费额度为每月 3,000 封邮件（每天上限 100 封）。Pro 套餐为每月 20 USD、含 50,000 封邮件，超出部分每 1,000 封 0.90 USD（Resend 价格）。
Mailgun：每月 15 USD、含 10,000 封邮件，超出部分每 1,000 封 1.80 至 1.10 USD（Mailgun 价格）。
SendGrid：免费版现已改为 60 天试用，Essentials 起价为每月 19.95 USD（SendGrid 价格）。

SPF 故障排查清单

如果您怀疑遇到了查询上限问题，请逐项检查以下清单：

对根域名和所有发信子域名运行 DNS 检查。
统计 include、a、mx 和 exists 机制的总数。
跟踪每个服务商的 include 链，查看是否有嵌套查询。
识别并移除未使用的服务商。
评估是否可将流量迁移到专用子域名（例如 notifications.example.com）。
如果仍超出上限，请实施动态 SPF 扁平化。
验证最终记录每个字符串均未超过 255 个字符上限。

汇总表：SPF 机制

机制 | 是否产生 DNS 查询？ | 风险 | 建议

ip4 / ip6 | 否 | 低 | 用于静态 IP

include | 是 | 高 | 谨慎使用，监控查询链

a | 是 | 中 | 尽量避免，改用 ip4

mx | 是 | 中 | 尽量避免

ptr | 是 | 高 | 不要使用（已弃用）

主动管理 SPF 记录，您就能避免 permerror，它会在邮件抵达垃圾邮件过滤器之前就毁掉送达率。无论您使用的是简单的 API 还是复杂的智能体系统，保持 DNS 精简都是确保事务性邮件被受理的最佳方式。

如需一整套管理域名身份验证的工具，请访问 https://sendhq.cc。