DKIM2：让每封邮件经手的系统都签名负责

邮件安全的老问题一直没被真正解决：一封邮件从发件人到收件人，中间要经过多少系统、每个系统到底做了什么，现有协议基本说不清楚。DKIM2 提出的思路很直接——凡是碰过这封邮件的系统，都得为自己做过的事签名。

现有邮件认证的盲区

DKIM 的设计初衷是验证发件域名的真实性，它给邮件加上一个与域名绑定的签名，收件方可以据此判断邮件是否来自声称的域名、内容有没有被篡改。但 DKIM 的签名覆盖的是「发件方」这一端的行为，邮件离开发件服务器之后的旅程，它管不了。

邮件的实际路径往往要经过转发服务、邮件列表、安全网关、归档系统等多层中间节点。这些系统可能改写头部、追加标签、剥离附件，甚至重写正文。传统 DKIM 对这些后续改动要么直接失效，要么只能靠宽松的对齐策略勉强过关。结果是，收件方拿到的认证结果，和邮件真正经历了什么之间，存在一段说不清的空档。

DKIM（DomainKeys Identified Mail）是 IETF 标准化的邮件认证机制，其核心是发件服务器用与域名绑定的私钥对指定头部字段和正文计算哈希后签名，公钥则发布在 DNS 的 TXT 记录中，收件方通过查询 DNS 验证签名。签名中通常包含 d=（签名域名）和 i=（身份标识）等标签，并允许通过 l= 标签限定被签名的正文长度。这种设计天然假设邮件离开发件域后内容基本不变，因此一旦中间系统改写内容（哪怕只是追加一条页脚），签名就会失效。DKIM 本身并不规定邮件被拒收或标记，它只输出验证结果，具体处置取决于 DMARC、SPF 等策略组合。

DKIM2 的核心主张

DKIM2 把签名的主体从「发件域名」扩展到「每一个处理过邮件的系统」。根据 Hacker News 上对该项目的介绍，其基本主张是：每一个经手邮件的系统，都对自己执行的操作签名。

这意味着邮件在传递链上每经过一跳，就多一层可验证的操作记录。转发服务签「我转发了这封邮件」，网关签「我做了哪些检查、是否修改了内容」，收件端可以沿着这些签名逐层核验，而不是只看到一个最终的通过或不通过。

这种设计把邮件的处理历史变成了一条可追溯的凭据链，而不是一个二值的认证结论。

与现有协议的关系

DKIM2 并不是要推翻 DKIM。从命名和定位看，它更像是把 DKIM 的签名机制延伸到邮件传输的每一跳，让「谁做了什么」这件事本身成为可验证的对象。

对邮件列表和转发场景来说，这点尤其关键。传统 DKIM 在转发后签名失效，是长期困扰邮件投递的难题，各种变通方案都只能缓解。如果每个中间系统都对自己的改动签名，收件方就能区分「原文被合法转发服务修改」和「内容被恶意篡改」，而不必在两者之间二选一。

邮件列表和转发场景中，传统 DKIM 的失效问题通常通过几种变通手段缓解：一是 ARC（Authenticated Received Chain），它允许中间节点在保留原始认证结果的基础上追加自己的签名链，使收件方能看到邮件在每一跳的认证状态；二是改写 From 域（如邮件列表将发件人地址替换为列表地址），以牺牲原始身份为代价换取对齐通过；三是宽松对齐策略，接受子域或近似域名的签名。DKIM2 与 ARC 的差异在于，ARC 主要保护的是「认证结果」在转发过程中的完整性，而 DKIM2 的签名对象是「中间系统执行的操作」本身，粒度更细，也更强调对处理行为的追责，而不仅是对认证结论的传递。

落地面临的现实问题

这个思路在逻辑上清晰，工程上却有不少硬骨头。

一是部署惯性。邮件生态的兼容性要求极高，任何新签名机制都必须与大量存量系统共存，逐步渗透的速度不会快。二是签名链的信任模型需要明确：中间系统的签名由谁背书、收件方凭什么信任某一跳的密钥，这些问题的答案决定了 DKIM2 是成为可用的信任基础设施，还是沦为又一层可以伪造的标记。三是隐私与存储成本，每一跳的签名都会增加邮件体积，并留下处理路径的痕迹。

Hacker News 上的这条讨论目前热度不高，说明它还处在早期曝光阶段，社区尚未形成充分的实践反馈。这也意味着上述问题更多是开放式疑问，而非已有定论。

邮件签名链的信任模型可以类比证书链或透明日志（Certificate Transparency）的思路：中间系统的签名若要被收件方采信，需要解决公钥发现、密钥归属证明和撤销机制三个问题。DNS 是现成的公钥分发渠道（DKIM 本身即依赖 DNS），但 DNS 记录的可信度受限于 DNSSEC 的部署率；另一种可能是引入独立于邮件协议的信任锚或联盟白名单，但这会带来治理和准入问题。此外，签名链越长，验证成本和故障面越大——任何一跳的密钥过期或配置错误都可能导致整条链验证失败，因此需要设计降级策略，明确「链不完整时收件方应如何处置」，否则可能重蹈 DMARC 早期因策略过严而误伤合法邮件的覆辙。

值得关注的方向

邮件认证的演进一直偏保守，但也正因如此，任何把「处理过程可验证」引入邮件链路的尝试都值得留意。DKIM2 的价值主张在于把认证的粒度从「谁发的」推进到「谁做了什么」，这个方向如果走通，对邮件可信度的提升是结构性的。

短期内更现实的观察点，是它能否在转发和邮件列表这类痛点场景中拿出可运行的参考实现，以及社区是否愿意围绕中间系统的签名信任问题形成共识。