Microsoft 365 / 检查邮件DNS与SPF、DKIM、DMARC

在 Microsoft 365 邮件域中，MX 指定接收服务器，SPF·DKIM·DMARC 参与发信邮件的认证和处理策略。这些记录不能互相替代。完成域名所有权验证后，要调查实际发送路径，并反映 Microsoft 365 与外部发送服务的情况。

四种记录的作用

微软的邮件认证部署指南指导用户为自定义域设置SPF、DKIM和DMARC。DMARC并不是只要SPF或DKIM其中之一成功就总是通过，它还会检查与显示的发信域的对齐条件。

SPF是Sender Policy Framework，用于声明发件服务器的允许范围。DKIM是DomainKeys Identified Mail，为邮件附加电子签名的方法，而DMARC是Domain-based Message Authentication, Reporting and Conformance，用于对可见From发件域和认证结果进行对照，并传达失败处理和报告策略的方法。

SPF检查的地址可能与用户读取的From不同，是MAIL FROM（用于服务器间传输的信封发件地址）。DKIM的签名域也可能是服务提供商的域。因此，即使CRM（客户关系管理系统）通过了自己服务提供商域的SPF和DKIM，如果与屏幕上显示的公司域不匹配，也可能无法通过公司域的DMARC。关键点是必须通过至少一个已对齐的SPF或已对齐的DKIM。

在设置之前调查发送路径

• 员工在Exchange Online发送的邮件
• 网站咨询表单、CRM、营销服务、多功能打印机等外部系统发送的邮件
• 单独使用子域的发送服务
• 邮件安全网关或中继服务器经过的路径

如果遗漏发件源，在加强 SPF·DKIM·DMARC 后，正常邮件可能会被拒收。请删除不使用的发件源，并按照相关服务提供商的官方指南为必要的服务进行认证。

在 Microsoft 365 中确认的顺序

1. 在 Microsoft 365 管理中心的 [设置] → [域] 中打开目标域并检查 DNS 设置状态。MX 值使用该域向导中显示的值。

2. 在 DNS 托管商处检查当前的 SPF TXT 记录。如果需要包含 Microsoft 365 之外的发件源，则合并现有值进行设计。
3. 在 Microsoft Defender 门户的邮件认证设置中检查该自定义域的 DKIM 状态及所需的 DNS 记录。将提供的值添加到 DNS 后，确认签名已激活。

4. 逐步引入 DMARC。通过报告分析实际发件源和认证失败情况，然后决定是否强化策略。如果只添加策略语句而不查看报告，将很难发现问题。
5. 向组织外部地址发送测试邮件，并在接收端的头信息中确认 SPF、DKIM、DMARC 的结果及其是否对齐。即使 DNS 状态正常，也需要测试实际的发送路径。

可以直接使用 SPF 示例的条件

在直接管理互联网 DNS 的自定义域中，如果只使用 全球版Microsoft 365作为发送服务 ，则以下 TXT 值为基础示例。如果网站或营销服务使用同一域直接发送邮件，请不要仅用此示例进行替换。必须将实际向导与各发送服务的官方设置进行对照。

v=spf1 include:spf.protection.outlook.com -all

include参考 Microsoft 365 的发送范围，而 -all 表示将不符合条件的发送者视为 SPF 失败。在同一名称下创建两个 SPF TXT，把 Microsoft 365 和外部服务分开使用，这是一种错误配置。需要将所有发送者设计为一个 SPF 策略，并整理不必要的发送者。SPF 以外的所有权验证 TXT 用途不同，不应删除。根据 Microsoft SPF 设置指南 的发送场景进行选择。

设置 DKIM 和 DMARC 时选择的值

在 Defender 门户的 邮件与协作 → 策略与规则 → 威胁策略 → 邮件认证设置 → DKIM 中打开自定义域。如果需要，请进行密钥生成过程，并将域详细信息中显示的 两个 CNAME 的名称和目标 输入到 DNS 服务提供商。选择器和目标名称请复制当前租户提供的值，不要组合使用旧博客的字符串。

DNS 生效后，启用域的 DKIM 签名开关，并确认是否正在签名。如果出现 CNAME 缺失状态，请再次确认输入的名称、实际 DNS 管理供应商及检测时间。仅保存两个记录不会被认为签名已开启。可通过 DKIM 官方设置流程 查看当前状态下的操作方法。

DMARC 的初始策略可以配置为报告为中心，以分析正常发件人。以下示例使用 example.com 作为说明域。实际域的 _dmarc TXT 中需要填写的值应更改为组织可接收报告的地址。

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

p=none 是一种初始策略，不要求因 DMARC 失败而进行隔离或拒绝，也不会解除其他垃圾邮件或安全过滤。rua 是接收汇总报告的地址。该地址需要做好实际接收和分析的准备，如果使用外部报告服务地址，还需要确认额外的 DNS 授权条件。在确认正常发件人的对齐和传递路径后，再强化到 quarantine、reject 阶段。具体条件请遵循 DMARC 导入指南。

同时确认 DNS 通过和实际邮件认证

针对员工邮件、网站联系表单、CRM 等每个发送路径向外部测试地址发送新邮件。在接收端打开消息原文和互联网头信息，查看 Authentication-Results 的 SPF、DKIM、DMARC 结果，并对比 DKIM 的签名域和显示的 From 字段。需要的是更改后新发送消息的结果，而不是“以前的邮件正常”。

如果 DNS 正常但只有特定 CRM 失败，则从该路径的发送域和签名设置开始检查。在传递过程中，如果签名的正文被修改或发送服务器不同，结果可能会不同。认证通过并不保证进入收件箱，声誉、垃圾邮件和内容政策也会产生影响。

记录值会根据域名和设置时间的不同而有所变化。本文的目的不是要记住这些值，而是为了将管理中心提供的值、DNS的实际值以及接收端认证结果互相对照。如果发生邮件收发问题，请以更改前的DNS记录为依据来确认影响范围。如果正常邮件受到影响，请将上一个策略与发送方配置进行比较，仅恢复导致问题的更改，然后再次测试。不要在不明原因的情况下删除所有SPF、DKIM、DMARC记录或持续保持严格的DMARC策略。请在报告中区分正常发送方的失败与可疑伪造发送，并据此采取后续措施。