DKIM 让域通过加密签名对消息负责。要了解这对特定电子邮件意味着什么，请从收到的原始电子邮件开始，而不是从DNS检查器开始。有用的证据链是消息签名、签名域和 选择器，公钥，接收方验证结果，然后任意 DMARC 结盟 决定。
读取签名的身份
找到每个 DKIM-Signature 原始消息中的标头。 d= 值标识签名域，s= 标识其选择器。对于基于 DNS 的密钥检索，将它们组合为选择器。 _domainkey.signing-domain.签名域可能属于作者的组织、中继或为其代理的服务。 DKIM故意将签名责任与表面作者分开。 RFC 6376 §1, RFC 6376 §3.5, RFC 6376 §3.6.2.
说明性示例：发件人是accounts@example.com ，签名包含d=example.com; s=mail2026.验证程序查找mail2026._domainkey.example.com 。该DNS记录提供公共验证材料。私人签名密钥由授权签名者保留，不得公开。这个例子解释了查找；它不是真正的签名或经过测试的消息。
将存在与成功验证分开
DKIM-Signature标头可能存在，也可能无效。当应用程序根本不发送签名时，可以存在DNS密钥。验证检查签名结构、密钥、选定的标头和正文表示。签名后的更改可能会破坏它，具体取决于更改的内容和 规范化 用过的。看似摘要的字符串并不能证明这些检查已通过。 RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §3.7, RFC 6376 §6.
检查接收系统的可信度 Authentication-Results 或同等日志。了解哪个身份验证服务添加了该结果，以及在何处删除或忽略了不受信任的入站结果标头。发件人可以将看似合理的传递文本插入到消息中，因此任意的Authentication-Results内容都无法证明。 RFC 8601 §1.2, RFC 8601 §7.1.
将结果连接到可见作者
对于DMARC ，将成功验证的 d= 域与 From 中的作者域进行比较。严格的DKIM对齐需要精确匹配 RFC 9989 §3.2.10;宽松的对齐使用组织域发现 RFC 9989 §4.10.2。选择器和可选 i= 值不是用于此DMARC比较的域。如果存在多个DKIM签名，则一个传递的对齐签名可以提供DMARC传递的DKIM路径。 RFC 9989 §4.4.1.
在示例中， d=example.com与 From 域匹配。如果改为d=service.example.net进行验证，原始DKIM将通过，但该不相关的域不会与example.com建立对齐。不要通过编辑收到的标头来“修复”此问题：配置合法签名者以使用适当的受支持身份。
建立有用的调查记录
记录消息时间、路由、来自域、每个 d/s 对、可信DKIM结果和原因、 DNS观察时间和对齐结果。保护原始邮件，因为它可能包含个人或机密信息。编辑副本可能会导致其签名失效；当需要重新验证时，保留访问控制的原件。
如果验证失败，请调查签名是否已启用、正确的密钥是否可用、算法是否受支持以及消息在传输过程中是否发生更改。当前的加密指南取代过时的默认值： RFC 8301 §3.1 禁止使用 rsa-sha1 进行签名和验证； RFC 8301 §3.2 更新 RSA 密钥指南。不要仅仅因为旧教程的语法看起来仍然有效而使用旧教程的加密选择。最后提供收到结果的证据，而不仅仅是DNS包含密钥的证据。
应用区别
对于假设的消息，为每个签名写入一行：d、s、查找所有者、可信验证结果和对齐。如果example.com签名失败，而不相关的service.example.net签名通过，则不要将第一个域与第二个结果组合。调查失败的签名并评估 SPF 在分配DMARC之前单独进行。本文未进行消息验证。