Defaults.Exposed

Defaults.Exposed › 修复 › Guides

DKIM "No Key for Signature"：选择器与密钥轮换修复指南（2026）

发布于 2026-07-08

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

“No key for signature” 意味着接收方查询了你 DKIM 签名指向的 DNS 记录——selector._domainkey.yourdomain——却没找到密钥：它从未被发布，或在轮换过程中被删除。把签名方实际使用的选择器发布出去。根据 Defaults.Exposed 对 261,086,232 个已评分域名的普查，只有 10,092,481 个域名——3.87%——完成了 SPF+DKIM+DMARC 三件套。

修复只需一条 DNS 记录，而线索藏在一个标头里。从一封真实邮件的 DKIM-Signature 标头读取 s= 和 d= 标签，弄清你的邮件是用哪个选择器签名的，发布（或修复）那条确切的记录，并优先使用 CNAME 委托让服务商替你轮换密钥。然后按下面的操作手册进行轮换——这个错误通常意味着有人过早删除了旧选择器。

“dkim no key for signature” 是什么意思？

每个 DKIM 签名都携带两个标签，告诉接收方去哪里获取公钥：d=（签名域名）和 s=（选择器）。接收方用它们拼出一个 DNS 名称——s._domainkey.d——去查询密钥。“No key for signature” 意味着这次查询空手而归：签名存在，但它指名的密钥不存在。

这段措辞出现在 Authentication-Results 标头和 DMARC 汇总报告中——确切的表述因接收方而异，但有两种形态需要区分：

结果字符串（片段，广泛观察所得）实际发生了什么是暂时性的吗？
dkim=temperror (no key for signature)DNS 查询失败或超时——接收方根本没拿到答案是——重试往往就能通过；只有持续出现才需要调查
dkim=permerror (no key for signature)DNS 查询成功，但答案是”没有这条记录”——选择器确实不存在不是——在你发布之前，记录一直是缺失的

偶发一次的 temperror 是 DNS 的”天气问题”。permerror——或者跨越多天、多个接收方反复出现的 temperror——意味着签名指向的记录不在你的域内。这正是本指南要解决的问题。

后果是：无法验证的签名等同于完全没有 DKIM，于是 DMARC 只能退而依赖 SPF——而 SPF 在转发场景下会失效。如果签名存在但是无效而非缺失（正文哈希、密钥被弄乱），那是另一种故障——见 “DKIM signature not valid”。

如何找出我的邮件是用哪个选择器签名的？

别从服务商文档里猜——从一封真实邮件里读出来：

  1. 从出问题的系统给你自己控制的邮箱发一封邮件（Gmail 地址就很好用）。
  2. 打开原始源码（Gmail 里是 “Show original”，Outlook 里是 “View message source”）。
  3. 找到 DKIM-Signature: 标头并读取两个标签：s= 是选择器，d= 是签名域名。一个示意性的例子：DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=mail2026; ...
  4. 接收方查询的记录是 s._domainkey.d——在这里就是 mail2026._domainkey.yourdomain.com。自己核实一下：dig TXT mail2026._domainkey.yourdomain.com +short。答案为空 = 这个错误对每一个接收方都真实存在。
  5. 对每个发送系统重复上述步骤。一封邮件可以携带多个 DKIM 签名——邮箱服务商、邮件通讯工具、工单系统——各自有自己的 s=/d= 组合和记录。修好失败的那个，并留意它的 d=：只有 d= 与你 From 域名匹配的签名才对 DMARC 有帮助。

选择器记录为什么会缺失？

几乎所有这类错误都出自四个原因——按这个顺序排查：

  1. 它从未被发布。 签名方被开启（或默认开启）时用了一个没人添加到 DNS 的选择器。新工具和会意外签名的网关常出这种事。
  2. 它在轮换过程中被删除。 有人在用旧选择器签名的邮件还在传输途中、排队重试或等待转发时就把它”清理”掉了。那些邮件已经用 s=old 签好名；删除 old._domainkey 会追溯性地毁掉其中每一封。
  3. 你的 DNS 界面弄乱了 CNAME 目标。 许多服务商通过 CNAME 委托（s1._domainkey.yourdomain.com → s1.domainkey.u123.esp.com），而许多 DNS 面板会悄悄把你的域名追加到目标后面——存成 s1.domainkey.u123.esp.com.yourdomain.com，解析结果为空。要核实目标：dig CNAME s1._domainkey.yourdomain.com +short。工具迁移时同样会踩这个坑——见更换邮件工具后 DKIM 失败。
  4. 服务商轮换了，你的域没跟上。 把服务商的密钥当静态 TXT 记录粘贴（而不是用他们的 CNAME），就会被他们的定期轮换甩下——签名方换到了一个你从未发布的选择器。在 261 百万个普查域名中，只有 51.84% 在扫描时展示出可发现的 DKIM 密钥（数据截至 2026-06-29）。

