DKIM 密钥怎么轮换才不会造成验签失败？选择器该如何规划？

RFC 6376 第 3.1 节（Selectors）说明，选择器使同一个域可以同时存在多个有效的公钥。签名时通过 DKIM-Signature 的 s= 指定选择器、d= 指定域，验证方据此定位到唯一一条 DNS 密钥记录。

密钥记录的位置由选择器与域拼接而成：

<选择器>._domainkey.<域名>

这正是安全轮换的基础：新旧密钥可以挂在不同选择器上并行存在，互不干扰。第 3.1 节的说明性注记也明确提示，应把新密钥分配给新的选择器，而不是复用旧选择器换新密钥。

直接把旧选择器下的公钥改成新的，会立刻产生一个断层：那些已经用旧私钥签发、但仍在网络中传输或排队重试的邮件，其签名将无法验证。

邮件不是即时消费的——它可能在对端队列中重试数小时甚至更久，也可能被转发后延迟投递。原地替换等于人为制造一批验签失败，而这些失败会直接反映为 DMARC 失败。

RFC 6376 第 5.2 节（Select a Private Key and Corresponding Selector Information）给出的操作建议指出，滚动到新密钥对时，旧公钥应保留一段合理的验证期后再移除。据此的标准流程：

1. 生成新密钥对，分配一个全新的选择器（建议采用可排序的命名，如按年月）。
2. 先发布新公钥到 <新选择器>._domainkey.<域名>，此时暂不切换签名。
3. 等待 DNS 充分传播，确认各处均可查询到新记录后再进行下一步。
4. 切换签名侧，让发送系统改用新私钥与新选择器签名。旧公钥继续保留在 DNS 中。
5. 观察验证期：确认在途的旧签名邮件已基本消化完毕，通过聚合报告确认 DKIM 通过率无异常下降。
6. 最后删除旧选择器记录，并妥善销毁旧私钥。

顺序不可颠倒：任何「先切签名后发公钥」或「先删旧后观察」的做法都会造成验签失败窗口。

规范给出的是「合理的验证期」这一原则性表述，具体时长应由自身链路特征决定。判断依据：

• 对端重试队列的最长生命周期。邮件在对端队列中可能重试较长时间，保留期应覆盖这一窗口。
• 转发与列表的延迟。经中介转发的邮件到达时间更晚，需额外留出余量。
• 报告的滞后性。聚合报告本身有周期延迟，至少要等到覆盖切换时点的报告全部到齐并确认正常，才能删旧记录。

务实建议：宁可多留一段时间。旧公钥留在 DNS 中的成本极低，而删早了造成的验签失败是真实的投递损失。

• 命名可排序、含时间信息，便于一眼看出新旧与轮换节奏，也便于自动化脚本判断该清理哪些。
• 不同发送系统使用不同选择器。各系统独立轮换、互不影响，出问题时也能精确定位到是哪一套在签名。
• 密钥记录的标签由第 3.6.1 节（Textual Representation）定义，含 v、h、k、n、p、s、t 等；其中 p 为公钥数据。p 值为空表示该公钥已被撤销，验证方会据此判定签名无效——这是「主动作废某个选择器」的规范方式。
• 私钥保护是前提。轮换的意义建立在私钥未泄露的假设上；一旦怀疑泄露，应立即启动紧急轮换并撤销旧公钥，而非按常规节奏等待。

• 切换后大面积验签失败：多为新公钥未充分传播就切了签名，或公钥内容在录入 DNS 时被换行/空格破坏。先核对 DNS 中实际返回的 p 值与本地公钥是否完全一致。
• 部分接收方失败、部分正常：典型的 DNS 传播不一致，等待并复查即可。
• 删除旧选择器后出现零星失败：说明仍有旧签名邮件在途，应立即把旧记录加回，再延长观察期。
• 某个发送系统始终失败：检查该系统是否仍在使用已被删除的选择器，或其配置未随轮换更新。