邮件送达率优化指南：SPF、DKIM、DMARC 配置与收件箱投放实践

应用程序返回「发送成功」，只说明邮件被交给了发信服务器，并不代表它会出现在收件人的收件箱里。密码重置链接、账号验证码、支付确认这类邮件一旦落进垃圾邮件文件夹，用户就会认为产品坏了。邮件送达率（email deliverability）要解决的正是这个问题：它关心的不是「有没有发出去」，而是「收件方愿不愿意把它放进收件箱」。

收件方判断一封邮件是否可信，看的不只是内容。它会综合评估发件人是谁、通过什么方式发送、历史上收件人如何回应。这套评估由发件人声誉、邮件身份认证和基于机器学习的垃圾邮件过滤共同完成。本教程面向需要自己搭建或排查事务性邮件通道的开发者，讲清这些机制在做什么，以及可以采取哪些具体动作。需要说明的是，各家邮件服务商的过滤策略、配额与后台功能会持续调整，本文涉及的具体数值与功能请以各服务商官网当前信息为准。

准备工作

在动手改配置之前，先把下面这些条件确认清楚。缺少任何一项，后面的排查都会失去参照。

• 一个用于发信的域名。建议使用专门用于发信的子域名（例如 mail.example.com 或 em.example.com），而不是主站域名。这样发信声誉的波动不会直接牵连主域名的其他用途。
• 域名 DNS 的编辑权限。SPF、DKIM、DMARC 全部以 DNS 记录的形式发布，没有 DNS 管理权限就无法完成配置。
• 邮件服务商提供的认证参数。SPF 的 include 目标、DKIM 的公钥与选择器（selector）名称，都由邮件服务商生成，不能自己编造。
• 可接收测试邮件的多个邮箱。至少覆盖 Gmail、Outlook、Yahoo 三类，用于对比同一封邮件在不同服务商处的投放结果。
• 一个能查看邮件原始头部的收件邮箱。认证结果（SPF/DKIM/DMARC 的 pass 或 fail）会写在邮件头部，这是判断配置是否生效最直接的依据。
• 发信日志与退信处理入口。应用侧需要能记录每封邮件的发送结果，并能接收和解析退信通知。

如果使用的是第三方邮件发送服务，上述 SPF 与 DKIM 参数通常可以在其控制台的域名验证页面找到；如果自建邮件服务器，则需要自行生成 DKIM 密钥对并管理私钥。

操作步骤

第一步：发布 SPF 记录

SPF（Sender Policy Framework）的作用是告诉收信服务器：哪些服务器有权代表你的域名发信。它以 DNS TXT 记录的形式发布，一个域名只能有一条 SPF 记录。

一条简化后的记录形如：

v=spf1 include:_spf.example.com ~all

各部分含义如下：

• v=spf1 声明这是 SPF 记录，且版本为 1。
• include:_spf.example.com 表示把该域名下的 SPF 策略一并纳入授权范围，通常指向邮件服务商给出的地址。
• ~all 表示对不在授权列表内的发信源采取「软失败」处理，即标记但通常不直接拒收。也有使用 -all（硬失败）的写法，具体选哪种取决于你的发信结构。

不要直接照抄上面的示例值。 include 的目标必须换成你的邮件服务商实际提供的地址，否则这条记录等于没有授权任何正确的发信源。如果同时使用多个发信服务，需要把它们的 include 目标都写进同一条记录里，并注意 SPF 的 DNS 查询次数存在上限，超出会导致验证失败。

第二步：配置 DKIM 签名

DKIM（DomainKeys Identified Mail）走的是另一条路径：它给每封外发邮件加上一段数字签名，收信服务器用 DNS 里的公钥验证签名，从而确认邮件确实由该域名授权发出，并且在传输途中没有被篡改。

配置流程通常是：

1. 在邮件服务商处生成一对密钥（公钥 + 私钥）。
2. 把公钥按服务商给出的格式发布到 DNS，记录名一般形如 selector._domainkey.example.com，其中 selector 是选择器名称。
3. 私钥留在发信服务端，用于对每封外发邮件签名。
4. 发信时在邮件头部带上 DKIM-Signature 字段，其中包含选择器名称，收信方据此去 DNS 查询对应公钥。

需要注意两点：一是选择器名称必须与 DNS 记录名一致，写错会导致查询不到公钥；二是密钥长度与轮换策略由服务商决定，不要自行缩短密钥长度。

