Defaults.Exposed › 修复 › Guides

DKIM 通过但 DMARC 失败：gappssmtp.com / onmicrosoft.com 默认签名陷阱（2026）

发布于 2026-07-08

数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。

你的邮件用服务商的默认签名通过了 DKIM——d= 以 gappssmtp.com（Google Workspace）或 onmicrosoft.com（Microsoft 365）结尾——但该域名与你的 From 域名不匹配，所以 DMARC 拿不到对齐的通过。启用自定义域名签名即可修复。根据 Defaults.Exposed 对 261,086,232 个已评分域名的普查，在授权 Google 邮件服务器的 12,145,313 个域名中，只有 18.5% 强制执行 DMARC。

这是邮件认证里最干脆利落的修复之一：打开自定义域名 DKIM 签名。在 Google Workspace 是管理控制台的 “Authenticate email” 页面——生成密钥、发布一条 TXT 记录、启用。在 Microsoft 365 是 Defender 门户的 DKIM 页面——发布两条选择器 CNAME、启用。二十分钟的活儿，DMARC 就终于等到了它一直缺的那个对齐通过。

为什么 DKIM 通过但 DMARC 依然失败？

因为 DMARC 问的不是”有没有一个有效的 DKIM 签名？“——它问的是”有没有一个为 From 标头中那个域名签的有效 DKIM 签名？“第二个条件叫对齐（alignment），也是 DMARC 的全部意义所在：证明收件人看见的域名就是签名的域名。

在默认状态下，Google Workspace 用类似 yourdomain-com.20230601.gappssmtp.com 的域名给你的邮件签名（日期戳因域名而异），Microsoft 365 则用 yourtenant.onmicrosoft.com 签名。这两个签名在密码学上都是有效的——DKIM 检查工具都说通过——但 d= 域名属于 Google 或 Microsoft，不属于你。即便按 DMARC 的宽松对齐规则——只要求组织域名匹配——gappssmtp.com 也不是 yourdomain.com。不匹配就没有对齐通过；如果 SPF 也没对齐（它经常做不到——接收方是拿 Return-Path 域名评估 SPF 的，不是 From 标头，而且转发会把它彻底弄坏），DMARC 就失败了。

这就是服务商默认配置最典型的陷阱：**默认配置给你的是投递能力，不是保护——对齐才是那把没拧到底的钥匙。**普查数据显示有多少发件方止步于默认配置：在通过 _spf.google.com 授权 Google 邮件服务器的 12,145,313 个域名中（全球共 138,927,207 个 SPF 发布者），只有 18.5% 强制执行 DMARC。Microsoft 这边的图景形状相同：10,205,070 个域名授权 spf.protection.outlook.com，85.0% 保留着 M365 配置时给出的严格 SPF 记录——却只有 21.7% 强制执行 DMARC。完整对比见我们的邮件服务商 SPF 排行榜。

这个陷阱在日常使用中完全隐形：邮件照常投递，收件箱测试一切正常，什么都不报错——直到你发布一条 DMARC 策略，然后你自己的邮件开始过不了它。我们的免费扫描恰好能揭露这个缺口。

如何在 Authentication-Results 里识别默认签名陷阱？

打开一封你发出的邮件（发到 Gmail 或 Outlook 邮箱），查看原始源码，找到 Authentication-Results 标头。破绽是一个 DKIM 通过却带着错的 d=——Gmail 接收侧的例子长这样：

Authentication-Results: mx.google.com;
       dkim=pass [email protected];
       spf=pass smtp.mailfrom=yourdomain.com;
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

把它当三个问题来读：

在 Microsoft 接收的邮件上，同样的故事表现为 dkim=pass (signature was verified) header.d=yourtenant.onmicrosoft.com 伴随 compauth=fail——这一模式在 Outlook 拒收指南里有讲解。

如果你的标头反而显示 dkim=pass 和 spf=pass 双双通过却 DMARC 失败，那你属于更宽泛的对齐问题——DMARC 失败但 SPF 和 DKIM 都通过指南完整讲解了宽松与严格对齐。

如何启用自定义域名 DKIM 签名？

