安全的电子邮件网关和 DMARC 解决重叠的操作问题，但不可互换。网关可以检查、路由、隔离或修改消息。 DMARC评估一致的身份验证并向接收者提供域策略信息。重要的问题是您的完整路线的行为方式，包括创建签名后的转换。
绘制实际的消息路径
按顺序记录提交、签名、网关处理和最终接收。确定您控制哪些组件以及每个组件有权签署哪些身份。表示仅启用网关的图表无法确定下游接收器是否获得完整的对齐签名。从授权的测试路径获取原始和最终的原始消息，保留消息标识符和时间。
DKIM 涵盖选定的标头和规范化的正文。即使更改的链接是合法安全功能的一部分，主体重写也会使现有签名无效。 RFC 6376定义了签名和验证行为。 DKIM规范。保留签名的标头列表， 规范化 解释特定故障时的选择和任何身体长度参数。
刻意核对并签字
入站网关可以在修改之前验证消息，但内部结果不会自动信任每个下游收件人。定义下一个系统如何识别可信结果以及它如何处理不可信的标头断言。 RFC 8601。稍后的验证者检查修改的字节可能会出于合法原因得出不同的结果。
对于您管理的呼出路由，在批准转换后签名可以避免破坏最终签名。签名者必须获得其域的授权，并且 结盟 仍需评估。添加来自不相关网关域的有效签名不一定会产生一致的DMARC结果。不要仅仅为了保留签名而删除安全检查，而不审查更广泛的控制设计。
追踪假设的重写
假设授权的brand.test签名者签署了包含URL的消息正文。然后，网关会更改所覆盖的 URL，而无需随后添加授权的对齐签名。如果规范化的签名字节发生更改，则较早的签名将无法针对更改后的正文进行验证。保持相关规范化签名字节不变的转换不需要破坏签名。检查规范化、选定的标头和任何 l= 限制，而不是假设每次重写都具有相同的效果。
如果单独的授权签名者签署最终转换的消息，则即使旧签名失败，新签名也可以验证。它不会修复旧签名或证明新签名者具有业务权限。评估新的 d= 域的对齐和可信的最终接收者结果。这些是基于协议的假设结果，而不是原始消息样本、生成的密钥、dkimpy 输出或执行的网关实验。
将结果转化为路由测试
在生产中，使用受控接收者和供应商支持的配置重现相关的授权转换。捕获最终接收者的可信结果，而不是从网关控制台推断成功。比较整个路线中的相同内容修订，并记下其他更改，例如主题前缀或免责声明。通过的新签名并不能证明早期的身份验证仍然存在。
还测试故障处理。如果签名步骤不可用，请确定邮件是否排队、失败或在没有预期签名的情况下离开。将恢复说明与实际服务联系起来。避免紧急旁路将包含的身份验证问题转变为不受限制的中继或未经检查的传递。
验收记录应注明测试的路线、转换、签名者的位置、最终身份和接收者结果。维护单独的恶意软件过滤检查， 网络钓鱼 检测和域认证。通过一项测试是该功能的有用证据，而不是整个消息或网关安全的证书。
源和执行边界
RFC 9989第 4.4、5.3.5 和 5.4 节 区分认证、对齐和处理；通行证并不认可消息内容。这里的运营决策是范围内的建议和明确的假设示例，而不是对客户、提供商或历史固定装置的新测试。任何真正的改变都需要有自己的授权范围、保留的证据和负责任的决定。