第三步：发布 DMARC 策略

DMARC（Domain-based Message Authentication, Reporting and Conformance）建立在 SPF 与 DKIM 之上，它做两件事：告诉收信服务器当认证失败时该如何处理，以及把失败情况以报告形式反馈给域名所有者。

一条仅用于监控的记录形如：

v=DMARC1; p=none; rua=mailto:dmarc@example.com

参数含义：

• p=none 表示只监控，不要求收信方对认证失败的邮件执行拒收或隔离。
• rua=mailto:dmarc@example.com 指定接收汇总报告的邮箱地址。

建议的上线顺序是：先用 p=none 跑一段时间，通过汇总报告确认所有合法发信源都已通过 SPF 或 DKIM 认证，再逐步收紧为 p=quarantine，最后视情况调整为 p=reject。跳过监控阶段直接上严格策略，很容易把仍在使用的合法发信通道一并拦掉。

同样地，上面的记录只是示例格式，具体取值取决于你的邮件基础设施，应以邮件服务商提供的文档为准。

第四步：建立退信与投诉监控

认证配置解决的是「你是谁」，监控解决的是「收件人怎么看你」。需要持续跟踪的指标包括：

• 硬退信（hard bounce）：地址不存在或永久拒收。硬退信率持续偏高，说明地址列表质量有问题。
• 垃圾邮件投诉：收件人主动点击「标记为垃圾邮件」。这是对发信声誉伤害最直接的行为之一。
• 送达率突变：某段时间内投递成功率明显下滑，往往意味着过滤策略已经对你的域名或 IP 收紧了。

几个服务商提供了面向发信方的数据后台：

• 面向 Gmail 收件人，Google Postmaster Tools 向符合条件的发信方提供垃圾邮件率、认证情况以及域名或 IP 声誉等指标。
• Microsoft 提供 SNDS，用于监控向 Microsoft 消费级邮件服务发信的 IP 地址。
• Yahoo 通过其 Sender Hub 提供发信方指引与资源。

这些工具都不能保证邮件进入收件箱，但它们能让你在问题扩大之前发现它，而不是只依赖应用日志里那句「发送成功」。

第五步：保持稳定的发信节奏

发信量本身就是一个信号。一个平时每天只发几百封的域名，如果某天突然发出几千封，即使内容完全合法，也很容易触发额外的审查。机器学习模型特别擅长识别这类异常波动，而这类波动用静态规则很难可靠地捕捉。

可行的做法：

• 让日常发信量保持相对平稳，随业务增长逐步放大，而不是阶梯式跳变。
• 新域名或新邮箱账号上线时，逐步增加发信活动，先建立一段可观察的发信历史。
• 营销类批量邮件与事务性邮件尽量分开通道、分开子域名，避免互相影响。

有些发信方会使用预热（warm-up）平台来逐步提升发信量。需要明确的是，预热只是整个流程中的一环，它不能替代正确的 SPF、DKIM、DMARC 配置，不能替代良好的地址列表卫生，也不能替代负责任的上线节奏，更无法保证收件箱投放结果。

第六步：跨服务商测试收件箱投放

SMTP 返回成功，只说明接收服务器接受了这封邮件，不代表它进了主收件箱。因此关键邮件必须在多个服务商处实测。

具体做法：准备 Gmail、Outlook、Yahoo 三类测试邮箱，分别发送同一封测试邮件（例如密码重置邮件），然后逐一确认：

1. 邮件是否出现在主收件箱，而不是垃圾邮件文件夹或「推广」「其他」这类分类标签下。
2. 查看邮件原始头部，确认 SPF、DKIM、DMARC 三项的验证结果。
3. 记录不同服务商之间的差异，作为后续调整的依据。

这一步应当纳入上线前的常规检查，并且在修改认证记录或调整发信通道之后重新执行。

一个完整示例

下面以一个使用第三方邮件服务的发信域名为例，走一遍从配置到验证的完整流程。假设发信域名为 mail.example.com，邮件服务商给出的 SPF include 目标为 _spf.mailprovider.example，DKIM 选择器为 mp2024。

1. 发布 SPF 记录

mail.example.com.  TXT  "v=spf1 include:_spf.mailprovider.example ~all"

2. 发布 DKIM 公钥记录

mp2024._domainkey.mail.example.com.  TXT  "v=DKIM1; k=rsa; p=<服务商提供的公钥>"

