你找到了一款免费的SPF 记录生成器，勾选了所有选项，包括 Google Workspace、Mailchimp 和你的 CRM，然后把生成结果直接粘贴到 DNS 中。两周后，Gmail 可能会以 550 5.7.26 拒收你的发票邮件，Outlook 可能返回 550 5.7.515，支持队列也随之堆满。
SPF 记录生成器给出的是语法有效的内容，却不代表这条记录能正常工作。这个差距往往会影响邮件送达率。如果你还在配置完整的 DNS 体系，可以先阅读为域名设置电子邮件，因为 SPF 只是 MX、DKIM 和 DMARC 整体配置的一部分。
本指南将说明自动生成器为何可能在生产环境中失效、如何用现有工具在五分钟内审核输出，以及可用于生产环境的 SPF 记录通常是什么样子。
SPF 记录生成器实际做了什么
SPF 记录生成器是一种网页工具，它会根据你勾选的服务商，将各服务商的 include: 机制拼接成一条 TXT DNS 记录。选择发件服务后即可得到字符串。它通常不会查询你的实时 DNS，也不会统计递归查询，更不知道你的域名已有多少条 SPF 记录。
许多免费的 SPF 记录生成器本质上只是字符串拼接工具，它们能生成看起来正确的内容，却不会验证该内容是否适用于你的实际 DNS 环境。语法正确并不等于运行正常。
SPF 记录生成器容易遗漏的 3 种故障
生产环境中常见的 SPF 严重故障通常源于以下三类问题。标准 SPF 记录生成器往往无法发现它们，因为生成器既无权访问你的实时 DNS 数据，也不具备收件服务器在评估时实际采用的查询计数逻辑。
1. 双记录导致的 PermError
一个域名应当只有一条 SPF 记录。RFC 7208 明确规定，如果收件服务器发现两条以 v=spf1 开头的 TXT 记录，就会返回 PermError，也就是永久性错误。Gmail 和 Yahoo 可能会将 PermError 按未配置 SPF 的情况处理，邮件可能被退回或悄然进入垃圾邮件箱。
生成器通常不会检查现有记录。如果域名已经使用了几个月，很可能已有一条记录，可能来自域名注册商、之前的托管服务商，或三年前配置 Google Workspace 的人员。未经检查便发布生成器结果会造成重复记录，从而破坏原本可用的配置。
2. 递归查询次数限制
RFC 7208 将 SPF 评估限制为 10 次 DNS 查询。计数包括每个 include:、a、mx、exists 和 redirect，还包括这些 include 触发的每一次嵌套查询。SPF 记录生成器只会统计你选择的机制，通常不会计算其中嵌套的内容。
| 所选服务商 | 生成器计数 | 实际查询次数 |
|---|---|---|
| Google Workspace | 1 | 4（嵌套 _netblocks.google.com 等） |
| Zendesk | 1 | 2-3 |
| Mailchimp | 1 | 2 |
| Salesforce | 1 | 2-3 |
| 总计 | 4 | 10-12 → PermError |
生成器显示 4 次查询，但收件服务器执行到第 #11 次时可能会中止评估，使该域名的邮件无法通过 SPF。界面中可能没有警告，也不一定会收到退信通知，问题有时要等客户反馈后才会暴露。
3. 无结果查询限制（RFC 7208 §11.1）
还有一项次级限制：返回空结果（NXDOMAIN）的 DNS 查询不得超过 2 次。include: 中的一个拼写错误就会产生一次无结果查询。出现两个此类错误时，整条 SPF 记录可能失效，即使生成器的语法检查已经通过。
示例：
include:spf.trekmaill.net（多了一个“l”）。它在语法上有效，SPF 记录生成器可能会将其标记为正确。收件服务器执行查询后找不到结果，这就是无结果查询 #1。再出现一个错误的 include，整条记录便可能失效。
部署前如何审核 SPF 记录生成器的输出
发布 SPF 记录生成器提供的任何内容前，请针对实时 DNS 执行以下三项检查。通常只需五分钟，便可发现生成器容易遗漏的关键问题，包括重复记录、查询层级过深和语法错误。相关命令适用于 macOS、Linux 和 Windows 命令提示符。
步骤 1：检查现有记录
更改任何 DNS 配置前，请运行：
nslookup -type=txt yourdomain.com如果看到两行以 v=spf1 开头的内容，就存在重复记录。发布任何新内容前，应先手动将它们合并成一条记录。
# Broken - two records, PermError guaranteed:
"v=spf1 include:_spf.google.com -all"
"v=spf1 include:spf.trekmail.net -all"
# Fixed - merged into one:
v=spf1 include:_spf.google.com include:spf.trekmail.net -all步骤 2：统计递归查询
对记录中的每个 include: 查询其内容：
dig +short txt _spf.google.com输出：
"v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"仅这一项 include:_spf.google.com 就会触发 4 次实际查询。对记录中的每个服务商重复此操作并计算总数。如果总数超过 10，就需要调整结构，常见做法是把事务邮件移至子域名（send.yourdomain.com），并为其配置更短的独立记录。
步骤 3：审核各项机制
按照下表检查 SPF 记录生成器产生的字符串：
| 机制 | 状态 | 处理方式 |
|---|---|---|
ptr | 已弃用 | 删除。RFC 7208 明确不建议使用，该机制速度较慢且可靠性不足。 |
+all | 不安全 | 删除。它会授权互联网上的任何来源以你的域名发送邮件。 |
ip4: 1.2.3.4 | 语法无效 | 删除空格，必须写成 ip4:1.2.3.4。 |
?all | 较弱 | 避免使用。中性策略无法提供有效的仿冒防护。 |
~all | 可接受 | SoftFail。可在迁移期间使用，不建议作为永久设置。 |
-all | 适用 | HardFail。未获授权的发件来源可能被拒绝，生产环境中通常使用此设置。 |
SPF 语法检查清单
无论初稿来自 SPF 记录生成器还是手动编写，都应在修改 DNS 前完成以下检查。这些项目涵盖生成器可能无法发现的故障，包括重复记录、递归查询限制和不安全的策略标记。
- 每个域名一条记录。如有重复，请先合并，不要发布两条记录。
- 以
v=spf1开头。不要使用变体，字符串应准确无误。 - 以
-all或~all结尾。不要使用+all或?all。 - IP 写在 include 之前。
ip4:和ip6:机制不消耗 DNS 查询次数，把它们列在前面有助于加快评估。 - 不要自我引用。
include:yourdomain.com会形成无限循环，应将其删除。 - 不要手动展开 IP，除非有自动化机制持续更新。若 Google 轮换 IP 而记录没有同步更新，邮件可能在没有明显提示的情况下发生故障。
- 查询总数 ≤ 10。计算所有查询，包括嵌套 include。
一条可用于生产环境的记录示例：
v=spf1 ip4:192.0.2.1 include:spf.trekmail.net include:_spf.google.com -allIP 在前（不消耗查询次数），include 在后，末尾使用硬失败机制，结构就是这样。
为什么代理机构和中小企业不再只依赖 SPF 记录生成器
对于只有一个域名和一两个发件来源的场景，SPF 记录生成器通常可以满足起步需求。一旦规模扩大，例如代理机构管理数十个客户，或中小企业使用完整的 SaaS 工具栈，它就可能成为反复出现的运营风险，因为缺少对整个域名组合中查询次数和重复记录的集中视图。
传统做法是为每个客户单独创建 SPF 记录，每次使用不同的生成器会话，也没有审核记录。某个域名达到查询上限后，可能过了三天才有人发现，客户的送达信誉也可能因此受损。
如需从企业层面全面了解如何保护邮件基础设施，请参阅企业邮件安全指南，其中介绍了 SPF 之外的完整基础配置。
TrekMail 如何减少 SPF 生成器带来的问题
SPF 的复杂性主要来自管理多个第三方发件来源，同时还要保持在 10 次查询上限以内。对于主要邮件基础设施，TrekMail 可帮助减少这两方面的复杂性，因此核心发信域名通常不必反复运行 SPF 记录生成器、统计嵌套查询或审核各种机制。
面向中小企业：一个 Include，简化维护
使用 TrekMail Starter 套餐（$3.50/月）时，出站投递通过 TrekMail 的托管 SMTP 运行。你的 SPF 记录可以简化为一行：
v=spf1 include:spf.trekmail.net -allTrekMail 在该 include 后端管理 IP 轮换和发件信誉，因此通常无需频繁修改记录，也不必再次运行 SPF 记录生成器。六个月后新增 SaaS 工具时，仍应根据实际发件配置确认是否需要重新审核查询。
面向代理机构：一个模板，适用于各客户
传统做法是：100 个客户，通过 100 次不同的生成器操作建立 100 条 SPF 记录，每条记录都有各自的递归查询风险，其中任何一条都可能在没有及时警报的情况下失效。
TrekMail 的做法是：在各客户域名中使用同一个模板：
v=spf1 include:spf.trekmail.net -all使用 Agency 套餐（$23.25/月）时，你可以从一个控制面板管理 1,000+ 个域名。将 TrekMail 标准化用于企业邮件，有助于减少核心通信渠道中的递归查询问题。如果你正在扩展多域名配置，请了解多域名邮件托管如何改变管理方式。
关于 TrekMail 除 SPF 外还需要的完整 DNS 配置，包括 MX、DKIM 和 DMARC，请参阅必需的 DNS 记录文档，其中集中介绍了全部四类记录。
SPF 记录生成器常见问题
首次使用 SPF 记录生成器后，如果得到的记录无法正常工作，通常会出现以下问题。它们都与语法验证和运行验证之间的差异有关：前者是生成器检查的内容，后者则需要检查实时 DNS。
可以用两个生成器交叉核对输出吗？
可以，但运行第二个 SPF 记录生成器并不能解决核心问题。两个工具可能给出两个不同的字符串，而且都不一定能发现实时 DNS 中的重复记录，也未必能准确统计递归查询。上文的命令行步骤通常是更可靠的检查方式。
生成器显示记录有效，为什么邮件仍被退回？
在 SPF 记录生成器中，“有效”通常只表示语法正确，并不表示该记录能在你的环境中正常工作。造成这种差异的两个常见原因是：重复记录触发 PermError，或递归查询次数超过 10。两者都需要检查实时 DNS，仅靠界面验证无法确认。
什么时候使用 -all，什么时候使用 ~all？
生产环境通常使用 -all（HardFail），未获授权的发件来源可能被直接拒绝。只有在迁移期间尚未确认已列出每个发件来源时，才考虑使用 ~all（SoftFail）。它应当是一种临时状态，而不是最终配置。若 SPF 记录生成器默认使用 ?all 或 +all，它往往更侧重于让配置看似可用，而不是提供合适的送达策略。
简要总结
免费的 SPF 记录生成器可以作为起草字符串的合理起点，却不适合直接作为生产配置的终点。它容易遗漏的三类故障，包括重复记录、递归查询超限和无结果查询错误，可能造成不易察觉的退信和 PermError，而且排查往往需要较长时间。
解决方法通常不是换一个更好的 SPF 记录生成器，而是花五分钟完成命令行审核：检查重复记录、统计嵌套查询，并检查各项机制，然后再发布。
如果希望跳过生成器流程，TrekMail 可以将出站发信整合到一个 include: 中。DNS 中只需一行核心配置，也能减少查询计算和 PermError 排查工作。
开始 14 天免费试用，需要信用卡，可随时取消。
