只有一个发送方时，SPF 配置通常很简单。加入 Google Workspace、Mailchimp、Zendesk 和事务邮件 API 后，Microsoft 却可能返回 550 5.7.515。原本整洁的记录超过了 10 次查询上限，出站邮件的身份验证随之失败。
这正是陷阱所在。SPF 协议设有硬上限，不少团队在接入第三或第四项发信服务时就会触及。继续粘贴一个 include: 往往适得其反。语法基础请参阅邮件 SPF 记录指南。本文重点是架构：让多个发送方共存，并降低更换服务商时反复改写记录的风险。
为什么多个发送方会破坏 SPF 配置
RFC 7208 将每条 SPF 记录的 DNS 查询限制为 10 次。每个 include、a、mx、exists 和 redirect 都计入，而且会递归计算。服务商的 include 若再嵌套三项，也会占用预算。达到 11 次时，收件方可能返回 PermError 并拒收邮件。
常见过程都很相似：起初只有两个 include，余量充足；市场团队加入 HubSpot，客服加入 Freshdesk，工程团队用 SendGrid 发应用提醒。嵌套层级比预想更深，最终达到 12 次查询，Google 对每封邮件返回 550 5.7.26。
| 机制 | 占用查询？ | 运维提示 |
|---|---|---|
include: | 是（包括嵌套） | 服务商常用，但嵌套深度难预测 |
ip4: / ip6: | 否 | 静态自有发送方可优先使用 |
mx | 是 | 经常被滥用，可行时改用 ip4 |
a | 是 | 用于 SPF 效率较低，优先考虑 ip4 |
ptr | 是 | 已弃用，请勿使用 |
redirect | 是 | 将评估转移到另一域名的记录 |
-all / ~all | 否 | 策略终止符，应保留一个 |
计算并不复杂，只是在故障前很难察觉。因此，多发送方 SPF 应先设计架构，而不是复制粘贴。
添加内容前先审计 SPF 记录
第一步是清理不该存在的内容。许多域名还保留数月或数年前停用服务的 include，每一项都浪费查询预算。先清理，再搭建。
查看公开记录：
dig txt yourdomain.com +short逐项追踪 include 的嵌套深度：
dig txt _spf.google.com +short
dig txt spf.protection.outlook.com +short再与 DMARC 汇总报告交叉核对。如果某服务商的 IP 实际没有流量，对应 include 就是负担，可以移除。
审计时有三个快速改进：
- 将
mx换成实际 IP 的ip4:，节省一次查询。 - 移除已停用服务的 include。
- 检查重复 SPF 记录。同一域名存在两条以
v=spf1开头的 TXT 记录会立即导致 PermError。
这样通常能释放 2-3 次查询。详细步骤参阅 SPF 记录配置指南。
子域名分流：可扩展的 SPF 架构
要在多个发送方之间避免 10 次查询上限，可靠做法是按子域名分流。SPF 检查的是 Return-Path 域名，而不是可见的 From 标头。把非企业邮件迁至子域名后，每条邮件流都有独立的 10 次查询预算。
可采用以下模式：
根域名：仅供人工邮件
保持根域名简洁，只放主要邮箱服务商。
v=spf1 include:spf.trekmail.net -all一个 include，一次查询。市场团队新增工具时，不会因此破坏管理层邮件。
营销子域名：营销活动与简报
; news.example.com
v=spf1 include:spf.hubspot.com include:servers.mcsv.net -allHubSpot 和 Mailchimp 占用 news.example.com 的查询预算，而不是根域名。即使该子域名被限流，企业邮件仍可继续运行，但具体信誉关联取决于收件方。
客服子域名：工单系统
; help.example.com
v=spf1 include:mail.zendesk.com -all事务子域名：应用提醒与收据
; alerts.example.com
v=spf1 include:amazonses.com -allZendesk 以 support@help.example.com 发信时，收件方查询 help.example.com 的 DNS，而不会使用根域名的 SPF 记录。这就是分流的核心。
| 旧方式 | 新方式 |
|---|---|
| 所有发送方塞进一条根域名 SPF | 根域名只保留主要邮箱服务商 |
| 一个服务商变更可能影响所有邮件 | 故障局限在对应子域名 |
| 所有服务共享查询预算 | 每个子域名有独立的 10 次预算 |
| 每加一个工具就改写 SPF | 架构更能适应服务商变化 |
SPF 扁平化：最后手段
如果业务强制所有邮件都从裸域名发出，不能使用子域名，可以考虑 SPF 扁平化。它将服务商 include 解析成原始 IP，以不占查询次数的 ip4: 列出。虽然有效，却会增加维护负担。
主要风险是过期。SaaS 服务商会调整 IP。SendGrid 明天增加网段，而扁平记录仍是昨天的地址，SPF 就可能失败。除非每天检查，否则不要手动扁平化。应使用能监控服务商 IP 并定期更新 TXT 的动态 SPF 服务，同时评估其安全与变更控制。
扁平化是权宜之计，不是理想架构。优先采用子域名分流，确实没有其他选择时再使用。
验证 SPF 配置是否生效
每次修改后，都要查询公共 DNS 的实际返回值。不要只依赖注册商控制台、缓存页面或服务商界面的绿灯。直接查询域名，确认每个主机名仅有一条有效 SPF 记录。
# Check the root record
dig txt example.com +short
# Check a subdomain
dig txt news.example.com +short
# Verify DMARC while you're at it
dig txt _dmarc.example.com +short每个主机名应只有一条以 v=spf1 开头的 TXT 记录，不能有两条，也不能残留两年前迁移时的旧记录。
然后向 Gmail 发送测试邮件，打开三点菜单，选择“显示原始邮件”，查找：
SPF: PASS with IP [your sending IP]
DKIM: PASS
DMARC: PASSFAIL 或 SOFTFAIL 表示配置仍有问题，应在批量发送前修正。若还要排查 SPF 之外的信誉问题，请参阅邮件发送者信誉信号。
TrekMail 如何简化多域名 SPF
一个域名的 SPF 已经麻烦，50 个客户域名更耗时间，因为服务商、DNS 平台和历史问题各不相同。TrekMail 尽量保持 SPF 占用简单且可预测，为其他发送方留出空间。
核心是 include:spf.trekmail.net，占一次查询，不包含嵌套 redirect 或难以预测的扩展链。相比之下，Microsoft 365 可能因内部重定向占用 2-3 次，Google Workspace 也可能因区域而异。实际情况应通过 DNS 查询验证。
个人创始人加入营销工具后仍能保持简单；团队可减少入驻时的 DNS 错误；代理商则能复用模板：加入 TrekMail include，把其他服务商分配到子域名。这样可显著降低触顶风险，但仍需持续审计。管理多个品牌时，请阅读多域名邮件托管。
TrekMail 的 DNS 状态检查器还会在控制台提示 SPF 冲突，帮助用户在生产故障前发现问题。完整配置参阅文档中的必要 DNS 记录。
结语：一次设计好 SPF 架构
良好的 SPF 配置始于架构，而不是语法。清理失效 include，按子域名拆分发送方，让每条邮件流拥有 10 次查询预算。根域名只保留一个邮箱服务商、一个 include 和一个 -all。使用 dig 验证，不要只看控制台。
无论管理一个还是一百个域名，TrekMail 都提供固定价格的多域名托管、简洁的 SPF include、共享存储和 DNS 检查器。按当前说明，Nano 支持 10 个域名和自带 SMTP，无需银行卡并可长期免费；Starter 的付费方案从$3.50/mo 起，包含托管 SMTP 和 14 天试用，需银行卡。价格与条件可能变化，请在 trekmail.net/pricing 查看当前方案。
