为什么 SPF、DKIM 和 DMARC 缺一不可
SPF、DKIM 和 DMARC 是三种 DNS 记录，让其他邮件系统能够核实来自您域名的邮件确实出自您手。每一种都弥补了其他两种留下的缺口，所以一个域名需要三者齐备。
与工程师沟通 知识库
为什么它对企业重要
电子邮件本身没有对发件人身份的内置检查。没有这些记录，任何人都可以把您的域名写进 From 行，于是一张伪造的发票收到时看上去就像来自您的财务团队。
反过来的情况也会发生。大型服务商不信任未经验证的邮件，因此真实的回复会落入垃圾邮件。自 2024 年起，Google 和 Yahoo 要求批量发件人进行验证。
各自的作用
- SPF：列出获准代表您的域名发送邮件的服务器。
- DKIM：为每封邮件签名，证明是哪个域名签的名，以及邮件在途中没有被改动。
- DMARC：检查 SPF 或 DKIM 是否针对 From 地址中的域名通过验证，在两者都未通过时告诉接收方该怎么做，并向您发送报告。
单独一种都不够。SPF 和 DKIM 可能针对一个与读者所见不同的域名通过验证，而且两者都不要求接收方拦截任何邮件。DMARC 需要其中一种正常工作，而 SPF 在转发的邮件上会失败，所以 DKIM 是后备。
| 记录 | 检查什么 | 存放位置 | 无法做到什么 |
|---|---|---|---|
| SPF | 发送服务器是否在您的名单上 | 域名上的一条 TXT 记录 | 保护 From 地址，或在转发后依然有效 |
| DKIM | 邮件是否未被改动，以及由谁签名 | 每个发送服务一条记录，位于某个选择器之下 | 说明对未签名或签名被破坏的邮件该怎么处理 |
| DMARC | SPF 或 DKIM 与 From 域名匹配 | 位于 _dmarc 的 TXT 记录 | 在没有 SPF 或 DKIM 的情况下发挥作用 |
常见错误
- 两条 SPF 记录：为新服务另外添加第二条记录，会让您所有邮件的 SPF 验证失败。
- 没人添加的发送方：营销平台或开票系统以您的域名发送邮件，却从未获得 SPF 条目或 DKIM 密钥。
- DMARC 永远停在 none：策略始终不推进，伪造的邮件仍会被投递。
- 直接跳到 reject：在没读报告之前就强制执行，会把您自己的邮件和伪造邮件一起拦下。
设置顺序
- 列出每个发送方：您的邮件服务商，以及每个以您的域名发邮件的服务。
- 发布一条 SPF 记录，涵盖所有发送方。
- 在每个发送服务中启用 DKIM。
- 发布 none 策略的 DMARC，带上报告地址，并阅读报告。
- 先改为 quarantine，再改为 reject，前提是报告中只剩下您自己的服务。
这三种记录都位于您的 DNS 中。其余的设置内容请见我们的企业电子邮件指南。
KawaConnect 如何处理电子邮件验证
在我们设置、迁移或管理 Microsoft 365 时，SPF、DKIM 和 DMARC 记录是工作内容的一部分，与路由邮件的 MX 记录一起处理。对于由我们托管的网站，会发送邮件的联系表单也会加入同一套记录。
相关服务
了解更多
- 维基百科上的电子邮件验证对用于核实电子邮件来源的各种方法的概述。
- Cloudflare 上的 DMARC、DKIM 和 SPF对这三种记录的讲解。
- dmarc.org 上的 DMARC 概述来自标准自己的网站，说明 DMARC 如何建立在 SPF 和 DKIM 之上。
- Google 电子邮件发件人指南Gmail 对发件人所要求的验证。
- Microsoft 365 中的电子邮件验证Microsoft 针对 Microsoft 365 的这三种记录的指南。
