A DKIM-Signature 是一组用分号分隔的标签，描述域如何对消息进行签名。阅读这些字段可以帮助您选择正确的DNS查找和调查路径。它不允许您通过肉眼验证密码。在复制或重新格式化签名以供检查之前，请保留原始消息。
从查找和算法字段开始
所需的d=值为签名域； required s= is the 选择器。使用正常的DNS TXT查询方法，这些会导致 s。 _domainkey.d. a= 标签标识签名和哈希算法。对于RFC 6376签名语法，所需的 v= 标记必须具有值 1。这与DNS密钥记录中的版本标记不同。这些值描述签名，而不是其验证结果。 RFC 6376 §3.5, RFC 6376 §3.6.2.
说明性片段，故意不完整且不是有效签名： d=example.com; s=outbound2026; a=rsa-sha256; c=relaxed/relaxed; h=from:to:subject:date.其查找名称为outbound2026._domainkey.example.com 。它是 canonicalisation 对标头和正文使用宽松的处理。其签名标头列表命名选定的标头字段。该片段省略了所需的加密值，并且绝不能用作生产记录。
区分内容覆盖率和签名数据
h= 标签按照定义的顺序列出了提供给签名操作的标头字段。它不是哈希算法。发件人必须包含在有效的DKIM签名中。重复的头部名称和重复的消息字段需要规范中的选择规则；随意浏览一下列表并不能解决所有的覆盖问题。
The bh= tag holds the 正文哈希。 b= 标签保存签名值。匹配或看似合理的编码并不能证明有效性。 c= 标签描述规范化，它允许对签名表示进行特定的规范化。它不允许任意重写消息。如果省略c=，则默认为simple/simple；如果只命名一种算法，则它适用于标头，而正文默认为简单。 RFC 6376 §3.4, RFC 6376 §3.5, RFC 6376 §5.4.
可选的 l= 标签限制了所包含的规范化主体八位字节的数量。它的存在需要小心：有效的签名可能不涵盖超出该长度的附加内容。不要描述每一个 DKIM 作为每个可见字节未更改的证明。 RFC 6376 §3.5, RFC 6376 §8.2.
仔细解读身份和时间
可选的 i= 值是根据签名域规则声明的代理或用户标识符；它不一定是一个工作邮箱。 DMARC 对于DKIM使用经过验证的d=,而不是i=, 结盟。 t= 和 x= 标签描述签名时间和签名到期时间。 RFC 6376 §3.5 正式将两者标记为“推荐”，尽管它们可能不存在。它们是签名元数据，而不是实际SMTP到达时间的证明。保留收到的标头和系统日志以进行传输分析。
使用过时加密技术的签名不应仅仅因为其字段解析而被接受。 RFC 8301 §3.1 prohibits rsa-sha1; RFC 8301 §3.2 更新 RSA 密钥要求。使用受支持的验证软件和当前提供商指南，而不是根据本现场指南手动实施这些检查。
完成接收结果
收集d/s对、算法、相关覆盖字段、可信DKIM结果和失败原因。如果DNS丢失，请调查确切的所有者名称和密钥生命周期。如果密钥可用但验证失败，请在不更改原始证据的情况下比较签名和传递路径。使用新发送的消息和可信接收者结果确认任何补救措施。目标是对签名进行合理的解释，而不是视觉上的通过/失败猜测。
应用区别
阅读四组说明性片段：d/s 选择身份和查找； a/c 指定算法和规范化； h 和任意 l 定义覆盖范围； b/bh 携带软件验证的值。缺少必需的 v/b/bh 意味着该片段不是有效签名。如果l=0出现在真实签名中，则零个主体八位字节将被散列，因此主体完整性不受保护； RFC 6376 §3.5 定义该长度机制。这些观察结果都不是密码学通行证。