Microsoft 365 邮件认证：SPF、DKIM 与 DMARC 配置指南

Exchange Online 负责路由和签名，但认证的 DNS 侧仍要自己配。SPF、DKIM、DMARC 不正确的 Microsoft 365 域名，过不了 Gmail、Yahoo 与 Outlook.com 自 2024 年起执行的批量发件人要求——进箱率下滑，营销与通知邮件成批进垃圾箱，而失败常常是静默的，直到有人翻垃圾箱才发现合同邮件躺在里面。

本指南给出记录值与当前控制台路径（DKIM 已从 Exchange 管理中心迁至 Defender 门户），按不中断投递的顺序展开。协议不熟悉的读者先读邮件认证总览。

准备工作

• Microsoft 365 租户，以及 security.microsoft.com 的管理员权限。
• 已验证的自定义域名；初始 *.onmicrosoft.com 域由微软自动签名，无需处理。
• DNS 写权限（Cloudflare 用户见Cloudflare DNS 指南），并列出非微软发件源（CRM、营销、工单）——以下记录都覆盖不了它们，DMARC 报告迟早会把它们揪出来。

第一步：发布唯一的 SPF 记录

在自定义域名根下创建一条 TXT：

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

两条规则压倒一切：

• 只能有一条。迁移后旧服务商的 SPF TXT 若还在，SPF 永久失败。删旧记录，合并需要的：v=spf1 include:spf.protection.outlook.com include:mailgun.org ip4:203.0.113.10 ~all。
• 守住 10 次查询。RFC 7208 上限包含嵌套 include。用 SPF 检测复查；接近上限时参考SPF 扁平化指南。

验证期保持 ~all，DMARC 报告确认覆盖完整后再改 -all。很多人反过来做：先硬失败，再一个个排查被拒的来源，代价是几天内持续丢信。记录发布后，用 SPF 检测确认查询次数没有超过 10——这正是大部分"莫名其妙全挂"的根因。

第二步：在 Defender 门户启用 DKIM

Microsoft 生成并轮换密钥对，你用两条 CNAME 证明对域名的控制权。这个设计与多数服务商不同：DNS 里放的不是公钥本身，而是一个指向微软密钥库的别名，因此轮换对你完全透明。

1. 在 security.microsoft.com 进入 Email & collaboration > Policies & rules > Threat policies > Email authentication settings，选 DKIM 标签页。直达链接：security.microsoft.com/authentication?viewid=DKIM。旧教程里的 Exchange 管理中心路径已经过时，按它找不到开关。
2. 把域名开关滑向 Enabled，会弹出客户端错误框——属预期，内含 CNAME 值。关掉后打开域名详情浮层，Publish CNAMEs 展示得更清楚。
3. 在 DNS 处创建两条 CNAME：

selector1._domainkey  CNAME  selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey  CNAME  selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com

2025 年 5 月后添加的域名使用以 .dkim.mail.microsoft 结尾的新格式——以浮层值为准，别照抄文章。注意连字符：目标中的域名写作 yourdomain-com。

4. 等状态离开 CnameMissing 再打开开关，检测需几分钟到几小时。

新租户默认 2048 位；仍是 1024 位的，用浮层里的 Rotate DKIM keys 轮换（最长 96 小时，期间旧密钥继续签名，不会断档）。轮换后原先那条 s= 选择器会变化，测试邮件时别误以为配置坏了。用 DKIM 检测、selector 填 selector1 确认公钥可解析。

第三步：在自己的 DNS 发布 DMARC

DMARC 是 _dmarc.yourdomain.com 下的 TXT：

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

p=none 不拦截、只收聚合报告，用 DMARC 报告分析器阅读。报告会按发信 IP 归组，你很快能看清：哪些是 Exchange Online，哪些是漏配的第三方服务，哪些是真正的伪造尝试。所有正常发件源通过后，才经 p=quarantine; pct=25 升到 p=reject，每一步留一周观察期。记录用 DMARC 生成器生成。

验证整套配置

从 Exchange Online 向外部 Gmail 或 Outlook.com 发测试信，查看邮件头——Gmail 用显示原始邮件，其他用邮件头分析器：

spf=pass (sender IP is 203.0.113.10)
dkim=pass (signature was verified) header.d=yourdomain.com
dmarc=pass action=none header.from=yourdomain.com

header.d= 必须是你的域名，绝不能是 onmicrosoft.com——这就是对齐检查：DKIM 用哪个域名签名，DMARC 就认哪个域名，与 From 对不上等于白签。整域扫描用 邮件健康检查或 邮件投递测试，后者还会顺带给出黑名单与 DNS 配置的体检结果。

常见错误

• 迁移后残留两条 SPF。旧 TXT 没删，SPF 直接永久错误。一个域名一条 v=spf1。
• 猜 CNAME 目标值。格式含微软分配的字符段。从浮层复制，或在 PowerShell 跑 Get-DkimSigningConfig。
• 想给初始域配 DKIM。只有自定义域名出现在 DKIM 标签页并需要 CNAME。
• 第三方发件源未对齐。经租户中继的 CRM 不走连接器就可能破坏对齐；SendGrid、Mailgun 这类独立服务需要自己的记录，配置模式与本文完全不同——邮箱服务商的认证覆盖不了它们，见 SendGrid 与 Mailgun 指南。
• 第一天就上 reject。跳过监控，所有被遗忘的发件源全被拒收。

常见问题

为什么有两条 DKIM CNAME？

两个 selector 让密钥轮换无断档：一个换、另一个继续签名。这也是轮换期间收件方仍能验证旧邮件的原因——旧公钥还挂在另一个 selector 上。两条都要发，否则下次轮换 DKIM 就断。

能用 TXT 代替 CNAME 吗？

微软托管的密钥不行——CNAME 指向微软的密钥设施，轮换才自动。TXT 形式的 DKIM 通常只出现在第三方发信服务上。

状态一直卡在 CnameMissing？

几乎都是主机名问题：服务商追加了域名，或连字符形式敲错。用 DKIM 检测确认线上值，逐字符比对。CNAME 检测本身由微软周期触发，DNS 改对了也可能要等上几小时，别急着反复删改。

每个自定义域名都要单独配 DKIM 吗？

要。租户里的每个自定义域名都有自己的一对 CNAME 和自己的开关，两个域名就是四条记录。主域名配好了，新加的域名不会自动沾光——发信前记得单独启用。