一条消息有几个 DKIM 签名需要对每个签名进行评估。计算签名或选择第一个通过的结果可能会错误地识别对可见作者进行身份验证的域。在下面 RFC 9989 §4.4.1，任何与作者域一致的经过 DKIM 验证的标识符都可以提供DKIM路径 DMARC 经过。
保留每个结果的身份
通过批准的流程导出原始消息。记录可见的 From 域，并且对于每个签名，其 d= 签名域名， s= 选择器, a= 算法及相关 规范化 设置。将可信接收系统的结果与该签名相关联。两个签名可以使用相同的域但使用不同的选择器或算法，因此仅凭域可能无法区分它们。
不要轻信任意的 Authentication-Results 字段仅仅是因为它出现在消息中。 RFC 8601 §1.2 解释了这些字段的信任边界。使用您正在调查其评估的接收系统的结果，并在导出证据时保留该来源。发件人可以插入误导性的标题文本；复制的状态标签不是独立的验证。
将验证和调整作为单独的决策
验证确定签名是否对其签名域有效。 结盟 将该经过身份验证的域与适用DMARC规则下的作者域进行比较。不相关的提供商的签名可以完全有效，无需验证作者的DMARC可见域。
为了严格的DKIM对齐，域必须完全匹配，下面是域名大小写比较 RFC 1035 §2.3.3。宽松对齐使用由适用的DMARC流程确定的组织域关系。 RFC 9989 §4.10.2 为此确定定义了DNS树遍历。不要根据两个域名中的共同单词来决定对齐，也不要默默地假设每个接收者都采用了最新的发现实现。
处理合成消息
假设有效的适用DMARC策略，作者域为 example.com 并且没有对齐 SPF 经过。签名 A 使用 d=example.net，验证成功，未对齐。签名 B 使用 d=example.com 但下游内容更改后验证失败。两者都不提供对齐的传递DKIM身份，因此此组合不会生成DMARC通行证。
现在添加签名 C d=example.com 即验证成功。它精确对齐，因此它提供了DMARC传递的DKIM路径。不相关的通过和失败签名不会自动取消 C。这是一个说明性评估，而不是有关捕获的客户消息或保证邮箱放置的声明。
将示例写入调查记录中的单独列中：签名标识符、验证结果、对齐结果和对DMARC的贡献。切勿将签名 A 的通行证与签名 B 的对齐域相结合来制造单个签名无法实现的结果。
解释为什么有多个签名
并行算法、提供商的操作签名和中间人的后期签名都可以创建多个结果。在路由和签名者配置确定原因之前，这些都是假设。 RFC 8463 §6 描述了 RSA 的不同选择器和 埃德25519 转换签名；他们的结果应该单独跟踪。
如果网关重新签署修改后的邮件，请检查其新域。通过网关签名不会自动修复原始作者的身份验证。如果组织控制最终签名阶段，请验证其是否以批准的身份签署预期的后处理内容。在未检查其操作目的之前，请勿删除明显多余的签名。
以消息级结论结束
评估所有相关的DKIM签名后，分别评估SPF的经过身份验证的标识符和对齐方式。如果未发现适用的DMARC策略，请勿将该情况重新标记为正常DMARC故障。将身份验证结果与接收者的最终处置区分开来，这可以反映附加策略或过滤。
保留原始消息、可信结果来源、每个签名分析以及最终结论的原因。如果报告工具以不同的方式聚合签名，请在将不同的摘要视为协议矛盾之前比较其原始证据。有用的结果是一条可解释的身份路径，而不仅仅是大量的绿色指标。
记录示例，不混合身份
对于上面的合成消息，每个签名保留一行：
- 答： example.net ；验证通过；对齐编号； DKIM对DMARC贡献
- B： example.com ；验证失败；域将匹配但未经过身份验证； DKIM贡献编号
- C： example.com ；验证通过；对齐是； DKIM贡献是的。
在 C 出现之前，所声明的未对齐SPF不存在任何通过路径。如果存在 C， DMARC将通过假定的适用策略。不声明实际的接收者结果或收件箱放置结果。
相关阅读
DKIM对齐：将 d= 与可见的 From 域进行比较 · RSA 和 Ed25519 DKIM签名：部署问题和互操作性.