SPF 记录配置是接收邮件服务器可能执行的身份验证之一，并不一定是第一项或唯一一项检查。配置错误可能导致拒收，但 SMTP 错误 550 5.7.26 本身不能证明原因就是 SPF。自 2024 年二月起，Google 和 Yahoo 的身份验证要求开始实施，具体适用范围取决于发送量、接收服务等条件。
常见问题包括记录重复、超过 10 个会触发 DNS 查询的条款，以及结尾限定符选择不当。这些问题可能影响投递，甚至数天未被发现，而退信内容未必能明确解释原因。
本指南介绍 SPF 配置的完整流程：语法、TrekMail 的 Managed SMTP 和 BYO 场景示例、DNS 发布，以及命令行验证。如果尚未配置域名邮箱，请先阅读在自己的域名上设置邮箱，再回来补充身份验证。
SPF 的作用
SPF（Sender Policy Framework，发件人策略框架）通过 DNS TXT 记录公布哪些服务器获准代表域名发信。接收服务器可以将发送 IP 与这项策略进行比对。未匹配时的 SPF 结果由限定符决定，是否拒收则由接收方决定。根据 RFC 7208，SPF 检查的是 MAIL FROM 身份，也就是信封发件人，而不是收件人看到的 From 标头。
没有 SPF，接收方就缺少这份针对信封发件人的授权声明，但仍可利用其他验证方式识别伪造。适用时 SPF 也会检查 HELO 身份；未发布策略并不强制接收方拒收。一般 DMARC 检查只需 SPF 成功或 DKIM 签名有效，且相应域名与可见 From 对齐。SPF 不能阻止所有地址冒用，也不保证邮件进入收件箱。
一个名称只能有一条 SPF 记录
同一个 DNS 名称只能发布一条 SPF TXT 资源记录。两条以 v=spf1 开头的独立资源记录会造成 PermError；同一资源记录内的多段带引号字符串则会拼接为一个值。接收方可能因 PermError 拒收，但不意味着所有邮件必然被拒。更换提供商或增加营销工具时，应留意重复记录。
| 错误：两条独立记录 | 正确：一条合并记录 |
|---|---|
v=spf1 include:spf.trekmail.net -allv=spf1 include:_spf.google.com -all |
v=spf1 include:spf.trekmail.net include:_spf.google.com -all |
应编辑现有 SPF 记录，合并仍然需要的授权内容。不要在替代记录准备好之前先删除旧记录，以免已发布的策略出现空档。
步骤 1：列出所有使用域名发信的服务
修改 DNS 之前，先列出所有以 @yourdomain.com 发信的服务。如果遗漏的服务以您的域名作为 MAIL FROM，发布 -all 后，其邮件可能得到 SPF Fail 结果。五分钟盘点只是规划示例，并非固定耗时；认真核查可能省去数小时的后续诊断。最终是否退信取决于接收方的策略。
常见发信服务包括：
- 企业邮箱：TrekMail、Google Workspace、Microsoft 365
- 事务邮件：Amazon SES、SendGrid、Mailgun、Postmark
- 营销邮件：Mailchimp、HubSpot、Klaviyo、Brevo
- SaaS 工具：Zendesk、Freshdesk、Shopify、Intercom
有些服务使用自己的 Return-Path 域名，例如 bounce.mailchimp.com，这种情况下通常不需要写入您域名的 SPF。另一些服务为了实现 DMARC 对齐，会使用您域名下的信封发件人。请查看服务商文档和账户的实际设置，再决定是否纳入。
步骤 2：构建 SPF 记录
SPF 是一条 DNS TXT 资源记录，必要时其中的字符串会拼接起来。基本格式相同，机制则根据实际发信路径选择。下列地址段用于文档示例，并非真实发信服务器地址。各部分的作用如下：
| 组成部分 | 示例 | 作用 |
|---|---|---|
| 版本 | v=spf1 | 必需。所有 SPF 记录都以此开头。 |
| include | include:domain.com | 评估服务商发布的 SPF 策略，计入 10 个触发 DNS 查询条款的限制。 |
| ip4 | ip4:203.0.113.0/24 | 直接授权 IPv4 地址或 CIDR 网段，无需 DNS 查询。 |
| ip6 | ip6:2001:db8::/32 | 对 IPv6 提供相同的直接授权。 |
| -all | -all | 未匹配的发件人得到 Fail。是否拒收由接收方决定。 |
| ~all | ~all | 未匹配的发件人得到 SoftFail。可用于过渡阶段，但不保证邮件被接受。 |
步骤 3：按服务商配置 SPF
选择与您的架构相符的场景。以下均为示例，发布前应核对服务商最新文档和账户设置。使用多个服务商时，将 include 机制合并到同一条记录中。
场景 A：TrekMail Managed SMTP（Starter 和 Agency 套餐）
如果您当前的 TrekMail 套餐提供 Managed SMTP，而且只有这项服务使用该信封域名发信，记录可以采用以下形式：
v=spf1 include:spf.trekmail.net -all这会引用 TrekMail 公布的发信策略。其他发信服务仍需一并考虑。
场景 B：TrekMail BYO SMTP（免费套餐或自定义配置）
如果用 TrekMail 收信，但连接自己的 SMTP 服务商发送邮件，应按该服务商文档进行授权。关键是最后一跳发信服务器的 IP，以及实际使用的信封发件人域名。
# Amazon SES
v=spf1 include:amazonses.com -all
# SendGrid
v=spf1 include:sendgrid.net -all场景 C：Google Workspace
v=spf1 include:_spf.google.com -all场景 D：Microsoft 365
v=spf1 include:spf.protection.outlook.com -all场景 E：TrekMail 与营销平台混合使用
团队邮箱用 TrekMail，营销活动用 HubSpot？如果两者都使用同一个信封域名，应将授权合并为一条记录：
v=spf1 include:spf.trekmail.net include:456789.spf05.hubspotemail.net -allHubSpot 的 include 值与您的门户账户相关。请从 HubSpot 的 DNS 设置页面获取，不要直接复制示例中的编号。
步骤 4：发布到 DNS
在域名的 DNS 服务商处将策略发布为 TXT 记录。服务商可能是 Cloudflare、Namecheap、GoDaddy、Route 53 或其他平台。
- 类型：TXT
- 主机名/名称：
@（有些服务商要求留空） - 值：完整的 SPF 字符串，例如
v=spf1 include:spf.trekmail.net -all - TTL：3600（1 小时）
已有 SPF 记录时，应更新该记录，而不是另加一条。保留仍需使用的授权，避免提前删除造成策略空档。修改后确认只有一条 SPF 记录。
步骤 5：验证 SPF 记录
用命令行检查发布结果。这些命令显示所用 DNS 解析器的回答，而解析器也可能返回缓存数据。命令行查询和 TTL 都不能绕过所有 DNS 缓存。
# Mac, Linux, or Windows PowerShell
nslookup -q=txt yourdomain.com
# Linux/Mac alternative
dig txt yourdomain.com +short重点检查三项：
- 只有一条 TXT 记录以
v=spf1开头 - 包含所有必需的
include机制 - 按选定策略，以
-all或~all结尾
先确认以 v=spf1 开头的是独立资源记录，还是同一记录显示出的多段字符串。确有重复时，合并需要保留的授权后再移除。还应检查递归评估及真实邮件：DNS 发布结果并不能证明 SPF 成功、DMARC 对齐或邮件进入收件箱。
排查常见 SPF 错误
以下三个问题有助于缩小排查范围。确定原因之前，还应查看完整 SMTP 回复和身份验证结果。
1. 10 次 DNS 查询限制（PermError）
SPF 将评估过程中会触发 DNS 查询的条款限制为 10 个，其中包括 include、a、mx、exists、ptr、redirect，以及递归评估中的相关条款。这个限制并不是简单统计所有 DNS 数据包。超过 10 个会产生 PermError，接收方可能因此拒收。
表现：验证工具返回 PermError 或“too many DNS lookups”。
处理办法：可将适合迁移的发信服务，如 Mailchimp、Zendesk，配置到 support.yourdomain.com 这样的子域名。子域名有独立的 10 个条款预算，但只有服务实际使用该子域名作为 MAIL FROM，并且子域名 SPF 配置正确，这才有帮助。这样可以简化主域名的策略。
2. Microsoft 个人邮箱（550 5.7.515）
看到 550 5.7.515 时，应阅读 Microsoft 的完整错误说明，不能直接断定 SPF 已正确或问题必然在 IP 信誉。向个人 Hotmail 或 Outlook.com 邮箱进行适用的大批量发信时，SPF 和 DKIM 必须同时成功，还须通过 DMARC，其中至少一项成功机制的域名与 From 对齐。即便如此，也不保证进入收件箱。配置说明见企业邮箱安全基础。
3. SoftFail（~all）与 HardFail（-all）
| 限定符 | 向接收方表达的含义 | 使用时机 |
|---|---|---|
~all（SoftFail） | 发件人可能未经授权；接收方自行决定如何处理。 | 例如配置过渡的前 2 至 4 周，仍在核查发信服务时。 |
-all（HardFail） | 发件人未经授权，但这不是强制拒收命令。 | 确认全部合法发信路径后，选择较严格策略时。 |
~all 返回 SoftFail，?all 则返回 Neutral，不表明发件人是否获准。应在所有合法发送路径得到确认后再切换到 -all。DKIM、DMARC 和接收方策略仍然重要。
使用 TrekMail 配置 SPF
管理 DNS 和排查 SMTP 错误会占用时间。如果当前 TrekMail 配置提供 SPF/DKIM/DMARC 向导，可以借助它设置 Managed SMTP 或 BYO。请核对向导给出的域名专用值。
为数十个客户域名管理邮箱的代理机构，更需要一致的配置流程。多域名控制面板可以帮助核查预期的 DNS 记录，但这类状态不衡量真实邮件的密码学验证、域名对齐或收件箱投递。有关流程，请阅读多域名邮箱托管和创建自定义域名邮箱。
原套餐概览列出的信息包括：Starter 每月 $3.50，含 Managed SMTP；Nano 无套餐费用，使用 BYO SMTP，不要求信用卡，也没有试用到期限制；付费套餐提供 14 天试用并要求信用卡。所述 Nano 模式的全部外发邮件，包括回复，都需要自备 SMTP；这并非有权使用 Managed SMTP 的付费套餐的共同要求。价格、可用性和条件可能变化，请以当前产品页面为准。体验 TrekMail。
完整 SPF 配置检查清单
完成前检查这七项。简单配置可能不到 15 分钟就能准备好，但 DNS 缓存和复杂发送路径可能需要更久。
- 已列出所有使用域名发信的服务
- 已确认现有 SPF 记录为零条或一条，而不是两条
- 已构建包含所有必要服务商的单一
v=spf1字符串 - 已在
@发布 TXT 记录，TTL 为 3600 - 已更新原记录而未造成发布空档，并在合并后删除重复记录
- 已使用
dig txt yourdomain.com +short验证 - 已确认只有一条以
v=spf1开头、以选定的-all结尾的记录
让 DNS 配置更省心。开始使用 TrekMail 发信。
