RFC 5863《DKIM 开发、部署与运维》中文导读

摘要

DKIM（DomainKeys Identified Mail）让一个组织能够以可被收件方校验的方式，为一封邮件的传递「声明责任」。该组织可以是作者所在域、原始发送站点、中介，或它们的代理；一封邮件也可以携带来自多个组织的多个签名。DKIM 使用公钥密码学、以 DNS 作为密钥服务器，建立域级别的数字签名认证框架。

RFC 5863 不定义协议本身（协议见 RFC 6376），而是配套的实施、部署、运维与迁移指南：它回答「密钥怎么管」「选择器怎么用」「签名粒度做到多细」「验证失败怎么办」「邮件列表破坏签名怎么处理」这类工程问题。

2. 把 DKIM 用作信任评估的输入

• 只有 d= 是正式的评估输入输出。签名中的 d= 标识才是接收方建立信誉记录的稳定锚点。
• i= 可选且对接收方不透明。它的语义由签名方自定，接收方不应擅自解读其结构含义。
• s= 选择器不宜参与信誉判断。选择器的用途是区分同一域下的多把密钥；若接收方按选择器建信誉，签名方就无法平滑更换密钥了。
• DKIM 只验证标识合法性，不验证内容有效性——包括不保证 From 字段与签名域一致。
• 签名方可为不同邮件流（如交易类、营销类、账单类）使用不同子域作为 d=，从而让接收方能对不同流做差异化评估。

3. 密钥的生成、存储与管理

这是全文最具运维价值的一节。核心观点是：私钥的保密性远比更换频率重要。

"An operational practice in which the private key is stored in tamper-proof hardware and changed once a year is considerably more desirable than one in which the signature key is changed on an hourly basis but maintained in software."（§3.1）

译：把私钥存放在防篡改硬件中、每年更换一次的运维实践，远优于每小时更换一次但仅以软件方式保管密钥的做法。

• 最小持有：私钥应由尽可能少的人员/系统掌握；相关人员离职时须撤销其可触达的密钥。
• 软件存储的底线：严格的文件权限；明文私钥不进备份。
• 选择器策略：按管理需要分配选择器，例如滚动密钥、委托给第三方可信方（TTP）时各用一个。
• 第三方签名：应由第三方自行生成密钥对，只把公钥交给域持有者发布；域持有者授予最小权限，最好不开放整个域的 DNS 写权限。
• 生命周期与终止：部署与停用流程都要文档化。停用某选择器时，可发布空 p= 的「墓碑」记录，防止该选择器被复用或被误认为仍然有效。

4. 签名侧的实现与部署

• 签名方只需两样东西：一个可发布记录的 DNS 管理接口，以及一个受信任的签名模块。
• 签名模块可置于 ADMD 内的任意位置（常见于出口边界 MTA），签名策略应运行时可配置，不要硬编码进程序。
• DNS 侧需支持含下划线的 _domainkey 名称与 TXT 记录发布。
• 规范未规定签名模块如何取得私钥，但为便于轮换与隔离，不应把密钥硬编码进软件。
• 粒度警告：签名粒度切得过细会显著增加管理开销，而接收方往往只取域名右侧子串做判断，结果是把 DKIM 降级成一种启发式规则。

5. 验证侧的实现与部署

"It follows that messages with invalid signatures need to be treated no better and no worse than those with no signature at all."（§5.1）

译：由此可知，带无效签名的邮件应当与完全没有签名的邮件同等对待——不更好，也不更差。

• 验证只提供认证，必须与信誉/策略结合才能构成访问控制决策。
• 只有落在签名范围内的内容才算被认证；使用 l= 指定长度时，超出部分未被覆盖，存在被追加内容的风险。
• 验证本身有其局限：私钥失控、DNS 被劫持等情况下，签名有效并不等于安全。
• 若把「验证」与「结果应用」拆分到不同组件（典型是用 Authentication-Results 传递），必须防范伪造结果头；中介应删除无法自证来源的入站结果头。

关于中介与邮件列表：

"Such intermediaries are strongly encouraged to deploy DKIM signing so that a verifiable claim of responsibility remains available to parties attempting to verify the modified message."（§5.5）

译：强烈建议此类中介部署 DKIM 签名，以便在邮件被修改后，试图校验的一方仍能获得一个可验证的责任声明。

6. 签名分类

原文按签名方与作者域的关系给出分类：单域签名（d= 与作者域一致）、父域签名、第三方签名、以及多重签名。文档明确：第三方签名的价值取决于接收方如何解读，与 From 是否匹配无必然关系；而业界对「一封邮件带多个签名时如何处理」尚无共识。转发者若破坏了原始签名，应补上自己的签名。

7. 典型使用场景

• 简单场景：全域单一 d=，i= 按需变化。
• 差异化邮件流：营销、账单等各用一个子域，便于收件方分别累积信誉。
• ADSP 场景：若发送域确认已对所有出站邮件签名，可发布 ADSP 记录（dkim=all 或 discardable）；前提是必须彻底排查所有出站来源，否则会误伤合法邮件。
• 委托签名：外包服务商生成密钥对，由域持有者发布公钥，或将子域的 DNS 委托给服务商；即便邮件由外包方物理发出，签名域仍可以是 d=benefits.companya.example 这类归属明确的子域。

8. 使用注意事项

• 非标准提交路径（用户在 ISP 侧使用多个地址、第三方转发等）往往拿不到权威私钥，因而不会出现「预期中的域签名」。
• 内部仿冒防护：当组织对全部邮件签名后，边界 MTA 就能识别出「声称来自内部、却没有有效签名」的仿冒邮件——这是 DKIM 在企业内的一个高价值用法。
• 每用户密钥不现实：接收方多数只看基域信誉，且 DKIM 协议内并无表达「本签名代表某个具体用户」意图的机制。

9-11. 安全考量与参考

安全考量提示读者正视 DKIM 的能力边界（尤见 §5.3 所述验证局限）：DKIM 解决的是「谁为这封邮件负责」，不解决「这封邮件的内容是否可信」。参考文献分规范性与资料性两类，含 RFC 4871、5617、5672 等。

附录 A. 迁移策略

• A.1 从 DomainKeys（RFC 4870）迁移到 DKIM：给出并行期与切换步骤。
• A.2 / A.3 哈希与签名算法迁移：讨论在不中断验证的前提下更换算法的过渡方式——这对今日从 rsa-sha1、1024 位密钥升级的组织仍有直接参考价值（另见 RFC 8301、RFC 8463）。

参考链接

• RFC 5863 英文原文：https://www.rfc-editor.org/rfc/rfc5863.txt
• IETF Datatracker 页面：https://datatracker.ietf.org/doc/html/rfc5863
• DKIM 协议本体 RFC 6376：https://www.rfc-editor.org/rfc/rfc6376
• DKIM 服务概览 RFC 5585：https://www.rfc-editor.org/rfc/rfc5585
• DKIM 密钥长度更新 RFC 8301：https://www.rfc-editor.org/rfc/rfc8301