DKIM 结盟 是签名验证成功后的身份比对。问题是通过DKIM承担责任的域是否与消息的 From 字段中显示的域相对应。来自不相关服务的有效签名可能会使这个问题得不到解答。
提取正确的域对
使用作者域 RFC5322 .来自 场和 d= 来自成功验证的域名 DKIM签名。不要替代回复， Return-Path， 这 选择器 或可选的 i= 在此比较中签名域的身份。保留原始消息并使用 可信接收者的验证结果，而不是因为签名存在而假设它是有效的。
例如，一条消息显示为 计费 < billing@example.com > 有 example.com 在这个简单的单作者案例中作为其作者域。传递签名 d=example.net 验证签名者的身份 example.net; “计费”一词、熟悉的徽标或相同的邮箱本地部分并不使其与 example.com.
应用配置的对齐规则
RFC 9989第 4.4 节 将严格对齐定义为相同的域。其宽松的规则比较由适用的发现过程确定的组织域。 DKIM对齐模式通过选择 阿德金;当其他适用的策略中缺少该标签时，relaxed 是默认值。
一个精确的 d=example.com 与作者域匹配 example.com 满足严格的一致性，也避免了他们之间关系的歧义。签名来自 mail.example.com 不是严格匹配 example.com。其宽松的状态需要组织领域的确定；不要将每个父子域关系视为在每个可能的策略配置下自动足够。
RFC 9989第 4.10 节 取代 RFC 7489的发现模型与用于组织域发现的DNS Tree Walks。较旧的实现仍然可以使用早期的基于公共后缀的流程。记录您的诊断所针对的规格和接收器行为。过渡时代的差异需要有关发现和政策的证据，而不是一张DNS屏幕截图描述每个接收者的笼统断言。
完成一个明确的轻松示例
假设适用的规则放宽并且接收者确定 组织域 两者的 mail.example.com 和 example.com 成为 example.com。传递签名 d=mail.example.com 然后与作者域对齐 example.com。在严格模式下，同一对不会对齐。
仅将签名结果更改为失败。域关系未更改，但不再提供经过 DKIM 身份验证的标识符。因此，该消息没有来自该签名的DKIM通行证贡献。单独对齐 SPF 通行证仍然可以提供 DMARC 路径，因此不要在不评估整个消息的情况下就得出失败的结论。
这些是带有既定假设的综合案例。在实时调查中，记录发现的策略、对齐模式、相关DNS证据和接收器结果。这使得结论可重复，而不是减少后缀匹配快捷方式的对齐。
从源头更正发送方配置
如果服务仅使用其自己的不相关域进行签名，请确定其当前产品是否支持适当的客户签名身份。获取生成的记录并通过支持的流程激活签名。发布一个 DMARC记录 不改变服务的 d= 值，并且将提供商添加到SPF不会更改DKIM签名。
当打算使用严格模式时，请在更改策略之前验证每个相关路由的精确域签名。不要仅仅为了隐藏非托管发送服务而削弱对齐。同样，不要假设严格模式是免费的：记录它排除的合法子域签名路由以及该限制背后的操作决策。
验证修正后的路线
通过实际应用程序发送，然后捕获传递的签名、其域和可信接收者的DMARC评估。如果有多个签名，请检查所有签名； RFC 9989第 4.4.1 节 接受任何传递的对齐DKIM标识符。来自不同邮箱或租户的测试可能使用不同的身份，并且无法解决受影响的应用程序的问题。
保持一致性和交付结果不同。当预期发件人根据适用策略生成有效的一致身份时，即可证明更正。收件箱的放置仍然取决于收件人的更广泛的决定。
比较三种合成结果
假设作者域example.com和适用的策略。带有d=example.com传递签名在两种模式下都对齐。带有d=mail.example.com传递签名未能严格对齐；仅在两个组织域均为example.com既定假设下，它才以宽松模式对齐。当其组织域为example.net时，带有d=vendor.example.net传递签名在任一模式下均不对齐。在每种情况下，在决定总体DMARC结果之前评估其他签名和SPF 。这些是域比较示例，而不是捕获的接收器结果。
保留紧凑的调查记录
使用此建议的工作表来查看正在审查的路线。它是一种规划辅助工具，而不是已执行测试的证据。
- 消息：应用程序路由、原始消息引用和可信验证接收者。
- 身份：作者域和每个传递的DKIM d 域。
- 策略：发现DMARC策略、adkim 和接收者的发现模型。
- 结论：严格或宽松匹配，其他DKIM / SPF路径，并单独记录交付结果。
相关阅读
多个DKIM签名：找到对齐的传递签名 · DKIM TXT和 CNAME 发布：遵循提供商的密钥管理模型.