Defaults.Exposed

Defaults.Exposed › 修复 › Guides

换了邮件工具后 DKIM 失败：CNAME 与选择器迁移指南（2026）

发布于 2026-07-08

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

换工具后 DKIM 失败，有两个机械性的原因：你的 DNS 面板把新工具的 CNAME 目标弄坏了——通常是追加了你自己的区域名——或者旧工具的选择器在其邮件排空之前就被删除了。根据 Defaults.Exposed 对 261,086,232 个已评分域名的普查，只有 3.87% 的域名——10,092,481 个——凑齐 SPF+DKIM+DMARC 三件套。

修复顺序：先扫描域名，然后用 dig 检查每个新 CNAME 的已存储目标——以你自己域名结尾的目标就是铁证。在权威域名服务器上修好记录，在把真实邮件切过去之前确认新工具能签名并通过，并在旧工具的流量排空之前保持其选择器发布。

为什么换了工具 DKIM 就坏了？

DKIM 本身什么都没变——变的是你的选择器。旧工具用它的选择器签名；新工具用另一套签名，通常通过接入时添加的两三条 CNAME 记录委托。四个坑几乎解释了所有迁移后的 DKIM 故障：

  1. DNS 面板把你的区域名追加到了 CNAME 目标上。 很多面板把任何粘贴进来的主机名当作相对名，悄悄存成 target.provider.com.yourdomain.com 而不是 target.provider.com。记录存在，面板打着绿勾，可它什么也解析不出来。
  2. 末尾点的困惑。 有些面板要求加末尾点（target.provider.com.）来表示“绝对名——别追加我的区域名”；另一些则把点当作非法输入拒绝，自己处理绝对性。同一个粘贴值在这个面板是对的，在下一个面板就被弄坏。
  3. 旧工具的选择器在切换当天就被删了。 旧工具已签名的邮件还会在重试队列和转发路径里躺好几天；删掉它的选择器——或注销旧账户，从而杀死其委托的 CNAME——会追溯性地弄坏那些邮件。
  4. 你在错误的域名服务器上做了验证。 如果迁移包含域名服务器变更，修好的记录可能只存在于一套 NS 上，而接收方还在查询另一套。

在普查的 261 百万个域名中，只有 51.84% 在扫描时呈现出可发现的 DKIM 密钥（数据截至 2026-06-29）。

同一场迁移通常也会留下 SPF 残骸——1,013,416 个域名（尝试配置 SPF 的域名中约每 138 个就有 1 个）挂着两条 v=spf1 记录，这是换服务商时新增记录而不是合并记录的经典迹象。迁移的那一侧有自己的指南：换了邮件服务商后 SPF 不工作了。

怎么识别一条被弄坏的 CNAME 记录？

别信面板——去问 DNS 它实际存了什么。查询新工具给你的每个选择器的 CNAME 目标。一个示意例子，模仿 SendGrid 风格的委托选择器（你的服务商的目标格式会不同）：

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.yourdomain.com.

服务商要的是 s1.domainkey.u1234567.wl123.sendgrid.net——但存储的目标以 .yourdomain.com 结尾。面板追加了区域名；那个名字什么也解析不出来，接收方于是找不到密钥。健康的版本：

$ dig CNAME s1._domainkey.yourdomain.com +short
s1.domainkey.u1234567.wl123.sendgrid.net.

（dig 输出里的单个末尾点是正常的——它标记完全限定名。）如果目标是对的，再往前跟一跳：dig TXT s1._domainkey.yourdomain.com +short 应当返回服务商的密钥。CNAME 正确却答案为空，说明问题在委托的服务商那一侧——完成他们的验证步骤，或见 DKIM“no key for signature”做选择器级诊断。

迁移操作手册：之前、当天、之后

失败的通常不是记录——是顺序。DKIM 迁移在切换时出事，是因为验证发生在切换之后，那时真实邮件已经在失败了。

阶段做什么过关条件
切换之前添加新工具的 DKIM CNAME（及退信域名记录），然后证明它们没问题：在你的网络之外 dig 每个 CNAME 的已存储目标，完成工具自己的验证步骤，并经新工具向你控制的邮箱发一封测试邮件测试邮件显示 dkim=pass 且 d= = 你的域名——绝不把真实邮件切到未验证的工具
切换当天把真实流量切到新工具。旧工具的一切都别碰：保留其选择器、CNAME 和账户新工具的邮件在真实接收方处通过；仍流经旧工具的邮件继续通过
排空之后盯着 DMARC 汇总报告，直到旧工具的选择器不再出现（重试队列和转发会跑好几天——留出一周以上），然后再退役其记录和账户旧选择器在报告中消失 ≥ 7 天后才移除

