更改出站网关可能会更改签名消息，即使其可见目的只是路由邮件。页脚、链接重写、 MIME转换和标题编辑可能会使现有的 DKIM签名。在更改DNS或指责接收提供商之前，找到确切的修改和签名边界。
绘制消息处理顺序
记录应用程序输出、第一签名者、网关转换、最终签名者和接收者。尽可能在网关之前和之后捕获授权的原始消息。保留 CRLF 行结尾和确切的字节；将显示的消息复制到文本编辑器中可以创建在传输过程中从未发生过的更改。
DKIM 签署选定的标头和规范化的正文。检查签名的 d、s、h、c 以及任何正文长度限制。轻松 规范化 容忍特定的格式差异，而不是任意的内容更改。全身签名后添加的页脚通常会更改 正文哈希. RFC 6376、第 3.4、5 和 6 节。
比较纸上的签名边界
假设来自alerts@example.test ，一个有效的原始签名，其中d=example.test并且 选择器 首先，放宽了正文规范化，并且没有 l= 正文长度限制。未提供真实密钥或签名消息。
- 网关改造前：签名有效性是前提，而不是观察到的密码学结果。
- 附加更改规范化完整正文的非空文本页脚后：原始正文哈希不再匹配，因此原始签名在所述假设下将失败。
- 使用d=example.test和选择器 Final 对转换后的字节进行最终授权签名后：正确生成并独立验证的新签名可以提供对齐的DKIM路径。实际的新签名有效性尚未经过测试。旧签名未修复；保留或删除它是一个单独的处理选择。
此书面比较没有发生密钥生成、签名、验证或网关执行。在生产中捕获实际的前/后字节和关键数据，然后测量而不是假设每个结果。
狭义地解释结果
在页脚之后观察到的失败的旧签名将确定此转换破坏了该签名。它并不能确定每次网关修改都会破坏每个签名。未签名的标头可以更改，而不会影响已签名的标头集。规范化还可以在某些空白更改中保持有效性。测试实际的网关功能、 MIME结构和签名设置，而不是从单个文本消息推断。
书面示例假设相同的签名和来自域，但不执行完整 DMARC 发现或接收提供商的政策。 DMARC需要通过对齐的身份验证路径，并且不相关的网关签名域不会自动提供该路径 结盟. RFC 9989。新的有效签名仍必须根据预期的作者身份进行评估。
选择生产签名边界
如果支持，请将最终授权签名置于合法转换之后，否则会更改签名内容。在组织批准的权限下为新签名者配置有效的域和选择器。在引导生产流量通过它之前发布并验证其公钥。根据有意的退休计划，为排队或延迟的消息保留必要的旧选择器。
不要通过承诺宽松的规范化接受任何重写来解决页脚问题。不要将减少签名体覆盖率作为常规解决方法；这会改变签名保护的内容。如果上游签名必须存活，请调整转换或路由并验证确切的字节，而不是假设最终重新签名修复了早期签名。
验证网关割接
通过实际授权路径测试纯文本、HTML、附件和代表性业务模板。比较原始标头、来自受信任接收方的身份验证结果和消息呈现。包括退回处理和队列行为。本地签名通行证根据提供的密钥数据建立加密有效性，而不是收件箱放置、用户信任或每个模板的交付。
回滚标准应确定哪些合法流或身份验证路径失败以及如何恢复旧的处理顺序。再次更改设置之前保留证据。仅在了解新路线和计划的恢复路径后才关闭。