其中 mp2024 必须与服务商控制台中设置的选择器名称完全一致。

3. 发布 DMARC 监控记录

_dmarc.mail.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

4. 从应用侧发送一封测试邮件

以常见的 SMTP 发信为例，应用配置大致包含以下要素：

SMTP_HOST=smtp.mailprovider.example
SMTP_PORT=587
SMTP_USER=apikey
SMTP_PASSWORD=<服务商提供的密钥>
MAIL_FROM=no-reply@mail.example.com
MAIL_FROM_NAME=Example Notifications

发送时使用 STARTTLS 或 TLS 加密连接，并确保 MAIL_FROM 的域名与前面配置认证记录的域名一致。如果信封发件人（envelope from）与头部 From 域名不同，SPF 的对齐检查可能失败，这一点在排查时经常被忽略。

5. 验证认证结果

把测试邮件分别发往 Gmail、Outlook、Yahoo 的测试邮箱，打开邮件原始头部，查找类似下面的字段：

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=mail.example.com;
  dkim=pass header.d=mail.example.com;
  dmarc=pass header.from=mail.example.com

三项均为 pass 说明认证链路已经打通。如果 DKIM 显示 fail 或 none，优先检查选择器名称与 DNS 记录名是否匹配；如果 SPF 显示 fail，检查实际发信 IP 是否落在 include 目标覆盖的范围内。

6. 观察一段时间后再收紧策略

在 p=none 状态下运行一段时间，通过 rua 邮箱收到的汇总报告确认所有合法发信源都能通过认证，再把 DMARC 策略调整为 p=quarantine，观察无异常后视需要调整为 p=reject。

注意事项

认证通过不等于进入收件箱

SPF、DKIM、DMARC 提供的是邮件来源的密码学证明，它证明这封邮件确实由该域名授权发出、途中未被篡改。但它不能证明这封邮件是收件人想要的。认证是必要条件，不是充分条件。

声誉是动态的，不是固定分数

发件人声誉不是一次性评定后长期不变的静态分数。发信模式、认证失败情况、收件人的互动反馈都会持续影响它。一个历史声誉良好的域名，如果突然开始大量发送未经许可的邮件，历史声誉并不能保护这批异常流量免于被立即处理。

不存在统一的全球声誉分

各邮件服务商各自维护独立的过滤基础设施，没有一套统一的、覆盖整个互联网的声誉评分。因此同一封邮件在不同服务商处的命运可能完全不同：它可能顺利进入某个收件人的主收件箱，同时被另一个服务商静默投进垃圾邮件文件夹。原因在于各家对域名声誉、发信历史和用户互动信号赋予的权重不同。

举例来说，同一封新闻邮件分别发往 Gmail 和 Outlook 用户，它在两处通过的 DNS 认证检查完全相同，但两家的过滤系统对内容、发信人历史和内部用户指标的评价方式不同，最终投放结果就可能出现差异。所以，任何单一认证设置都无法绝对保证收件箱投放。

关键词不是判定依据

现代过滤系统是整体评估的，上下文比单个关键词重要得多。同样含有「免费」字样的两封邮件，一封可能是开发者社区的正常账号通知，另一封可能同时具备欺骗性链接和异常发信模式。过滤系统会把这些特征放在一起看，而不是因为出现了某个词就判定为垃圾邮件。

当前一些服务商的垃圾邮件过滤已经引入基于文本向量化的模型，用于捕捉词语的底层含义，从而识别字符间插入空格、使用形近字符等文本操纵手法，同时降低误判率。这意味着靠替换敏感词来绕过过滤的做法基本无效。

机器学习过滤的局限

基于机器学习的过滤并非没有边界。它依赖大量标注数据来学习模式，对全新形态的滥用行为可能存在滞后；不同服务商的模型与训练数据互不公开，导致同一封邮件的结果难以预测和复现；此外，模型判断本身不对外解释，发信方通常只能看到「进了垃圾箱」这个结果，而拿不到具体原因。这也是为什么跨服务商实测和持续监控比单次配置更重要。

配置类信息以官网为准

本文给出的 SPF、DKIM、DMARC 记录均为格式示例。实际取值取决于你所使用的邮件服务商与发信架构，且各服务商的记录格式、密钥长度、报告字段、后台功能与配额都可能随时调整。动手前请以对应服务商的官方文档和当前控制台信息为准。