在 2026 年搭建邮件基础设施时，SPF 记录是重要的验证基础。错误可能影响收件箱投递，也可能导致拒收。不过，SPF 并非所有服务商决定送达的唯一条件，也不保证进入收件箱。
自 2024 年二月起，Google 和 Yahoo 对适用发件人实施更严格的验证要求。缺少有效 SPF 可能在特定收件规则下出现 SMTP 550，但不表示每封未通过 SPF 的邮件都会在传输结束前被拒收。
对只用一个域名的创始人，SPF 错误可能让投资人收不到演示材料。对管理 500 个客户域名的 MSP，它可能带来周一早晨大量“为什么不能发给 Gmail”的工单。正确配置与检查能降低风险，但不能避免所有送达问题。
本指南介绍 SPF 的作用、记录的构建方式、影响投递的隐蔽错误，以及如何有条理地管理多个域名的配置。
SPF 是什么，又不是什么
Sender Policy Framework (SPF)是基于 DNS 的授权协议，定义见RFC 7208。SPF 记录为被检查的域名公布允许的发送来源，收件服务器据此检查连接 IP。它不是通用安全防护，只完成特定的来源授权检查。
检查实际如何进行
Gmail 收到来自 alice@yourcompany.com 的邮件时，SPF 并不只看界面上的 From。通常检查 MAIL FROM 信封发件人的域名，该地址会体现在Return-Path中并用于退信处理；适当情形下会检查 HELO。收件方查询相应域名的 SPF，再判断连接 IP 是否匹配授权。
匹配允许规则时，检查可能通过。对于剩余来源，末尾规则可给出 SoftFail (~all) 或 Fail (-all)。这些是 SPF 结果，不直接命令所有收件方以同样方式接收、标记或拒收。
重要区别：From 头与 Return-Path
原文所说的 90% 并非已证实的新手总体统计，但可说明一种常见误解。SPF 不检查 Outlook 或 Apple Mail 中显示的 From，而是相应的技术信封域名。
容易忽略的情况：Mailchimp 发送简报时可能使用自有退信域名，例如 bounce-mc.us1.mailchimp.com。收件方因此查询的是 Mailchimp 的 SPF，而不是你可见 From 的域名。你的记录可能完全正确，却没有在这个发送路径上被调用。
这种对齐问题说明不能只看 SPF。SPF、DKIM 与 DMARC 的关系可参考邮件验证的配置顺序。
为什么仍需配置 SPF
即使使用 DKIM 和 DMARC，缺少 SPF 也可能违反适用发件要求。Microsoft 在对应批量发送场景中可能返回 550 5.7.515 Access Denied，但并非所有 Microsoft 收件服务都对缺少 SPF 作此处理。仍应检查 SPF 及其他要求。
基础方案：单一发送服务
小企业若主要通过 TrekMail、Google Workspace 或 Microsoft 365 发送，再加一个营销工具，目标应是为每个被检查的 DNS 名称维护清晰、单一的 SPF 策略。配置通常不复杂，但重复创建记录很常见。
基本规则：每个 DNS 名称只能发布一条 SPF 策略。
添加新服务时，不应把第二条 SPF TXT 记录与原有 SPF 并列发布，而应整合策略。检查发现同一名称有两条适用 SPF 时，会产生 PermError。这不是两条策略各自独立检查失败，而是无法选出唯一策略。
| 配置 | 记录 | 结果 |
|---|---|---|
| 错误：两条 SPF 记录 | v=spf1 include:_spf.google.com -allv=spf1 include:spf.trekmail.net -all |
SPF 求值产生 PermError |
| 合并示例，需验证来源和完整查询路径 | v=spf1 include:_spf.google.com include:spf.trekmail.net -all |
Pass |
记录的组成
| 组成项 | 示例 | 作用 |
|---|---|---|
| 版本 | v=spf1 |
必须在开头，用于识别 SPF 策略。 |
| Include | include:spf.trekmail.net |
求值目标域名的 SPF，只有目标得到 Pass 时机制才匹配；错误和其他结果也会影响处理。 |
| IP 机制 | ip4:192.0.2.1 |
直接授权某个地址，例如发送事务邮件的自有服务器。示例地址不可作为真实配置直接部署。 |
| 限定符 | -all |
为剩余来源设定结果：-all 给出 Fail，~all 给出 SoftFail。接收、标记或拒收由收件方决定。 |
以上代码用于说明结构，并不保证是当前可部署的服务商配置。先核查现行值、真实发送来源及预算，再参考SPF 配置指南逐步设置。
小企业如何评估 TrekMail
原文以每用户每月 $6-$18 比较 Google Workspace，并为十名用户列出每年 $720-$2,160。TrekMail Starter 列为每月 $3.50 固定费用及最多 100 用户。这些是历史价格与限额示例，应核查现行条件。include:spf.trekmail.net可能是适当记录的一部分，但不代替完整来源清单、DNS 发布与验证。许可模式和合同条款仍需按具体方案比较。
多个发送服务：代理商视角
MSP 或代理商的客户可能同时使用 HubSpot 做销售、Zendesk 做支持、Klaviyo 做营销、TrekMail 做日常企业邮件。并非每个工具都必须写进你的 SPF；这取决于实际信封域名及服务商配置。
应把必要授权纳入同一策略，同时遵守 RFC 的重要限制：10 个相关 DNS 查询项的预算。
10 个相关 DNS 查询项的上限
RFC 7208 §4.6.4限制实际求值路径中需要 DNS 查询的相关机制和修饰符，包含嵌套，总数不得超过 10。这并非简单统计全部 DNS 数据包。限制有助于减少滥用带来的查询负担，也可能影响复杂的合法配置。
会消耗预算： include:、a、mx、exists、redirect，前提是实际执行到这些项。旧的 ptr 机制也计入。
不消耗该预算： ip4:、ip6:、all。
嵌套 include 的问题
加入 include:bluehost.com 看起来只有 1 个查询项。但历史示例中，它可能再包含 spf.protection.outlook.com 和 mail.bluehost.com，使一个外层项触发三个相关求值。spf.protection.outlook.com 也可能继续嵌套。需检查当前真实值和实际执行路径，而非把该例当作现行配置。
相关项超过 10 时产生 PermError。合法邮件可能受影响，但并不必然无通知地被永久拒收。收件方可能给出 SMTP 诊断，处理也受本地规则与其他验证结果影响。
如何检查预算
不要猜测。使用适当的命令行工具或可解释的可视化工具。在 Mac/Linux 上可先执行：
dig +short txt yourdomain.com随后递归查询每个 include: 的目标，并检查其他相关项及实际路径。dig 只显示 TXT，不自行执行完整 SPF 验证。审计方式和常见超限见SPF 查询上限指南。
扁平化与子域名分流
当存在超过 10 个相关项的风险时，可考虑以下两种方式。代理商并不是必然会超限。
方案 1：需要持续维护的 SPF 扁平化
扁平化把 include: 链中的授权地址改为直接的 ip4:。ip4:消耗零个相关 DNS 查询项，因此数百个 IP 也可能不超出此预算。但仍需遵守记录大小和有效性限制，并考虑原策略语义及其他地址类型。
风险：HubSpot、Klaviyo 等 ESP 可能更换 IP。硬编码名单会过时，几个月后新地址可能缺失，旧地址可能仍被授权。曾经通过检查，不代表以后也正确。
采用扁平化应有可靠的源记录监控、受控 DNS 更新、错误处理与回退。自动脚本可帮助维护，但本身不能保证安全。没有持续维护，扁平化就会积累技术债务。
方案 2：按实际发送身份分配子域名
另一种方式是不把所有工具挤在根域名。SPF 检查的是实际信封域名，它体现在 Return-Path 中，也可以是子域名。
营销一定要使用 team@company.com，还是可以使用 news@marketing.company.com？只改显示 From 并不会更换 SPF 检查域名。
根域名 (company.com)：保留清晰的必要来源，例如企业邮件与关键基础设施。
v=spf1 include:spf.trekmail.net -all营销子域名 (marketing.company.com)：可为相关工具分别配置发送身份。
v=spf1 include:servers.mcsv.net include:hubspot.com -all只有实际使用独立信封身份和 SPF 策略时，才可能获得独立的 10 项预算。marketing.company.com不是信誉防火墙，收件方可能合并组织域名或共享 IP 的信誉，不能保证高管邮件不受影响。还应检查 relaxed 或 strict DMARC 对齐，并核查当前服务商值，不要照搬示例。
更多起点可参考SPF 配置模板。多服务发送的关系见多个发送来源的配置指南。
发布后的验证流程
在 DNS 编辑器点击保存并非完成配置。以下流程帮助检查记录是否公开，以及是否被实际发送路径正确使用。
1. 检查 DNS 可见性与缓存
DNS 更新不会同时出现在所有位置。TTL、已有缓存和服务商权限可能使其耗时几分钟或几小时。除本地与权威 DNS 外，也可查询公共解析器：
nslookup -type=txt yourdomain.com 8.8.8.88.8.8.8查询 Google 公共 DNS，绕过本地 ISP 解析器，但 Google 自己也有缓存。此处出现新值不能证明全球多数解析器或所有收件方均已更新。
2. 检查语法
SPF 对语法有明确要求。常见问题包括：
v=spf1前出现空格ip4: 192.1.1.1：冒号后的空格不合法- 多个
all：第一个已匹配，其后的机制在该路径不会执行 - 重复
include:：不一定构成语法错误，但实际执行时可能浪费预算
结束设置前运行语法检查。当前可用的DNS 配置向导可提供提示，但不能代替完整验证。
3. 检查空查询
RFC 7208 还建议限制空查询：最多2 次没有结果的 DNS 查询，包括 NXDOMAIN 或成功响应但无相应数据。实现可能允许配置该限制，还应区分具体错误类型。
例如 include:spf.trekmaill.net多了一个“l”，可能产生 1 次空查询。但 include 找不到有效 SPF 策略时也可能立即产生 PermError，不必等到空查询预算超限。两处拼写错误不等于必然超过推荐上限。
因此不仅要查语法，还要解析目标并理解结果。问题可以在出现退信之前发现，并非只能等邮件失败。
4. 检查实际邮件头
发往自己控制的 Gmail，打开三点菜单并选择“显示原始邮件”。查看可信收件系统添加的 Authentication-Results，而不是任意发件人提供的同名头。可能看到：
spf=pass (google.com: domain of user@yourdomain.com designates 192.0.2.1 as permitted sender)spf=neutral或spf=softfail应结合预期策略调查，未必意味着错误。比较连接 IP、验证域名与授权来源。检查 DNS 状态有助于核查 DNS，也需另行分析可信邮件头。
常见故障与错误
以下情况常见于 SPF 支持问题。了解它们能帮助排查，但不是经过验证的普遍故障占比。
1. 转发与 SPF
SPF 检查连接发送 IP，这也是其架构局限。
Alice 发给 Bob，Bob 再转发给 Charlie。Charlie 看到的是 Bob 服务器的 IP。若仍保留 Alice 的信封域名，而 Bob 的 IP 未被授权，SPF 就可能失败，即使原始邮件完全合法。
单靠 SPF 无法解决所有转发情况。DKIM 签署选定头部和邮件正文，若数据经过规范化后仍有效，且满足密钥等验证条件，署名可能在转发后保留。DMARC 还需要对齐。因此不要仅依赖 SPF。
DKIM 和 SRS 在转发中的作用见域名邮件转发与送达检查，它们也不保证所有路径成功。
2. ptr机制
在 2000 年代初，SPF 的反向 DNS 机制 ptr曾较常见：
v=spf1 ptr -all新配置不应使用它。RFC 不建议 ptr，因为查询负担与可靠性存在问题，但不表示 Gmail 必然惩罚或忽略整条记录。继承的 ptr应在核查来源、准备替代授权与测试后更换。SMTP 发送 IP 的 PTR 反向解析要求是另一项工作，不应混淆。
3. +all的风险
仍可见到这类问题记录：
v=spf1 include:spf.google.com +all各限定符表示：
-all= 对前面未匹配的来源给出 Fail，处理由收件方决定~all= 对剩余来源给出 SoftFail，不是强制接受并标记+all= 对所有剩余来源给出 Pass
若求值到达 +all，任意 IP 都获得该验证域名的授权。包含 +all的策略会削弱 SPF，可能便利滥用，但不是钓鱼送达保证。发现 +all应及时清点合法来源，并通过测试选用适当规则，例如 -all，而不是忽略正常发送流直接更改。
4. 第三方服务的 Return-Path 不对齐
未配置自有 Return-Path 时，营销服务常用供应商退信域名。Tracking 域名并不一定等于退信域名。此时你的 SPF 不会用于该信封验证；供应商 SPF 可通过，却可能不与显示 From 对齐。但只要另有有效且对齐的 DKIM，DMARC 仍可能通过。
若 ESP 支持 bounce.yourcompany.com这样的自有退信子域名，可按文档设置。Relaxed 可允许适当的组织域名相同，strict 要求完全一致。详见DMARC 对齐与域名信誉。
如何审慎使用生成器
SPF 生成器差别很大。有些让检查更直观，有些可能生成不适用的内容。
有用的工具
可视化工具能展示完整 include:链，帮助在超限前检查预算。适当的邮件送达工具可能提供该功能，但还要考虑其他相关项。
语法检查器可发现缺失冒号与不合法字符；空查询和目标策略等运行时问题还需独立解析 DNS 并执行相关检查。每次变更后使用，并结合实际发送验证。
需要谨慎的结果
一键向导可能输出 ?all，即 Neutral。它不为剩余来源提供正面授权信号，但也不自动说明配置错误。根据完整来源清单及接收要求选择 -all或暂时的~all等合适规则，不能盲目采用默认项。
分拆记录生成器：TXT 的单个字符串限制为 255 字节。长 SPF 应分为同一记录内的多个带引号字符串，而不是两条独立 SPF TXT：
- 预期分拆方式：
"v=spf1 include:a..." "include:b... -all"表示两个字符串、一条记录，实际内容需在边界保留分隔空格 - 错误：两条独立 SPF TXT 在验证时产生 PermError
字符串连接不会自动插入空格，所以以上缩略例子不能直接当成有效记录部署。检查任何生成器的实际发布内容和语法。
更多选择标准见SPF 生成器与配置指南。
用 TrekMail 统一配置
大型办公套件并非不好的产品，但捆绑功能和按用户收费未必适合每位客户。应按需要的服务与合同公平比较。
| 场景 | Google Workspace Business Starter | TrekMail Agency |
|---|---|---|
| 50 个客户域名，每个 5 用户 (250 邮箱) | ~$1,500+/月为历史示例，现行价格需核查 | 按当前 Agency 条件的固定套餐 |
| 各域名的 SPF 设置 | 按服务商指南逐域配置 | 合适的 include 可统一，但每个实际验证名称都需独立发布 |
| IP 信誉管理 | Google 管理其发送池，客户仍负责发送行为 | 适用托管 SMTP 中由 TrekMail 管理基础设施与 PTR，需核查实际路径 |
| 反馈回路与滥用处理 | Google 的基础设施措施不代替客户义务 | 依当前服务范围支持，并非接管全部义务或覆盖所有反馈 |
适当的 TrekMail 发送路径可考虑以下示例，但需验证现行值及其他来源：
v=spf1 include:spf.trekmail.net -all只有正确覆盖验证域名所需的全部发送来源，这条记录才完整。托管 SMTP 可按服务范围管理 IP、PTR 和可用反馈流程，BYO SMTP 的责任不同。发送许可、名单、量与监控仍需维护，授权不保证送达。
若 MSP 的 50 个客户域名配置确实相同，50 条相同 SPF 可便于管理。套餐和每位客户实际来源仍要检查。新域名可能使用此前输入过一百次的同一行，但标准化不等于无需单独验证。
迁移时可参考IMAP 迁移概览与必需 DNS 记录指南。IMAP 复制可访问的邮箱数据，不自动迁移 DNS、应用或信誉，也不保证无损与无中断。应先准备验证、测试和迁移检查，再切换 MX。面板批量导入的可用性和条件见批量添加域名。
可靠的 SPF 维护方式
2024 年邮件验证要求进一步加强。不合适的SPF 记录会增加合法发送风险。Google 和 Microsoft 按各自适用规则使用 SPF，不是所有邮件都受到相同的自动拒收。
要点如下：
- 立即审计。运行
dig +short txt yourdomain.com并统计同一名称的 SPF 策略，不是全部 TXT。多于一条 SPF 策略会在求值时产生 PermError。 - 合并授权。发布一条包含必要来源的 SPF TXT，同一记录内可有多个字符串。
- 检查预算。使用适当工具。超过 10 个相关项时，真实信封子域名可作为维护成本较高的扁平化的替代方案。
- 审慎选择
-all。离开~all前需清点来源、测试并决定政策。+all应及时调查修正。 - 检查 Return-Path 对齐。Mailchimp 或 HubSpot 的自有退信域名可能帮助 SPF 对齐，但 DMARC 也可仅凭有效对齐 DKIM 通过。
- 不止检查 SPF。转发可能影响 SPF，也可能修改 DKIM。应使用并验证全部三项：SPF、DKIM、DMARC。
示例中 50 字节的 SPF 不值得因可避免的配置错误失去客户。正确配置后可按年度示例周期检查，并在来源或服务商变更时重新审计，不能设置一次便永久不管。
有条理地维护 DNS。了解TrekMail 免费方案时，请核查当前条件、固定套餐及各域名 SPF、DKIM、DMARC 支持范围。
