从需要解释的签名开始
一个有用的 DKIM 检查器以特定签名或确认的发送配置开始。仅询问域名会邀请检查者猜测 选择器 然后报告可能不相关的缺勤。第一个问题是读者正在调查哪条消息、签名域和选择器。如果这些输入不可用，则诚实的结果是尚未识别目标密钥。
本指南指定了建议的诊断方法。它不提供或演示有效的EmailAuth检查器。未导入任何消息、发送DNS请求或验证签名。确切的目录实现大门仍然开放：实现并测试承诺的功能。一篇文章、模型或规范本身并不是一个有效的工具。
在提取字段之前保留证据
为了以后进行授权调查，请在制作经过编辑的工作副本之前将收到的消息保留在受控位置。记录其来源和收集时间。仅复制视觉显示的标头可能会丢弃加密验证所需的折叠、重复字段或主体字节。诊断视图应解释提供了哪些输入以及它是否足以进行所要求的检查。
找到每个 DKIM-Signature 分别字段。读取其 d= 签名域和 s= 选择器，无需替换为可见的发件人地址或提供商熟悉的默认值。其他标签描述了算法， 规范化 并签署材料。多个签名需要单独的行；仅选择第一个可以隐藏与相关的另一个签名 DMARC. RFC 6376 定义签名字段。
构造精确的公钥问题
查找所有者由选择器、 _domainkey标签和签名域组成。在一个纯粹虚构的示例中， d=sender.example和s=mail2026暗示mail2026._domainkey.sender.example 。这是一个构造的名称，而不是执行的查询或观察到的键。当消息不可用时，已确认的提供程序配置可以提供这些值，但该路径证明配置意图而不是实时签名。
保留构造所有者旁边的输入字段并 TXT记录 键入以便其他审阅者可以检查推导。保留任何别名链和解析状态，而不是仅显示最终文本。网络超时、查询被拒绝或服务器故障并不意味着选择器没有键。 DNS响应语义和解析器上下文很重要。 RFC 6376密钥查找 和 RFC 1035.
解释关键记录而不破坏不同的结果
TXT记录可以包含多个字符串，这些字符串共同构成其值。这与接收多个单独的密钥记录不同。建议的检查器应保留记录边界、解析DKIM标签并明确报告格式错误或不明确的数据。空的 p= 值表示撤销，而不是丢失DNS响应。公钥的存在本身并不能证明发送应用程序拥有或使用匹配的私钥。
算法解释必须包括对原始DKIM规范的更新。 RFC 8301禁止使用 rsa-sha1 进行签名和验证，并更新了 RSA 密钥要求。 RFC 8463添加了 Ed25519-SHA256。工具应该声明其支持的算法和版本，而不是将不支持的实现转变为密钥无效的通用声明。这里没有测试任何库、算法实现或安装的工具。 RFC 8301 和 RFC 8463.
单独的查找、验证和对齐
使用三个不同的结论：观察到关键材料、验证提供的签名以及生成的签名身份与作者域一致。每个人都需要不同的证据。密码验证需要相关的消息字节、签名参数和密钥。当前的密钥查找也可能与接收者在较旧的消息到达时看到的不同，特别是在轮换或撤销方面。
值得信赖的 Authentication-Results 断言可以记录接收者报告的内容，但它不能与独立地重新验证已更改的消息互换。在依赖该断言之前先确定接收者和信任边界。相反，编辑签名的标头或正文可以更改验证输入；衍生品的失败并不能自动证明原始产品的失败。 RFC 8601 和 RFC 6376.
欠电流 RFC 9989，当经过身份验证的标识符与作者域一致时，传递的DKIM签名将有助于DMARC 。因此，来自不相关域的有效签名本身是不够的。检查员应标记 结盟 模式和评估的身份，而不是将任何DKIM通行证转换为DMARC通行证。 RFC 9989.
设计一个导致下一步有界的结果
有用的建议结果包含提供的消息引用、提取的 d= 和 s= 值、确切的查询所有者、观察时间、记录解析结果、验证范围和对齐评估。添加支持每个结论的证据并解释未检查的内容。不要通过成功的DNS查找发明绿色实时签名徽章。
如果选择器被猜测，请在建议DNS更正之前请求真实签名或确认配置。如果密钥可用但验证失败，请在建议更换之前调查消息修改、错误的密钥选择和发件人配置。让私钥完全远离检查者。获取客户消息、查询域、共享证据和更改DNS都需要各自的授权范围。
保持承诺的演示出色
确切的原始证据要求是：显示消息到查询链并区分密钥可用性和实时签名。上面的虚构推导解释了该方法，但不满足操作要求。一个可行的实现需要保留对真实选择器提取、记录边界、错误、支持的算法和消息验证的测试，然后才能信任其结果。
来源于 2026 年 11 月 8 日进行了审查。本文仍在准备文件中，有待独立审查、人工技术和隐私批准、实施证据、目视检查和所有者出版物发布。它报告没有完成的查找、测试或产品功能。