在转发之前进行验证并在之后失败的消息需要对签名字节和签名上下文进行比较。不要假设每个添加的标头都会中断 DKIM 或放松的 规范化 允许任意编辑。签名标识受保护的标头字段、规范化和 正文哈希。在决定哪种转变重要之前重新构建这些选择。
保存可比较的文物
参考： RFC 6376 §3.5, RFC 6376 §3.7.
保留原始的原始消息和最终消息，而无需通过可能规范行结尾或重新编码MIME客户端打开和重新保存。记录签名者域名， 选择器、算法、签名标头列表、规范化和任何正文长度限制。保留验证者输出和DNS密钥观察结果以及时间戳。视觉上相同的消息可以具有不同的编码字节。
在处理链中找到签名者。最终签名之前添加的页脚是签名内容的一部分；签名后附加的相同页脚可能会使正文哈希无效。清单列出软件、网关、免责声明引擎、防病毒重写器和归档路径作为可能的转换点。只有来自实际路线的证据才能确定是哪一个行动的。
了解规范化允许什么
参考： RFC 6376 §3.4, RFC 6376 §5.4, RFC 6376 §8.2.
RFC 6376，第 3.4 节，定义了简单且宽松的规范化。宽松的正文处理规范指定的空白和尾随空行。它不会使添加的段落或更改的金额消失。标头规范化有其自己的规则，不应被正文规则取代。
主题前缀会影响覆盖相关主题字段的签名。仅仅添加不相关的未签名标头是一种不同的情况。重复的签名字段和标头选择需要验证者的规则，而不是随意的视觉差异。如果签名包含正文长度限制，请了解未覆盖内容的风险；不要引入该选项作为使任意页脚安全的便捷方法。
运行真实的主体哈希比较
参考： RFC 6376 §3.4.4.
本地固定装置将宽松的主体规范化应用于三个合成主体。它为原始版本、纯空白版本和添加页脚的版本计算 SHA-256 和 base64。原始大小写和空白大小写匹配；页脚大小写不同。生成的原始和修改后的 .eml 文件保留说明性正文字节以供检查。
这是观察到的哈希转换，而不是 DKIM签名 确认。不涉及私有签名密钥、 DNS密钥查找、标头签名或可信接收服务。对完整签名的预期效果仍然取决于覆盖已更改字节的实际签名。下面保留的证据记录了历史本地签名和前后验证；生产路线证据仍未收集。
在削弱覆盖范围之前修复排序
参考： RFC 9989 §4.4.1, RFC 9989 §5.3.5.
如果可能，请在合法域的最终签名步骤之前应用所需的转换。对于无法代表原作者签名的中介，保留原始签名内容可能会保留对齐的通行证。来自中介的替换签名验证其自己的域，并且不会自动与原始发件人地址对齐。 RFC 9989 提供单独的比较。
使用完整的验证程序和代表性MIME内容重新测试相同的转换。包括附件、多部分替代项和非 ASCII 消息（如果它们在范围内）。保留阴性对照，这样测试就不会仅仅因为签名消失而成功。闭包应该说明哪个转换发生了变化，哪个签名现在验证了以及该签名是否在最终接收者处提供了一致的身份验证。
保留的实验室证据
参考： RFC 6376 §6.
在 2026 年 11 月 7 日的捕获中，临时 2048 位 RSA 密钥在转发之前使用 dkimpy 对原始字节进行签名。密钥的公共DNS记录将被保留，私钥将在执行后被删除。 dkimpy 验证原始消息和保留转发消息并拒绝添加页脚的正文。列表案例在创建其列表域签名之前应用归因和页脚更改，并进行验证。这些是真正完整的DKIM签名测试，不提供布尔结果。放松身体助手现在还将空输入处理为零八位字节。
对保留的赛跑者和2026年11月7日捕获的赛跑者进行了检查；本次审查没有重新运行网络实验。最初的实验仅使用环回并且不发送互联网邮件。它的接收者创建 Authentication-Results 根据其自己的检查，使这些字段具有已知的实验室来源。身份验证结果和处置保持独立：所有六个SMTP样本均在显式捕获策略下收到 250，包括失败样本。信任边界是这个受控实验室，而不是生产邮箱提供商。 DNS适配器提供保留的固定答案而不是查询公共DNS ，并且 DMARC 评估器仅使用严格的域相等。完整的组织域发现、生产策略解析和实时部署结果尚未经过测试。