1. 动手之前，先在 defaults.exposed 运行免费扫描。 它会显示你的域名是否有对齐的 DKIM、你的 DMARC 策略实际是什么，以及这项修复之后是否还有别的东西（SPF、DMARC 记录语法）会拦住你——这样一次就把整件事做完。
2. 确认你在用哪个默认签名。 按上文查看 Authentication-Results 里的 header.d=：gappssmtp.com 是 Google Workspace 默认，onmicrosoft.com 是 Microsoft 365 默认。
3. Google Workspace：生成并发布你自己的密钥。 在管理控制台进入 Apps → Google Workspace → Gmail → Authenticate email，选择你的域名并点击 Generate New Record（除非你的 DNS 主机存不下，否则选 2048 位）。把它给出的 TXT 记录发布到 google._domainkey.yourdomain.com，等待 DNS 生效（最长 48 小时），然后——大家最常漏掉的一步——点击 Start authentication。只生成记录不开启签名，什么都不会发生。完整教程：在 Google Workspace 配置 DKIM。
4. Microsoft 365：发布两条选择器 CNAME 并启用。 在 Defender 门户进入 Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM，选择你的自定义域名并创建密钥。两条 CNAME 都要发布——selector1._domainkey 和 selector2._domainkey，指向 Microsoft 显示给你的目标（从门户原样复制确切目标——2025 年 5 月之前启用的域名以你租户的 .onmicrosoft.com 结尾；更新的以 .dkim.mail.microsoft 结尾）——然后打开签名开关。两个选择器不是可选项：Microsoft 会在两者之间轮换密钥。完整教程：在 Microsoft 365 配置 DKIM。
5. 验证新签名。 给外部邮箱发一封新邮件，重新检查 Authentication-Results：dkim=pass 现在应该显示 header.d=yourdomain.com。如果你的 DNS 面板自动把你的域名追加到了 CNAME 目标后面，或者把很长的 TXT 值弄乱了，签名就切换不过来——这里大多数失败都是面板的怪癖造成的，不是服务商的问题。
6. 重新扫描，让这个对齐通过发挥作用。 确认扫描显示 DKIM 已对齐，然后用起来：停在 p=none 的 DMARC 策略保护不了任何东西。在全部 261,086,232 个已评分域名中，只有 10.59% 强制执行 DMARC（数据截至 2026-06-29）——正是对齐的 DKIM 让逐级收紧变得安全。从如何修复 DMARC 开始。

启用自定义 DKIM 会弄坏什么吗？

不会——这是邮件认证里少见的几乎零波及面的修复：原来带默认签名发出的邮件，现在带着更好的签名发出，密钥仍由服务商管理（Microsoft 会在两个选择器之间自动轮换）。真正的失败模式是做一半——发布了 Google 的 TXT 却始终没点 Start authentication，或者只发布了一条 M365 选择器而不是两条。另外别在日后为了”清理”而删掉这些 DNS 记录；密钥一消失，签名立刻停止。

一个范围说明：这修复的是经由 Google 或 Microsoft 发出的邮件。邮件通讯工具和 CRM 也用它们自己的默认签名，每一个都需要单独开启自定义域名 DKIM——这一模式，连同现在明确提出此要求的 Gmail 大宗发件方规则，都在 550-5.7.26 指南里讲到。

常见问题

每个测试工具上 DKIM 都显示”通过”——为什么还有东西要修？ 因为这些工具回答的问题比 DMARC 问的窄。签名确实有效——但它是 gappssmtp.com 或 onmicrosoft.com 的，不是你的，所以在 DMARC 对齐中一文不值。这正是那么多发件方止步于默认配置的原因：在 12,145,313 个授权 Google 的域名中，只有 18.5% 强制执行 DMARC（数据截至 2026-06-29）。

DMARC 的宽松对齐能让默认签名通过吗？ 不能。宽松对齐只是把匹配放宽到组织域名——mail.yourdomain.com 与 yourdomain.com 对齐。而默认签名的组织域名是 gappssmtp.com 或 onmicrosoft.com，跟你的域名毫无交集。没有任何对齐模式能拯救第三方的 d=。

gappssmtp.com / onmicrosoft.com 签名是坏东西吗？我该移除它吗？ 它不坏——它保证你的邮件至少带着某个有效签名，这对垃圾邮件过滤有帮助。它只是不属于你。你不需要移除它；启用自定义域名签名就把它替换掉了。

我的域名在 Microsoft 365 上，SPF 是严格模式——我是不是已经安全了？ 多半没有：那条严格记录只是 M365 默认配置在完成它唯一的本职工作。在授权 spf.protection.outlook.com 的 10,205,070 个域名中，85.0% 有严格 SPF，却只有 21.7% 强制执行 DMARC（数据截至 2026-06-29）。SPF 在转发下还会失效，因为它是对 Return-Path 而不是 From 标头评估的——对齐的 DKIM 才是能活下来的那条腿，这正是这项修复重要的原因。

这个修复要花多久？ 控制台里的操作每个服务商只需几分钟。等的是 DNS：Google 说开始认证前要预留最长 48 小时；Microsoft 的 CNAME 通常几小时内生效。整体预算一个工作日，其中大部分是等待。

把报告发给负责人

如果你是在替客户或雇主修这个问题，用证据来收尾。新签名生效后重新运行免费扫描，把评分报告转发给企业负责人：有日期、说人话、显示 DKIM 已与他们的域名对齐。这正是网络保险续保和下一份供应商安全问卷需要的材料——证明域名以自己的身份做认证，而不是作为 gappssmtp.com 的一个”租客”。

免费检查你的 DKIM 对齐

查看你的邮件是否以你自己的域名签名——以及确切要修什么——私密进行，仅域名所有者可见。

检查你的域名 → · DMARC 失败但 SPF 和 DKIM 都通过 → · 修复 DKIM → · 在 Google Workspace 配置 DKIM → · 仅使用汇总数据。数据在欧盟境内存储和处理。