“no key for signature” 怎么修？

  1. 动 DNS 之前，先在 defaults.exposed 运行免费扫描。 它读取你现网的 DKIM、SPF 和 DMARC 记录，展示接收方实际看到的样子——包括选择器是否可解析、CNAME 目标是否被弄乱。
  2. 发布签名方实际使用的选择器——是标头里那个 s= 值，不是旧操作手册里写的那个。从服务商的管理控制台获取记录（Google Workspace DKIM 配置 · Microsoft 365 DKIM 配置），并添加到精确的 s._domainkey.yourdomain.com 位置。
  3. 优先用 CNAME 委托，而不是粘贴 TXT 密钥。 如果服务商提供 DKIM CNAME，就用它们：密钥存在他们的域里，轮换时你无需再碰 DNS——原因 4 从此不可能发生。邮件通讯平台几乎全都是这种方式；见 Mailchimp/Brevo/Klaviyo 邮件 DMARC 失败。
  4. 在你的面板之外验证。 在你网络之外的机器上运行 dig TXT s._domainkey.yourdomain.com +short（委托型选择器则用 dig CNAME …）。面板显示有这条记录不代表什么——域实际对外提供的可能是别的东西。
  5. 重新扫描并重发测试邮件。 Authentication-Results 现在应该显示 dkim=pass。然后逐项处理扫描在修复 DKIM 页面标记的其他问题——签名通过但与你的 From 域名不对齐，DMARC 照样失败。

如何轮换 DKIM 密钥而不触发这个错误？

轮换正是好端端的配置出问题的地方。防止出错的规则是：只有在最后一封用某选择器签名的邮件排空之后才能删除它——绝不在切换时删。 已签名的邮件比你想的活得久：重试队列会跑好几天，转发的邮件每次流转都会被重新验证。

步骤操作进入下一步前的关卡
1. 添加在旧选择器旁边发布新选择器（s2._domainkey…）dig 确认它从外部可解析
2. 切换把签名方指向新选择器测试邮件显示 s=s2 且 dkim=pass
3. 等待让旧选择器保持发布状态，等在途、排队和转发的流量排空≥ 7 天；盯着 DMARC 汇总报告，直到旧选择器不再出现
4. 退役移除旧密钥——或者更好：用空的 p= 标签重新发布它：“已退役”，而不是”从未存在”绝不在切换当下就开始这一步——过早删除是 “no key for signature” 的头号原因

用 CNAME 委托的话，服务商会在自己的域内跑完这套完全相同的手册，而你全程无感——这是委托方案最有力的论据。

常见问题

“no key for signature” 是 temperror 还是 permerror？ 两种字符串都存在：temperror 是 DNS 查询失败或超时——暂时性的，重试往往就没了——而 permerror 意味着 DNS 明确回答”没有这条记录”。跨多个接收方反复出现的 temperror，最后通常也被证实是记录确实缺失。用 dig 检查，相信查询结果，而不是标签。

这个错误是否意味着有人在冒充我的域名？ 不是——冒充者不会用你的选择器签名。它意味着你自己的邮件带着一个接收方无法验证的签名，于是被当作未签名处理，DMARC 只能依赖 SPF。完整、对齐的认证很罕见：在 Defaults.Exposed 普查的 261,086,232 个域名中，只有 10,092,481 个（3.87%）完成了 SPF+DKIM+DMARC 三件套（数据截至 2026-06-29）。

新选择器一生效，我能直接删掉旧的吗？ 不能马上删。用它签名的邮件还在重试队列和转发路径上；删除密钥会追溯性地毁掉它们。旧记录至少保留一周，盯着 DMARC 报告直到旧选择器不再出现，然后再让它退役——最好是改成空的 p=，而不是直接删除。

服务商的检查器说 DKIM 已配置好，可接收方还是报没有密钥。怎么回事？ 几乎总是 CNAME 目标的坑：你的 DNS 面板把你的域名追加到了目标后面（…esp.com.yourdomain.com），于是记录存在却指向空处。dig CNAME selector._domainkey.yourdomain.com +short 会原样显示存储的目标——逐字符与服务商要求的做对比。

把报告发给负责人

如果你是在替客户或雇主修这个问题，用证据来收尾。选择器可解析之后重新运行免费扫描，把评分报告转发给企业负责人：有日期、说人话、DKIM 已在正常验证。这正是网络保险续保和下一份供应商安全问卷需要的材料——一项有效控制措施的证明，而不只是一张已关闭的工单。

免费检查你的 DKIM

查看你的选择器是否可解析——以及确切要修什么——私密进行，仅域名所有者可见。

检查你的域名 → · “DKIM signature not valid” → · 修复 DKIM → · 在 Google Workspace 配置 DKIM → · 仅使用汇总数据。数据在欧盟境内存储和处理。