核心要点
- SPF（RFC 7208）：公布一份授权名单，列明哪些 IP 地址和发信服务可以在信封发件人（Return-Path）中使用您的域名发送邮件。
- DKIM（RFC 6376）：利用非对称密钥对为每封邮件添加加密签名，证明邮件确由签名域名授权发出，且在传输途中未被篡改。
- DMARC（RFC 7489）：告诉收件服务器如何处理未通过 SPF 和 DKIM 对齐校验的邮件（none、quarantine 或 reject），以及应将聚合报告发送到哪里。
- 自 2024 年 2 月起，Gmail 和 Yahoo 要求批量发件人（Gmail 的定义是每天向个人 Gmail 账户发送 5,000 封以上邮件）同时通过 SPF 和 DKIM 认证，发布 DMARC 记录（至少为
p=none），并使 From 域名与 SPF 或 DKIM 对齐。
当 Google Workspace、Microsoft 365 或 Yahoo Mail 等收件服务器接收一封来自 contact@yourcompany.com 的邮件时，其过滤系统会执行一系列技术检查，以判断这封邮件究竟来自该域名的合法所有者，还是一次仿冒或钓鱼企图。
如果您的域名在 DNS（域名系统）中缺少必需的认证记录，该邮件就会被视为高风险邮件，很可能被投入垃圾邮件文件夹，或直接在 SMTP 层面被拒收，并在您的发信平台中记录为退信。
1. 三大核心邮件认证机制
要理解邮件安全体系如何协同运作，先要弄清三个协议各自承担的、既独立又互补的角色：
SPF（Sender Policy Framework，发件人策略框架）
SPF 相当于发布在 DNS 中的一份公开白名单。该记录声明哪些服务器有权代表您的域名发送邮件，这些服务器可以通过 IP 地址标识，也可以通过指向 Amazon SES、SendGrid 或 Mailgun 等服务商的 include 机制来指定。收件方针对的是信封发件人（MAIL FROM / Return-Path）的域名进行 SPF 校验，而不是收件人看到的 From 地址。
DKIM（DomainKeys Identified Mail，域名密钥识别邮件）
DKIM 用于验证邮件的完整性。邮件离开发信服务器时，系统会用私钥生成数字签名，并以 DKIM-Signature 邮件头的形式附加到邮件中。收件服务器从您的 DNS 中获取对应的公钥来验证签名，从而确认已签名的邮件头和正文在传输途中没有被伪造或修改。
DMARC（Domain-based Message Authentication, Reporting, and Conformance，基于域名的邮件认证、报告与一致性）
DMARC 是将 SPF 与 DKIM 串联起来的一层。它要求收件服务器检查可见发件人地址（Header From）中的域名，是否与通过 SPF 或 DKIM 认证的域名一致，这一检查称为对齐（alignment）。只要两者中至少有一项通过且已对齐，邮件即通过 DMARC。DMARC 还规定了认证失败时收件方应采取的处理方式，并提供了接收聚合报告（RUA）的渠道。
2. SPF 记录的结构与语法
SPF 记录以 TXT 记录的形式发布在信封发件人所用的域名上。如果邮件由您自己的服务器或 Google Workspace 发出，这通常就是根域名：
Host / Name: @ (or yourcompany.com)
Value / Content: v=spf1 include:amazonses.com ~all
记录中各部分的含义：
v=spf1：声明所使用的 SPF 版本，必须位于记录的第一项。include:amazonses.com：授权 Amazon Simple Email Service（SES）的发信 IP 段代表该域名发送邮件。如果同时使用 SendGrid，对应写法为include:sendgrid.net。请注意，使用 Amazon SES 时，只有配置了自定义 MAIL FROM 子域名（例如bounce.yourcompany.com），并在该子域名上发布这条记录以及 SES 提供的 MX 记录，SPF 才能满足 DMARC 对齐要求。若在 SendGrid 中启用了域名认证和自动安全功能，SendGrid 会通过 CNAME 为其 return-path 子域名托管 SPF，因此无需在根域名上添加 include。~all（SoftFail，软失败）：表示来自名单之外服务器的邮件应被视为可疑，但通常仍会接收。这是最常见的选择，尤其适合仍在梳理发信来源的阶段。-all（HardFail，硬失败）：表示来自未授权来源的邮件应被判定为明确失败，收件方可能直接拒收；不过，如今许多大型邮箱服务商会以 DMARC 结果为准，而不会仅凭 SPF 就拒收邮件。
include、a、mx、ptr、exists 和 redirect 均计入，嵌套查询也包括在内）。如果有多个服务使用同一域名发信（例如 Google Workspace 和 Amazon SES），请将它们合并到同一条记录中：v=spf1 include:_spf.google.com include:amazonses.com ~all。
3. 配置 DKIM
配置 DKIM 通常需要生成一对 RSA 密钥，目前建议的最低密钥长度为 2048 位。通过 eMailBase 接入发信服务商时：
- 服务商会为其 DKIM 选择器（selector）生成相应的 DNS 记录。Amazon SES Easy DKIM 会生成三条
CNAME记录，格式为<token>._domainkey.yourcompany.com；SendGrid 会生成两条 DKIMCNAME记录（s1._domainkey和s2._domainkey），外加一条用于其 return-path 子域名的记录；Mailgun 通常提供一条包含公钥的 TXT 记录。 - 登录您的 DNS 服务商控制面板，严格按照生成的内容逐条创建记录。
- 记录生效传播后，eMailBase 会自动查询 DNS 并确认激活状态。
4. 稳妥推进 DMARC 强制策略
如果在第一天就发布严格的 DMARC 策略，一旦某个发信来源尚未被 SPF 或 DKIM 完全覆盖，合法邮件也可能遭到拒收。DMARC 记录以 TXT 记录的形式发布在 _dmarc.yourcompany.com 上，标准的推进流程分为三个阶段：
| 阶段 | 策略语法 | 运营目标 |
|---|---|---|
| 阶段 1：监控 | v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com |
收集聚合报告，在不影响投递的前提下识别所有合法发信来源。 |
| 阶段 2：隔离 | v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourcompany.com |
对 25% 未通过校验的邮件执行隔离策略（通常是投入垃圾邮件文件夹），待报告确认合法邮件均已通过后，再逐步提高比例。各收件方对 pct 的支持程度不一，且该标准的修订版 DMARCbis 已将其移除。 |
| 阶段 3：拒收 | v=DMARC1; p=reject; rua=mailto:dmarc@yourcompany.com |
要求收件方拒收所有未通过 DMARC 的邮件，杜绝他人冒用您的域名。 |
5. 验证 DNS 记录与排查问题
记录配置完成后，可以使用标准命令行工具进行检查：
dig +short TXT yourcompany.com
# Check a DKIM record (replace the selector with your own)
dig +short CNAME selector._domainkey.yourcompany.com
# Check the DMARC record
dig +short TXT _dmarc.yourcompany.com
在 eMailBase 工作区中，这些检查由 DNS 与送达率管理器自动执行，一旦出现语法冲突或记录缺失，系统会立即发出提示。
