如果你需要为域名创建 SPF 记录，目标很简单：授权正确的发件服务，不要把 DNS 配置堆成半年后就会出问题的乱局。故障往往从同一个过程开始：先接入一个服务商，再加一个。随后 Microsoft 返回 550 5.7.515，Google 返回 550 5.7.26，你只能在晚上 11 点翻查 TXT 记录。
问题就在这里。SPF 看起来容易，直到根域名的记录变成各种服务的公共授权清单。递归 include 越积越多，再多评估一个会触发 DNS 查询的项，就可能出现 PermError。对于企业域名、客户邮件系统或多品牌环境，这不是小问题：收件方可能根据自己的策略拒收邮件。想先了解域名配置的整体思路，可以阅读小企业的商务邮箱。
这篇指南介绍一种更稳健的架构：企业日常邮件留在根域名，批量邮件和应用邮件按子域名拆分，并把查询预算当作有限资源。这样创建的 SPF 记录通常不必频繁整体重写，但仍需要定期检查和维护。
为什么很多 SPF 记录会出问题
SPF 评估限制的是会触发 DNS 查询的项数，而不是所有 DNS 数据包的总数。在同一个域名上叠加过多 include，检查可能超出限制并返回 PermError。即使语法看起来正确，收件方也可能根据其策略拒收；PermError 本身并不意味着一定拒收。
RFC 7208 对此有明确规定。触发 DNS 查询的项包括 include、a、mx、ptr、exists 和 redirect。收件方必须将评估时的总数，包括递归评估，限制在 10 以内。超出后得到的是永久错误，不是警告。同一主机名存在多条 SPF 记录也会导致 PermError，但与 SPF 无关的其他 TXT 记录可以共存。
这就是常见建议不够可靠的原因。一般教程让你把所有发件服务塞进 @ 下的同一个 TXT 值。表面上很整齐，实际上让根域名同时承载邮件简报、客服系统、应用通知、客户开发工具和员工邮箱的授权。某个服务商扩展 include 链，就可能影响整个根域名的 SPF 检查。
不理想的做法：用根域名的一条 SPF 记录，授权公司曾经使用过的所有工具。
Google 的发件人指南也强调正确认证和清晰的域名对齐，尤其是批量邮件。SPF 只是其中一环，但 SPF 出错往往是最先显现的问题。
真正的限制：10 项 DNS 查询预算
硬性规则是：SPF 评估最多使用 10 个触发 DNS 查询的项。预算按递归计算。如果评估某个 include 时还需要评估更多此类项，它们也计入总数。DNS 服务商再可靠，也无法弥补过度堆叠的 SPF 结构。
计入预算的项：
includeamxptr（不要使用）existsredirect
不计入预算的项：
ip4ip6all
无结果查询，也就是 void lookup，同样值得注意。RFC 7208 建议收件方把这类查询限制为两次。include 目标中的拼写错误可能消耗部分额度。错误引用在超过建议上限时可能引发另一种 PermError；仅仅达到上限并不等于超限。
| 机制 | 计入查询预算？ | 运维提示 |
|---|---|---|
include:spf.trekmail.net | 是 | 也要检查当前的递归链 |
include:vendor.example | 是 | 可能继续展开更多 include |
ip4:203.0.113.10 | 否 | 适合完全可控的静态发件地址 |
mx | 是 | 经常被过度使用或误解 |
ptr | 是 | SPF 不建议使用，应省略 |
-all | 否 | 明确规定未授权发件人的处理结果 |
如果一个域名通过四五家服务商发信，最好尽早核算预算。问题不在于 SPF 天生脆弱，而在于服务商的递归链可能给架构带来压力。
用分流架构创建 SPF 记录
稳健的做法是将日常人工邮件与批量邮件、应用邮件分开。主要邮箱服务使用根域名，营销、客服平台和应用发件服务使用子域名。不过，只有实际 MAIL FROM 或 Return-Path 使用对应子域名，才会拥有独立的 SPF 预算。仅修改用户看到的 From 地址并不能实现隔离。DMARC 仍需要对齐的 SPF 或 DKIM 认证，严格对齐和宽松对齐的要求也不同。
架构如下：
- 根域名
@用于日常人员之间的邮件。 - 邮件简报、客服、交易通知等专用邮件流使用子域名，并正确配置邮件信封域名。
- 每个主机名只保留一条 SPF 记录。删除重复和遗留 SPF 记录；无关的 TXT 记录可以保留。
TrekMail 托管发件的根域名记录示例，使用前应确认符合当前服务商要求：
v=spf1 include:spf.trekmail.net -all结构清晰：一个 include，一条明确策略。不过，仍需检查其递归评估和完整的实际发件人清单。
营销子域名示例：
v=spf1 include:servers.mcsv.net include:hubspot.com -all这些服务商值只是示例，不是通用配置。请查阅 Mailchimp 和 HubSpot 当前的官方指南，包括是否支持以及如何配置自定义 MAIL FROM。只有 SPF 实际针对 marketing.example.com 评估时，其预算才与 example.com 上的企业邮件预算分开。
| 旧做法 | 分流做法 |
|---|---|
| 根域名授权所有发件服务 | 根域名只授权主要邮箱的邮件流 |
| 一家服务商变更可能影响全部外发邮件 | SPF 故障可以局限于相应的信封子域名 |
| 所有服务共享查询预算 | 每个实际参与 SPF 检查的域名有自己的预算 |
| SPF 经常需要整体重写 | 架构更能适应服务商变更，但仍需检查 |
TrekMail 也可以融入这样的架构。其域名设置文档将 include:spf.trekmail.net 列为基础 include，DNS 检查工具可帮助发现冲突，但不能代替完整的发件人核查。如果你还在添加邮箱和配置 DNS，可以参考向 TrekMail 添加域名和检查 DNS 状态，以当前配置要求为准。
逐步创建 SPF 记录，不靠猜测
要让 SPF 便于维护，应先列出所有发件服务，再为每个服务分配合适的主机名，最后才创建 TXT 记录。不要从 DNS 界面开始，而应先明确谁负责什么邮件流，避免把不必要的 include 堆到根域名上。
按以下流程操作：
- 列出所有代表你的域名发信的服务。
- 把每个服务归类为企业邮件、交易邮件、客服或营销。
- 确定每个服务使用的主机名和实际 MAIL FROM 域名。
- 为该域名采用最精简且正确的 SPF 策略。
- 每个主机名发布一条 SPF TXT 记录，其他用途的 TXT 记录独立保留。
| 发件服务 | 邮件类型 | 主机名示例 |
|---|---|---|
| TrekMail | 企业邮件 | @ |
| Amazon SES | 应用通知 | alerts.example.com |
| Mailchimp | 邮件简报 | news.example.com |
| Zendesk | 客服工单 | support.example.com |
然后根据服务商官方要求和信封域名配置创建实际记录。
TrekMail 托管 SMTP 示例：
Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net -all
TTL: 3600Nano 套餐或混合环境中 TrekMail 加自备 SMTP 的组合示例，仅适用于确实需要同时授权这两条发件路径的情况：
Type: TXT
Host: @
Value: v=spf1 include:spf.trekmail.net include:amazonses.com -all
TTL: 3600自备 SMTP 时，应在对应信封域名上授权实际使用的 SMTP 服务商，而不是自动加入 TrekMail、Amazon SES 或其他人的 include。使用 SES 尤其要核对当前自定义 MAIL FROM 要求。本文所述 Nano 模式需要你自行提供外发 SMTP 服务。所引用的产品示例称，付费套餐从每月 $3.50 起并包含托管 SMTP，Nano 为长期免费套餐；付费套餐提供 14 天免费试用，需要信用卡。这些信息受当前套餐条款约束。配置说明见自备 SMTP（BYO）和TrekMail 托管 SMTP。
发布并验证记录
创建 SPF 文本后，将其作为 TXT 记录发布，并检查公共 DNS 返回的结果。不要只相信注册商界面、控制台缓存或某个工具的绿色标记。以下命令通常查询递归解析器，可能返回缓存结果，并不保证直接查询权威 DNS 服务器。确认只有一条有效 SPF 记录，同时考虑各处缓存的有效期。
Mac 或 Linux：
dig txt example.com +shortWindows：
nslookup -type=txt example.com你应看到一条以 v=spf1 开头的 SPF 值，而不是多条 SPF，也不是当前记录旁边还留着三年前迁移时忘记删除的记录。其他 TXT 记录本身不会构成 SPF 冲突。
快速检查：
- 以
v=spf1开头 - 在完成测试和完整发件人盘点后，以
-all结尾 - 只包含实际需要的发件服务
- 每个主机名只有一条 SPF 记录
迁移到新服务商时，旧 MX 和 SPF 记录经常一起遗留。TrekMail 的 DNS 文档提醒了这类冲突；应核对适用于本次迁移的具体步骤。若要进行更全面的平台迁移，可以参考如何创建自定义域名邮箱和多域名邮件托管。
常见 SPF 错误与快速处理
常见 SPF 故障主要来自查询预算超限、重复 SPF 记录、发件域名错误，以及 include 拼写错误。有清晰的发件服务映射，问题更容易发现；随意拼凑配置则会让排查迅速变得费时。
| 错误 | 常见含义 | 快速处理 |
|---|---|---|
| PermError | 查询预算超限、语法错误或存在多条 SPF 记录 | 保留一条正确 SPF 记录并缩减 include 链 |
| TempError | DNS 超时或临时查询失败 | 稍后重试，再检查 DNS 可用性 |
| 550 5.7.515 | Microsoft 拒绝了认证结果 | 检查 SPF、DKIM、DMARC 和域名对齐 |
| 550 5.7.26 | Google 拒收认证不足的邮件 | 修复 SPF 或 DKIM，并验证 DMARC 对齐 |
两条实用规则能减少很多麻烦：
- 完全可控且地址固定的发件服务可使用
ip4，它不消耗 SPF 的 DNS 触发项预算。 - 没有充分理由，就不要让营销平台与管理层邮件共用同一个信封域名。这里的隔离不能只靠可见 From 地址。
Google 的发件人文档明确了真正的目标：认证加域名对齐，而不是单独让 SPF 通过。即使 SPF 通过，如果认证域名与可见 From 域名不符合要求，邮件仍可能无法通过策略检查。DMARC 接受对齐的 SPF 或 DKIM，具体取决于所配置的严格或宽松模式。排查批量邮件投递问题时，可阅读Google 邮件发件人指南常见问题。
TrekMail 在哪些情况下可以简化配置
当你希望多个域名的 SPF 配置保持简洁时，TrekMail 可以作为一种选择。本文介绍的运营特点包括 TrekMail include、共享存储、非按用户计费、内置 IMAP 迁移，以及根据套餐和发件模式选择自备或托管 SMTP。功能是否可用、限制和设置方式以当前产品为准；单个 include 也需要检查递归链。
对独立创业者，这种方案可能更简单：让根域名邮件结构清晰，用 TrekMail 托管邮箱，避免按席位付费。对团队，统一配置有助于接入员工。代理机构和 MSP 可以在大量域名上复用同一架构，但每个域名和服务商要求仍需单独核查。
与其为每个客户搭建不同且脆弱的 SPF 组合，不如采用可重复的架构、统一控制台和经过验证的根域名 include。这改善的是运维模式，不只是 TXT 字符串，但也不代表无需维护。
本文引用的 Nano 示例提供 10 个域名、5GB 共享存储和自备 SMTP，无需信用卡。需要托管发件或更高限额时，文中列出的付费套餐从每月 $3.50 起，提供 14 天免费试用并要求信用卡。决定前请在TrekMail 价格页面核对当前功能、限额和条款。
总结：先设计 SPF 架构，再减少反复修改
要创建能长期使用的 SPF 记录，不要只想着根域名上的庞大许可清单，而应从架构入手：日常邮件使用根域名，专用邮件流使用正确的信封子域名，尽量少用 include，完整核查发件人后明确设置 -all，发布后检查 DNS。
这种做法有助于控制查询预算、减少意外故障，并简化服务商变更，但不能保证 SPF 永远不需维护。如果你正在重建邮件系统，可以了解TrekMail，判断当前方案是否适合业务增长。
