将修改历史视为证据，而不是许可
出于合法原因，邮件列表可能会添加页脚或修改主题字段。敌对的中间人也可以更改消息。重要的问题不仅仅是事情是否发生了变化，而是接收者是否能够重建相关历史、验证责任域并决定该历史意味着什么。 DKIM2提出了前两项任务的机制；它不会自动回答第三个。
此解释固定于 draft-ietf-dkim-dkim2-spec-09，日期为 2026 年 11 月 1 日，目前是一个活跃的互联网草案。其提议的验证状态涉及未声明的修改和交付路径的一致性。第 14.1 节明确地将这些检查与消息的值或声明的更改的良性分开。经过验证的链并不是一揽子信任建议。
建立一条原创但明显虚构的道路
考虑三个发明的系统： author.larch.example 、 list.fir.example和inbox.birch.example 。第一个创建一条消息，其正文由两行组成：“议程”和“星期五中午”。该列表附加第三行“列表页脚”，而不更改正文。假设域、信封地址、时钟和密钥满足相关检查。这些是规定的教学输入，而不是捕获的消息或任何签名验证的证据。
在最初，建议的表示包括消息实例m=1以及原始标头和正文哈希值，以及引用该实例的 DKIM2-Signature i=1 。列表更改后，第二个实例记录当前哈希值以及重建早期表单所需的信息。该列表添加了自己的签名以及适当的序列和实例引用。本示例中有意未发明哈希值和签名字节。
解释为什么食谱会倒退
第 5 节和 12.1 节 描述重新创建早期消息内容的方法。在虚构的正文情况下，重建原始意味着保留前两行并排除附加的页脚。该配方解释了如何从新状态恢复旧状态；它不仅仅是一条“添加页脚”的指令。真正的装置需要字节精确的内容和草案的精确编码规则。
标头更改变体需要其自己的重建证据。如果主题前面有一个列表，则原始值必须可以为早期的标头哈希检查恢复。将原始字段、修改字段和配方记录在一起，以便审阅者可以确定是否忠实地表示了更改。不要依赖渲染的邮件客户端屏幕截图，它可能隐藏与验证者相关的折叠、编码和重复字段详细信息。
验证超过最新的签名
在下面 第13条，完整验证检查通过按降序应用后来的配方重建的早期消息实例以及签名链。仅检查最终显示的正文和最近的签名是一种不同的、范围更窄的操作。草案单独明确了有限初步评估的临时核查；两个结果不应共享不合格的绿色徽章。
接收者还需要传递上下文。 14.4节将最新签名的信封信息与实际的SMTP事务进行比较，而较早的跃点必须满足链式规则。第 14.8 节根据适当的签名身份检查相关的当前和历史发件人字段。如果仅包含内容的档案丢失了原始信封和接受时证据，则无法满足所有这些条件。
因此，对于虚构路径，预期的审查顺序是：检查语法和排序、保留SMTP上下文、检查时间戳、验证链和密钥、验证签名、重建每个相关实例、比较哈希值并评估真实性。这是建议的推理轨迹。这并不是声称特定软件包执行了这些步骤或返回了 PASS。
保持空配方和密文可见
该草案允许使用空体配方来表明无法重建较早的身体。它不允许头更改为空配方。这种区别对于删除机密材料的网关很重要：可逆配方可以保留网关想要删除的内容。隐私审查应该检查配方有效负载，而不仅仅是收件人可见的最终正文。
Core -09 第 13 节表示无法检查空配方下方的早期正文哈希，并且该消息未经过完全验证。然而，当地政策可能会接受它，例如在适当的关系下。这并不等同于以加密方式恢复丢失的证据。实验室应报告不可用的历史身体检查和单独的本地验收决定，而不是将结果重命名为完整验证。
不要将请求与可执行的信任混淆
分开的 可以修改-00草稿 探索发起者关于修改的请求。它于 11 月 2 日作为个人互联网草案发布。它的治疗是当地政策，一些善意的讨论显然还没有结束。它不应该作为通用部署权限系统合并到核心-09中。
这为运营商带来了实际的区别。配方可以支持归属，发起者请求可以表达偏好，接收者可以决定是否接受结果消息。没有一个单独的证据可以证明修改后的消息是安全的。审阅者注释应确定观察到的结果实际回答了哪些问题，特别是当产品报告使用“可信”一词但未对其进行定义时。
保留准确缺失的验证证据
确切的委托是：通过版本固定的草稿模型追踪一条原始、修改和验证的消息。原始虚构跟踪提供了预期的结构和检查，但此包中不存在签名消息、计算哈希、兼容验证器输出或实际验证结果。调试证据之门仍然打开，而不是被插图关闭。
未来的授权实验应保留消息形式、重建数据、信封元数据、关键快照、软件版本和完整的验证者诊断。包括未声明的更改控件和空配方变体。技术和隐私专家必须在实际使用之前审查解释和暴露。生产适用性、目视审查和业主出版批准也很出色；这里没有提出任何迁移或普遍信任的主张。