Cloudflare 上的 SPF 扁平化：宏、查询上限与更安全的模式

每次 SPF 评估最多允许 10 次 DNS 查询。这个上限平时完全不可见，直到你多加了一个 include，整条记录开始返回 permerror——接收方会把它当作"根本没有 SPF"。同时用着 CRM、营销、工单、账单外加 Google Workspace 或 Microsoft 365 的域名，几乎注定撞上这堵墙。

网上大量文章暗示在 Cloudflare 里点个开关就能解决。点不了。本指南讲清限制的真实含义、Cloudflare 能做什么不能做什么，以及真正安全的几种模式。协议基础见邮件认证总览，Cloudflare 的通用 DNS 配置见Cloudflare DNS 邮件认证指南。

10 次查询上限的真实含义

RFC 7208 第 4.6.4 节规定，SPF 评估中特定机制的 DNS 查询最多 10 次：include、a、mx、ptr、exists、redirect。几个最容易咬人的细节：

• 嵌套 include 每层都计数：单独一个 include:_spf.google.com 就要花掉约 4 次查询，因为它自身又引出 3 个 include。
• ip4 和 ip6 机制零查询——它们是记录里的字面量。
• 超限的后果不是"多余的 include 被忽略"，而是整条记录以 permerror 失败。
• 空查询（include 指向的域名返回 NXDOMAIN 或无记录）按双倍计数，失效的旧 include 比活着的更费额度。

用 SPF 检测看看现状——它按接收方的方式逐层展开 include 链并统计次数。这个数字才是有效的，自己数机制个数没有意义。

Cloudflare 不做的事

Cloudflare DNS 是一台符合标准的权威 DNS：原样存储、原样提供你的 TXT 记录。它不会把 include 改写成 IP 地址，面板里任何位置都不存在"SPF 扁平化"开关。任何声称如此的教程，要么在讲别的产品，要么干脆是错的。

顺手击碎两个相关迷思：

• SPF 宏不是扁平化。RFC 7208 的宏（如 exists: 机制里的 %{i}）由接收方在评估时展开。它是通配查询机制，不减少查询次数；用它绕限制既脆弱，又高度依赖接收方的实现细节。
• PowerDNS 式的做法搬不过来。自托管的权威 DNS 可以用自定义逻辑按查询动态返回展开后的记录。那是"自己运维的软件"才有的能力；Cloudflare DNS 没有等价功能，围绕它写的教程对托管在 Cloudflare 的域名不适用。

模式一：手动扁平化，睁大眼睛

所谓扁平化，就是把 include: 机制替换成它们当前解析出的字面 IP：

v=spf1 ip4:203.0.113.10 ip4:198.51.100.0/24 ip6:2001:db8::/32 ~all

零查询，天然免疫上限。但代价正是它危险的地方：服务商一调整发信 IP，记录就静默过期，正常邮件开始 SPF 失败，而没有任何人来提醒你。症状只会体现在送达率下滑和 DMARC 报告里——等你发现时，可能已经丢掉了几周的客户邮件。

选择手动扁平化，等于接受一份长期义务：至少每月用 SPF 检测重新解析每个来源；用 DMARC 报告分析器盯住被扁平化服务商的 SPF 失败；在运维手册里记下哪些 include 被扁平化、上次核对是什么时候。三条缺一条，这个方案就不成立。

模式二：用替你扁平化的服务

同一思路的更安全版本是专门的扁平化服务（多家 DMARC 厂商提供）：你把 include 指向他们的记录，他们那侧发布自动更新的 IP 列表，你自己的记录只消耗 1 次查询，盯梢来源的活由服务承担。评估时问两个问题：源变更多久被跟进；更新时效写进合同了吗，还是"尽力而为"。前者决定故障窗口，后者决定责任归属。

模式三：子域拆分——结构性安全的解法

很多时候最干净的答案不是扁平化，而是分区：别再把所有发件源堆在根记录上。把营销邮件挪到专用子域：

@ (根)         v=spf1 include:_spf.google.com ~all
news           v=spf1 include:mailgun.org ~all
billing        v=spf1 include:sendgrid.net ~all

每个子域有独立的 SPF 额度、独立的 DKIM selector，以及独立的 DMARC 记录——因为 DMARC 是按 From 域名评估的。根域保持精简、难以伪造；营销工具即使失陷，也污染不到根域名发出的交易邮件。这也是 ESP 和邮箱厂商本来就建议批量发信使用子域的原因。它唯一不适用的情况，是 From 地址必须字面等于 name@yourdomain.com；只要能接受 name@news.yourdomain.com，它就是最优解。

验证你的改动

• 每次改动后用 SPF 检测数一遍查询。
• 扁平化记录要定期做 TXT 查询，确认线上发布的确实是你以为的那条。
• 任何改动之后跑 邮件健康检查，再用邮件头分析器确认 SPF 端到端仍然通过。

常见错误

• 以为 Cloudflare 会扁平化 include。不会，这个设置根本不存在。
• 扁平化一次就撒手不管。记录只是某个时刻的 IP 快照，没有持续核对就是定时炸弹。
• 扁平化了 IP 轮换型服务商。来源发布庞大或动态 IP 集合的，保留 include，或者把该发件源挪去子域。
• 编辑时弄丢 ~all 或 -all。以裸 all 结尾会静默削弱策略，SPF 检测能标出来。

常见问题

我还剩几次查询额度？

把域名丢进 SPF 检测。它报告的是接收方实际会看到的次数，超过 10 说明 SPF 今天已经在失败了。

扁平化违反 RFC 吗？

不违反。纯 ip4/ip6 机制的记录完全合法。RFC 限制的是接收方执行多少次查询；它管不了的，是服务商改 IP 时没人通知你。

三种模式怎么选？

能用子域就先子域拆分——唯一结构性安全。做不到就用带更新承诺的扁平化服务。手动扁平化只在你真能长期坚持复查节奏时才选。