SPF记录示例：适用于各种配置的模板

网上找到的每个 SPF 记录示例往往不是过度简化，就是塞满了几乎不会遇到的边缘情况。真正需要的是适用于三种基础设施配置的生产级模板，它们可以覆盖 95% 的域名。只需一条 TXT 记录，以 v=spf1 开头，以 -all 结尾。如果设置错误，Google 和 Microsoft 等接收方可能会拒收邮件，并返回 550 5.7.26 之类难以理解的 SMTP 错误。

以下是 SPF 记录示例模板。选择符合自身情况的示例，粘贴记录，然后继续处理真正需要关注的问题。

适用于各种发信配置的 SPF 记录模板

好的 SPF 记录示例应当匹配实际基础设施，而不是包含六种 SaaS 工具的假想配置。以下三种场景涵盖单一发信方域名、混合配置和复杂的多发信方体系。每个模板都可以作为 DNS TXT 记录发布在根域名上。

场景 1：单一发信方（由一家服务商处理全部邮件）

所有邮件都通过一个平台发送。这是最简洁的配置，也是值得采用的目标。

TrekMail（Starter、Pro 或 Agency 套餐）：

v=spf1 include:spf.trekmail.net -all

Google Workspace：

v=spf1 include:_spf.google.com -all

Microsoft 365：

v=spf1 include:spf.protection.outlook.com -all

一个 include，一个 -all，仅此而已。这里只使用了 1 次 DNS 查询，允许的上限是 10 次。

场景 2：混合发信方（邮箱 + 事务邮件服务）

主要邮箱服务商之外，还使用单独的事务邮件或营销服务。TrekMail Nano 套餐使用自带 SMTP，这种配置很常见；添加 Amazon SES 或 Mailchimp 等工具时也会采用这种方式。

TrekMail Free + Amazon SES：

v=spf1 include:amazonses.com -all

Google Workspace + Mailchimp：

v=spf1 include:_spf.google.com include:servers.mcsv.net -all

两个 include 即两次查询，此外还要计算服务商可能触发的嵌套查询，但通常仍在限制以内。

场景 3：多发信方体系（高风险）

这个 SPF 记录示例涵盖企业邮件、CRM、帮助台和 HR 平台，它们都在同一个域名上获得授权。问题通常出现在这里。

v=spf1 include:spf.trekmail.net include:hubspot.com include:mail.zendesk.com include:spf.bamboohr.com -all

表面上有四个 include，但每个 include 都可能包含嵌套查询。仅 HubSpot 就可能串联 3-4 次额外查询。如果整条查询链超过 10，接收方会返回 PermError，并将邮件视为未经身份验证。如果配置与此类似，请务必阅读下方的查询限制部分。

SPF 语法的工作方式

SPF 是 RFC 7208 定义的 DNS 白名单，用于告知接收服务器哪些 IP 地址可以代表您的域名发信。实际 SPF 记录中会遇到以下组成部分：

如需完整设置说明，包括验证工具和扁平化风险，请参阅SPF 记录设置指南。

10 次查询限制：多数 SPF 记录在这里出错

RFC 7208 将每次 SPF 评估的 DNS 查询限制为 10 次。该限制用于防止拒绝服务攻击，但也常成为企业发展过程中遇到的边界。

以下机制各消耗 1 次查询： include、a、mx、redirect、exists、ptr（已弃用，请勿使用）。

以下机制不消耗查询： ip4、ip6、all。

需要注意的是，查询具有递归性。添加 include:bluehost.com 会消耗 1 次查询。如果 Bluehost 自己的 SPF 记录包含 include:spf.protection.outlook.com，这次嵌套查询同样计入您的限制。将 3-4 家带嵌套 include 的服务商串联起来，很可能已经超过 10。

经常被忽略的空查询限制

RFC 7208 §11.1 还规定了次级限制：最多允许 2 次没有返回结果的 DNS 查询，也就是 NXDOMAIN 或空结果。把 include:spf.trekmaill.net 多写一个“l”会产生 1 次空查询。两处拼写错误就可能导致整条记录失败。

不使用扁平化也能解决查询超限

在采用 SPF 记录扁平化之前，可以先考虑更稳妥的替代方案。扁平化会把 include 解析为原始 IP，但 IP 可能在未通知的情况下发生变化，从而使扁平化记录过期。下面是两种更耐用的方法。