加粗那一行是迁移成败之所在：其中每项检查都能在切换前几天完成，对在途邮件零风险。选择器退役的具体操作——包括为什么用空 p= 重新发布胜过删除——见轮换操作手册；这张表讲的是工具切换本身的排序。

切换之后怎么修 DKIM？

  1. 动 DNS 之前，先在 defaults.exposed 运行免费扫描。 它读取你的在线记录，显示接收方实际看到的东西——包括被追加了区域名的 CNAME 目标和无法解析的选择器。
  2. 列出新工具需要的 DKIM 记录。 从它的管理控制台找——邮箱服务商方面，Google Workspace 和 Microsoft 365 配置指南告诉你在哪里；简报和 CRM 工具在域名认证一栏列出它们的 CNAME（见 Mailchimp/Brevo/Klaviyo 邮件 DMARC 失败）。
  3. 用 dig CNAME <name> +short 检查每条记录的已存储值，与工具要求的值逐字符比对。以你自己域名结尾的目标 = 被追加了区域名；重新录入，如果面板还在追加，就加上末尾点（如果面板拒绝点，则去掉它）。
  4. 在权威域名服务器上验证。 dig +short NS yourdomain.com，然后带 @<那台域名服务器> 重复 CNAME 检查。如果迁移改了域名服务器，两套都要查——在委托传播完成之前，接收方可能还在查询旧的那套。
  5. 重跑工具的验证并发一封测试邮件。 Authentication-Results 标头应显示 dkim=pass 且 d= 等于你的域名——在工具默认域名上的通过对 DMARC 不对齐。
  6. 在旧工具的邮件排空之前保持其选择器发布，然后有计划地退役。之后重新扫描，并把修复 DKIM 页面标出的其余问题逐一处理。

常见问题

我的 DKIM CNAME 到底要不要末尾点？ 完全取决于面板。那个点的意思是“绝对名——别追加我的区域名”；有的面板要求它，有的替你加上，有的直接拒绝。唯一算数的测试是保存后 dig CNAME <selector>._domainkey.yourdomain.com +short 的输出：如果目标以你自己的域名结尾，说明面板追加了区域名，你需要那个点（或换一种输入格式）。

切换当天能删掉旧工具的 DKIM 记录吗？ 不能。旧工具签名的邮件还在重试队列和转发路径里，删掉它指向的密钥会追溯性地弄坏那些邮件。让旧选择器一直在线，直到它们不再出现在你的 DMARC 汇总报告里——一周或更久——在那之前也别注销旧账户。

DNS 面板和新工具都说“已验证”，接收方却仍然 DKIM 失败。怎么回事？ 两种常见情形：工具是对着缓存的检查结果验证的，而权威域名服务器提供的是别的东西（用 dig @<ns> 直接查询它们）；或者 DKIM 通过了，但通过在工具的默认签名域名上而不是你的域名上，DMARC 对齐照样失败。扫描能区分这两种。

重叠期里两个工具的 DKIM 记录能共存吗？ 能——而且应该。DKIM 没有单记录规则：每个选择器是各自独立的 DNS 名称，两个工具的记录并排共存互不冲突，这让“保留旧选择器到排空”的规则可以零成本执行。（SPF 恰恰相反——两条 v=spf1 记录会让它作废，所以 SPF 迁移指南讲的是合并。）

把报告发给老板

如果你是在替客户或雇主做这次迁移，用证据收尾。新工具签名且对齐之后，重新运行免费扫描，把评分报告转发给企业负责人：带日期、直白语言，证明切换之后域名的认证依然完整。这正是网络保险续保和下一份供应商安全问卷需要的凭证——它把“迁移做完了”从一句话变成一份文件。

免费检查你的 DKIM

看看新工具的选择器能否解析——以及到底要修什么——私密，仅域名所有者可见。

检查你的域名 → · 换服务商后 SPF 坏了 → · 修复 DKIM → · 在 Google Workspace 配置 DKIM → · 仅使用汇总数据。数据在欧盟境内存储和处理。