Defaults.Exposed › 修复 › Guides
“DKIM Signature Not Valid”——各种原因，按排查顺序排列（2026）
发布于 2026-07-08
数据截至 2026-06-29 · 方法论 v7。 基于 261 百万个已评分域名的汇总普查数据。参见我们如何评分。
“DKIM signature not valid”有五个常见原因，最好按顺序排查：内容在传输途中被修改、密钥记录被截断、发布的密钥与签名方不一致、选择器不对、脆弱的规范化设置。根据 Defaults.Exposed 普查（2026-06-29），在 261,086,232 个已评分域名中，只有 10,092,481 个（3.87%）同时具备 SPF + DKIM + 强制执行的 DMARC 这一完整三件套。
排查顺序之所以重要，是因为最常见的原因根本不在你的 DNS 里。先检查是什么在传输途中改动了邮件，再由外向内排查：密钥记录本身的完整性、它是否与邮件服务器实际使用的签名密钥一致、选择器，最后才是签名设置。大多数无效签名在第一步或第二步就修好了。
“DKIM signature not valid”到底是什么意思？
每封经 DKIM 签名的邮件都带有一个 DKIM-Signature 标头，其中写明域名（d=）、选择器（s=）、邮件正文的哈希（bh=），以及对正文哈希和选定标头的加密签名（b=）。接收方从 DNS 的 <selector>._domainkey.<domain> 处获取你的公钥，重新计算两个哈希，并校验签名（RFC 6376）。“Signature not valid”是检测工具和标头的说法，意思是：验证跑过了但失败了——密钥找到了，但数学没对上。
最后这半句是诊断的金子。找不到你的密钥的验证方会说别的话——通常是类似 dkim=fail (no key for signature) 的标头——那是选择器问题，见 DKIM“no key for signature”——选择器与轮换的修复。而重新算出不同正文哈希的验证方通常会明说：body hash did not verify——Microsoft 报告为 dkim=fail (body hash did not verify)，Gmail 则常把同样的诊断显示为 dkim=neutral (body hash did not verify)。无论哪种，都指向内容被修改，见“body hash did not verify”——是什么改动了你的邮件。动手之前先读 Authentication-Results 标头里的确切措辞：它告诉你手里拿的是五个原因中的哪一个。
把这件事做对的域名很少：根据 Defaults.Exposed 普查，只有 51.84% 的已评分域名在 DNS 中发布了可发现的 DKIM 密钥，而在 261 百万个已评分域名中，只有 3.87% 同时具备 SPF、DKIM 和强制执行的 DMARC 策略——这正是大宗发件规则如今默认要求的配置。逐阶段的全景见 SPF 采用成熟度模型。
五个原因按顺序是什么？
| # | 原因 | 特征信号 | 修复方法 |
|---|---|---|---|
| 1 | 内容在传输途中被修改——网关页脚、法律免责声明、邮件列表的主题标签 | Authentication-Results 中出现 body hash did not verify；外部邮件失败，直发邮件通过 | 在修改之后再签名，或停止修改——见正文哈希指南 |
| 2 | 长密钥被截断或弄乱 | 发布的 p= 明显比你生成的密钥短；所有接收方都失败 | 把 2048 位密钥以正确拆分的 TXT 字符串重新发布 |
| 3 | 发布的密钥与签名方不一致 | 失败恰好始于一次轮换、迁移或更换服务商之后 | 从签名方重新复制当前公钥；优先使用 CNAME 委托 |
| 4 | 选择器错误或缺失 | no key for signature——查询本身就失败 | 发布签名方实际使用的选择器——见选择器指南 |
| 5 | 脆弱的规范化设置或 l= 标签 | 在被轻微重排版的邮件上间歇性失败 | c=relaxed/relaxed；彻底删除 l= |
原因 1 加粗，是因为它破坏的是签得完美无缺的邮件。安全网关追加一段免责声明、合规页脚在签名之后被盖上去、邮件列表在主题里加上 [listname]——正文或被签名的标头变了，哈希就对不上了，签名随之无效，而你的 DNS 毫无过错。如果失败与经过网关、邮件列表或归档节点的邮件相关联，就从那里查起。
“DKIM signature not valid”怎么修？
- 动 DNS 之前，先在 defaults.exposed 运行免费扫描。 它显示你发布的密钥记录是否存在、格式正确且完整——一步就把“你的 DNS 坏了”（原因 2–4）和“你的 DNS 没问题，是邮件被改了”（原因 1）区分开。
- 读一封失败邮件的
Authentication-Results标头。body hash did not verify→ 原因 1，去看正文哈希指南——常见元凶是网关页脚和免责声明，解法是在修改之后签名。no key for signature→ 原因 4，去看选择器指南。普通的签名失败 → 继续往下。 - 检查发布的密钥是否被截断。 以 TXT 类型查询
<selector>._domainkey.<yourdomain>（dig TXT selector._domainkey.example.com）。2048 位 RSA 公钥超过单个 TXT 字符串 255 个字符的上限，因此必须发布为多个带引号的字符串，由接收方拼接——而 DNS 服务商的网页界面出了名地会悄悄截断粘贴内容、弄乱拆分，或往p=值里塞进空白和引号。与签名方生成的密钥逐字符比对；我们的 DKIM 配置逐步教程覆盖了各服务商的怪癖。 - 确认发布的密钥与签名方一致。 在密钥轮换、服务商迁移或 ESP 重新接入之后，常见的情况是签名方已持有新私钥，而 DNS 仍在提供旧公钥——每个签名都拿错误的密钥去验证，全部失败。从服务商管理控制台重新复制当前记录。更好的做法：只要服务商提供 CNAME 委托就用它——服务商在自己那边轮换密钥，这一整类故障就消失了。另外，在用旧选择器签名的邮件流量彻底排空之前，绝不要删除旧选择器。
- 修正签名设置，而不只是记录。 把规范化设置为
c=relaxed/relaxed，它能容忍中间服务器合法进行的空白重排和标头重新折行；simple规范化会在人眼都看不出的改动上失败。并且不要使用l=正文长度标签：它本意是放行页脚，实际却让任何人都能在你签名的邮件后追加内容而不破坏签名——一个真实的攻击途径——而且它照样扛不住大多数网关修改。不用l=既更安全也更可靠。 - 重新扫描，然后检查对齐。 有效的签名只有在
d=域名与你的 From 域名对齐时才对 DMARC 有用——一个以d=yourcompany.gappssmtp.com验证通过的签名，DKIM 通过，DMARC 照样失败。如果这说的就是你，见默认签名陷阱，然后在修复 DKIM 页面上处理扫描标出的其余问题。
常见问题
“DKIM signature not valid”和“body hash did not verify”是一回事吗？ 正文哈希那条信息是一个特定子情形：正文在签名之后被改动了（页脚、免责声明、列表改写）。“Signature not valid”是所有验证失败的总称裁决，包括坏密钥和标头改动——这就是为什么上面第 2 步是读标头，也是为什么正文哈希情形有自己的指南。
DKIM 签名无效是否意味着我的邮件正在被拒收？ 单凭它不会——接收方把损坏的签名当作缺失的签名对待。伤害经由 DMARC 落地：如果 SPF 也没有以对齐方式通过，邮件就 DMARC 失败，你发布的策略随即生效。截至 2026-06-29 的普查，261,086,232 个已评分域名中只有 3.87% 同时具备 SPF、DKIM 和强制执行的 DMARC 策略——但 Gmail 和 Microsoft 现在对发件方的期待恰恰是这一套，所以 DKIM 这条腿断了，还没到被拒收就已经在损失送达率。
DKIM 密钥该用 1024 位还是 2048 位？ 2048 位——1024 位密钥已低于当前密码学建议，部分接收方会为此扣分。麻烦纯粹在操作层面：2048 位密钥放不进一个 255 字符的 TXT 字符串，必须正确拆分（上面的原因 2）。CNAME 委托给你的服务商则完全绕开拆分问题。
我的 DKIM 在检测工具上通过，DMARC 却仍然失败——怎么回事？
几乎可以肯定是对齐问题：签名验证通过，但它的 d= 域名（比如 yourcompany.gappssmtp.com 或 yourtenant.onmicrosoft.com）与你的 From 域名不匹配，DMARC 用不上它。启用服务商的自定义域名签名——完整教程在默认签名陷阱指南里。
DKIM 老是失败，能不能干脆关掉？ 不能——自 2024 年的大宗发件强制要求以来，Gmail 和 Yahoo 要求量大的发件方必须有 DKIM，而强制执行的 DMARC 策略实际上也离不开 DKIM，因为仅靠 SPF 在转发场景下会失效。把签名修好；上面的这些原因一个下午都能修完。
把报告发给老板
如果你是在替客户或雇主修这个问题，用证据收尾。改完之后重新运行免费扫描，把评分报告转发给企业负责人：带日期、直白语言、DKIM 显示绿色。这正是他们在网络保险续保和下一份供应商安全问卷时需要的凭证——“我修了个 DNS 的东西”与一份白纸黑字的前后对比、证明该域名的邮件已通过认证，二者的区别就在这里。
检查你的域名 → · “Body hash did not verify”指南 → · 修复 DKIM → · 我们如何评分 → · 仅使用汇总数据。数据在欧盟境内存储和处理。