用子域名划分发信方

不要把每个工具都塞到根域名上。每个子域名都有独立的 10 次查询额度。

• 企业邮件： @company.com：只放 TrekMail、Google 等主要服务商
• 营销： @news.company.com：Mailchimp、HubSpot
• 支持： @support.company.com：Zendesk、Freshdesk

这种策略具有良好的扩展性。管理多个域名或客户账户时，子域名划分可以让每条 SPF 记录保持精简且便于审计。它还能隔离域名信誉，降低营销活动出现问题后波及事务邮件送达表现的风险。

用 IP 机制取代 DNS 查询

如果邮件服务器使用静态地址，可以直接写入 IP，而不使用 a 机制。

消耗 1 次查询：

v=spf1 a:mail.company.com -all

消耗 0 次查询：

v=spf1 ip4:192.0.2.55 -all

每用一个 ip4 或 ip6 替代方案，就能为必须使用 include 的 SaaS 工具腾出一次查询。

严重影响送达表现的 SPF 错误

错误 1：同一域名存在两条 SPF 记录

这是 SPF 记录示例中最常见的错误。同一域名不能发布两条以 v=spf1 开头的 TXT 记录，否则两条记录都会出现 PermError。

错误：

TXT: v=spf1 include:_spf.google.com -all
TXT: v=spf1 include:spf.trekmail.net -all

正确：

TXT: v=spf1 include:_spf.google.com include:spf.trekmail.net -all

请将它们合并，始终只保留一条记录。如需深入了解原因和完整示例，请参阅用于电子邮件的 SPF 记录。我们的SPF 记录设置指南介绍了从零开始的完整配置流程。

错误 2：使用 +all

切勿使用 +all。它表示允许全部来源，相当于告诉所有邮件服务器，任何人都能代表您的域名发信。请始终使用 -all（HardFail）。

错误 3：转发邮件只依赖 SPF

SPF 会根据信封发件人域名检查发信 IP。邮件被转发后，IP 会改变，但信封发件人不变，因此 SPF 会失败。

这正是 DKIM 存在的原因：它为邮件内容签名，签名可以在转发后保持有效。如果依赖邮件列表或邮件转发，仅有 SPF 并不够，还需要 DKIM，最好再配置接受其中任一验证方式的 DMARC 策略。转发方案的另一环是 Sender Rewriting Scheme（SRS），它重写信封发件人，让 SPF 可以在下一跳通过。

TrekMail 如何简化 SPF 管理

管理一个域名的 DNS 记录已经很繁琐，管理 50 或 100 个客户域名时，错误更容易累积。

TrekMail 的处理方式取决于套餐：

• Free（$0/mo，无需银行卡）：自带 SMTP。加入您自己服务商的 SPF 记录，保留完整控制权且无需费用。
• Starter（$3.50/mo）和 Pro（$10/mo）：托管 SMTP。加入 include:spf.trekmail.net，底层 IP 基础设施由 TrekMail 管理。服务器轮换时无需修改您的 DNS。
• Agency（.25/mo）：同样采用托管 SMTP，但面向多域名管理。可以在所有客户域名上应用标准 SPF 模板。仅使用一个 include，为客户的其他工具留下充足的查询额度。

所有付费套餐均提供 14 天免费试用，需要银行卡。内置的 SPF/DKIM/DMARC 向导会逐步引导 DNS 配置，并在投入生产前提示发现的错误。

SPF 检查清单

本指南中的每个 SPF 记录示例都遵循相同原则。去掉不必要的复杂性后，一条良好的记录并不难配置。请按以下顺序审查：

1. 统计查询次数。运行 dig TXT yourdomain.com 或使用在线 SPF 验证器。超过 10 次就已经无法通过。
2. 合并重复记录。一个域名只保留一条 v=spf1 记录。
3. 拆分查询负担重的发信方。将营销和支持工具移至子域名。
4. 将 a 机制换为 ip4，前提是服务器使用静态地址。
5. 以 -all 结尾。不要例外。

如果希望完全省去 DNS 编辑，TrekMail 免费套餐可以在没有前期费用的情况下提供可用的邮件系统。付费套餐会为您管理 SPF 基础设施。