DKIM 验证：电子邮件认证最佳实践
鸟
2017年4月8日
电子邮件
1 min read
关键要点
DKIM (DomainKeys Identified Mail) 是一种基于内容的电子邮件认证方法，用于验证邮件在签名后是否被更改。
与 SPF 验证发送路径不同，DKIM 使用加密签名验证邮件内容本身。
DKIM 使用两个密钥：一个用于签署外发邮件的私钥和一个发布在 DNS 中供接收者验证签名的公钥。
DKIM 签名包括邮件头和正文的哈希值、选择器、时间戳和身份字段，所有这些接收者都必须再现和验证。
DKIM 验证依赖于先接收完整的消息，这意味着故障可能在过程的后期发生。
故障排除失败的 DKIM 验证通常很困难，因为发送者和接收者无法重现彼此的签名/验证环境。
即使 DKIM 失败，也通常不会自己直接导致收件箱问题，除非与其他负面声誉信号结合。
Q&A 精华
DKIM 实际上有什么作用？
DKIM 将加密签名附加到电子邮件上，使接收服务器能够确认消息内容在发送后是否被修改。
DKIM与SPF有何不同？
SPF 验证 谁 被允许为一个域发送邮件（基于路径）。
DKIM 验证 内容 是否完整（基于内容）。
两者目的不同，但相辅相成。
DKIM-Signature 标头内部是什么？
关键字段包括：
v= 版本
a= 算法
c= 标准化规则
d= 签名域
s= 选择器
h= 包含在签名中的头部
bh= 正文散列
b= 实际签名数据
每个部分都对签名验证有贡献。
接收服务器如何验证DKIM？
提取 d= 和 s= 值。
在以下位置查找公钥：
selector._domainkey.domain
重新生成标题和正文的哈希值。
将它们与电子邮件中的 bh= 和 b= 值进行比较。
如果匹配，消息通过 DKIM。
是什么原因导致DKIM失败？
消息在传输中被更改（如果使用严格的规范化，甚至空白也会发生变化）
DNS中公钥不正确或缺失
DNS格式错误
选择器被移除或错误旋转
身份不匹配（i=必须与d=相同域或子域）
为什么 DKIM failures 可能会很难 troubleshoot？
因为签署者和验证者在完全不同的环境中运行——双方都无法重建对方的哈希条件或签名状态。
这使得不透明的“哈希不匹配”故障成为最令人生气的诊断问题。
DKIM 失败是否意味着电子邮件会进入垃圾邮件？
不一定。
DKIM 只是一个信号。如果域名声誉良好并通过其他检查（SPF、DMARC 对齐、低投诉率），单独的 DKIM 失败通常不会对 Inbox 产生影响。
为什么要使用 DKIM？
保护信息的完整性
建立域名声誉
实现DMARC对齐
帮助邮箱提供商区分合法发件人与欺骗者
DKIM被视为所有严肃电子邮件发件人的最佳实践。
当我们谈论“邮件认证”时，我们指的是一种向邮件接收者提供一定程度确信的方法，即邮件确实来自所声称来源的技术。这类技术背后的理念是建立起某种程度的防御，以防止欺诈性邮件，例如钓鱼和欺骗邮件，这些邮件可能削弱接收者对接收邮件的信任。不过，发送经过认证的邮件并不意味着该邮件是好的或受欢迎的；它仅仅意味着可以可靠地建立经过认证方的声誉，并在邮件接受和放置决策中使用。
目前，使用中有两种形式的邮件认证：
发送者政策框架 (SPF)
域名密钥识别邮件 (DKIM)
在今天的文章中，我将介绍DKIM是什么以及它如何运作。
当我们谈论“邮件认证”时，我们指的是一种向邮件接收者提供一定程度确信的方法，即邮件确实来自所声称来源的技术。这类技术背后的理念是建立起某种程度的防御，以防止欺诈性邮件，例如钓鱼和欺骗邮件，这些邮件可能削弱接收者对接收邮件的信任。不过，发送经过认证的邮件并不意味着该邮件是好的或受欢迎的；它仅仅意味着可以可靠地建立经过认证方的声誉，并在邮件接受和放置决策中使用。
目前，使用中有两种形式的邮件认证：
发送者政策框架 (SPF)
域名密钥识别邮件 (DKIM)
在今天的文章中，我将介绍DKIM是什么以及它如何运作。
当我们谈论“邮件认证”时，我们指的是一种向邮件接收者提供一定程度确信的方法，即邮件确实来自所声称来源的技术。这类技术背后的理念是建立起某种程度的防御，以防止欺诈性邮件，例如钓鱼和欺骗邮件，这些邮件可能削弱接收者对接收邮件的信任。不过，发送经过认证的邮件并不意味着该邮件是好的或受欢迎的；它仅仅意味着可以可靠地建立经过认证方的声誉，并在邮件接受和放置决策中使用。
目前，使用中有两种形式的邮件认证：
发送者政策框架 (SPF)
域名密钥识别邮件 (DKIM)
在今天的文章中，我将介绍DKIM是什么以及它如何运作。
DKIM 概览
与其认证对应物SPF不同，SPF提供了一种方式让域授权主机代表其发送邮件，DKIM提供了一种方式让一个实体（域、组织、个人等）对邮件负责，这与实际发送邮件的实体无关。虽然在许多情况下，责任实体和发送实体是相同或至少紧密相关的，但在DKIM中没有要求必须如此。
我希望通过这篇文章，你能学习和理解关于DKIM的以下概念：
DKIM是一种"基于内容"的认证，与"基于路径"的SPF不同。
责任实体通过在邮件头中插入一对加密哈希“签署”邮件来断言其责任。
DKIM验证由接收域尝试生成相同的两个哈希完成。
在许多情况下，DKIM 验证不能完成，直到发送服务器传输完整消息。
验证失败可能很难排查。
与其认证对应物SPF不同，SPF提供了一种方式让域授权主机代表其发送邮件，DKIM提供了一种方式让一个实体（域、组织、个人等）对邮件负责，这与实际发送邮件的实体无关。虽然在许多情况下，责任实体和发送实体是相同或至少紧密相关的，但在DKIM中没有要求必须如此。
我希望通过这篇文章，你能学习和理解关于DKIM的以下概念：
DKIM是一种"基于内容"的认证，与"基于路径"的SPF不同。
责任实体通过在邮件头中插入一对加密哈希“签署”邮件来断言其责任。
DKIM验证由接收域尝试生成相同的两个哈希完成。
在许多情况下，DKIM 验证不能完成，直到发送服务器传输完整消息。
验证失败可能很难排查。
与其认证对应物SPF不同，SPF提供了一种方式让域授权主机代表其发送邮件，DKIM提供了一种方式让一个实体（域、组织、个人等）对邮件负责，这与实际发送邮件的实体无关。虽然在许多情况下，责任实体和发送实体是相同或至少紧密相关的，但在DKIM中没有要求必须如此。
我希望通过这篇文章，你能学习和理解关于DKIM的以下概念：
DKIM是一种"基于内容"的认证，与"基于路径"的SPF不同。
责任实体通过在邮件头中插入一对加密哈希“签署”邮件来断言其责任。
DKIM验证由接收域尝试生成相同的两个哈希完成。
在许多情况下，DKIM 验证不能完成，直到发送服务器传输完整消息。
验证失败可能很难排查。
“Content-Based” Authentication
DKIM 被称为“基于内容”的身份验证，而不是“基于路径”，因为消息是否通过 DKIM 验证完全取决于内容在签名时和尝试验证时之间是否发生了变化。
DKIM 被称为“基于内容”的身份验证，而不是“基于路径”，因为消息是否通过 DKIM 验证完全取决于内容在签名时和尝试验证时之间是否发生了变化。
DKIM 被称为“基于内容”的身份验证，而不是“基于路径”，因为消息是否通过 DKIM 验证完全取决于内容在签名时和尝试验证时之间是否发生了变化。
DKIM Signing 和 Validation
希望进行DKIM签名邮件的组织将首先生成两个加密密钥。一个密钥是私有的，供发送服务器用于邮件签名，另一个则需要公开发布在DNS中，以便接收域尝试验证签名。生成这些密钥并安装的方法取决于平台，不在本文讨论范围之内，不过稍后我将描述如何在DNS中发布公用DKIM密钥。
希望进行DKIM签名邮件的组织将首先生成两个加密密钥。一个密钥是私有的，供发送服务器用于邮件签名，另一个则需要公开发布在DNS中，以便接收域尝试验证签名。生成这些密钥并安装的方法取决于平台，不在本文讨论范围之内，不过稍后我将描述如何在DNS中发布公用DKIM密钥。
希望进行DKIM签名邮件的组织将首先生成两个加密密钥。一个密钥是私有的，供发送服务器用于邮件签名，另一个则需要公开发布在DNS中，以便接收域尝试验证签名。生成这些密钥并安装的方法取决于平台，不在本文讨论范围之内，不过稍后我将描述如何在DNS中发布公用DKIM密钥。
The DKIM-Signature Header
为了开始了解DKIM，让我们先看看一个DKIM-Signature头：
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
DKIM-Signature头是一系列键值对，其中一些对读者更有吸引力，但我将在这里描述所有这些。
首先，我们先看看那些对读者来说基本上只是顺带一提的部分：
v=1; – 指定DKIM版本（1是唯一有效值）
a=rsa-sha256; – 用于构造加密哈希的算法
c=relaxed/relaxed; – 这涉及两个规则集，适用于在创建DKIM签名的哈希时去除头和主体中空白的规则；这些规则称为“规范化规则”（因此键是c），规则集可以是“relaxed”或“strict”。
t=1454417737; – 签名创建的时间戳。
这三个头部分包含实际的签名信息：
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – 这是消息主体的哈希。
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – 这是用于创建下面显示的签名数据的头列表。
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – 这是实际的DKIM签名数据
这三个部分对接收方验证签名的服务器最感兴趣：
d=welcome.foo.com; – 这标识了签署此消息的域
s=notices; – 选择器；域可以在签署消息时使用多个选择器。
i=@welcome.foo.com; – 这是代表其签署消息的身份。从语法上看。这看起来像一个电子邮件地址，甚至可能是一个；电子邮件地址的本地部分可以为空，如本例中一样，且域部分必须与签名中d=部分的域相同或为其子域。
这些部分对接收服务器感兴趣的原因是，它们提供了所需的信息，有助于接收方验证签名。
字段 | 含义 | 接收方如何使用 |
|---|---|---|
v= | DKIM版本（始终为1） | 确认签名格式 |
a= | 哈希+签名算法（例如rsa-sha256） | 确保验证者正确重现签名 |
c= | 规范化规则（头/主体） | 在哈希前规范化空白符 |
t= | 签名创建时间戳 | 用于新鲜性检查和重放预防 |
bh= | 主体哈希 | 接收方重新生成以确认消息主体完整性 |
h= | 签名头字段列表 | 确保签名中使用的头是可用且未修改的 |
b= | 实际的DKIM签名 | 接收方根据公钥验证此签名 |
d= | 签名域 | 用于定位签名者的DNS公钥 |
s= | 选择器 | 与域结合形成：selector._domainkey.domain |
i= | 签名身份 | 必须与d=相同或为其子域，标识签署实体 |
为了开始了解DKIM，让我们先看看一个DKIM-Signature头：
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
DKIM-Signature头是一系列键值对，其中一些对读者更有吸引力，但我将在这里描述所有这些。
首先，我们先看看那些对读者来说基本上只是顺带一提的部分：
v=1; – 指定DKIM版本（1是唯一有效值）
a=rsa-sha256; – 用于构造加密哈希的算法
c=relaxed/relaxed; – 这涉及两个规则集，适用于在创建DKIM签名的哈希时去除头和主体中空白的规则；这些规则称为“规范化规则”（因此键是c），规则集可以是“relaxed”或“strict”。
t=1454417737; – 签名创建的时间戳。
这三个头部分包含实际的签名信息：
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – 这是消息主体的哈希。
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – 这是用于创建下面显示的签名数据的头列表。
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – 这是实际的DKIM签名数据
这三个部分对接收方验证签名的服务器最感兴趣：
d=welcome.foo.com; – 这标识了签署此消息的域
s=notices; – 选择器；域可以在签署消息时使用多个选择器。
i=@welcome.foo.com; – 这是代表其签署消息的身份。从语法上看。这看起来像一个电子邮件地址，甚至可能是一个；电子邮件地址的本地部分可以为空，如本例中一样，且域部分必须与签名中d=部分的域相同或为其子域。
这些部分对接收服务器感兴趣的原因是，它们提供了所需的信息，有助于接收方验证签名。
字段 | 含义 | 接收方如何使用 |
|---|---|---|
v= | DKIM版本（始终为1） | 确认签名格式 |
a= | 哈希+签名算法（例如rsa-sha256） | 确保验证者正确重现签名 |
c= | 规范化规则（头/主体） | 在哈希前规范化空白符 |
t= | 签名创建时间戳 | 用于新鲜性检查和重放预防 |
bh= | 主体哈希 | 接收方重新生成以确认消息主体完整性 |
h= | 签名头字段列表 | 确保签名中使用的头是可用且未修改的 |
b= | 实际的DKIM签名 | 接收方根据公钥验证此签名 |
d= | 签名域 | 用于定位签名者的DNS公钥 |
s= | 选择器 | 与域结合形成：selector._domainkey.domain |
i= | 签名身份 | 必须与d=相同或为其子域，标识签署实体 |
为了开始了解DKIM，让我们先看看一个DKIM-Signature头：
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
DKIM-Signature头是一系列键值对，其中一些对读者更有吸引力，但我将在这里描述所有这些。
首先，我们先看看那些对读者来说基本上只是顺带一提的部分：
v=1; – 指定DKIM版本（1是唯一有效值）
a=rsa-sha256; – 用于构造加密哈希的算法
c=relaxed/relaxed; – 这涉及两个规则集，适用于在创建DKIM签名的哈希时去除头和主体中空白的规则；这些规则称为“规范化规则”（因此键是c），规则集可以是“relaxed”或“strict”。
t=1454417737; – 签名创建的时间戳。
这三个头部分包含实际的签名信息：
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – 这是消息主体的哈希。
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – 这是用于创建下面显示的签名数据的头列表。
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – 这是实际的DKIM签名数据
这三个部分对接收方验证签名的服务器最感兴趣：
d=welcome.foo.com; – 这标识了签署此消息的域
s=notices; – 选择器；域可以在签署消息时使用多个选择器。
i=@welcome.foo.com; – 这是代表其签署消息的身份。从语法上看。这看起来像一个电子邮件地址，甚至可能是一个；电子邮件地址的本地部分可以为空，如本例中一样，且域部分必须与签名中d=部分的域相同或为其子域。
这些部分对接收服务器感兴趣的原因是，它们提供了所需的信息，有助于接收方验证签名。
字段 | 含义 | 接收方如何使用 |
|---|---|---|
v= | DKIM版本（始终为1） | 确认签名格式 |
a= | 哈希+签名算法（例如rsa-sha256） | 确保验证者正确重现签名 |
c= | 规范化规则（头/主体） | 在哈希前规范化空白符 |
t= | 签名创建时间戳 | 用于新鲜性检查和重放预防 |
bh= | 主体哈希 | 接收方重新生成以确认消息主体完整性 |
h= | 签名头字段列表 | 确保签名中使用的头是可用且未修改的 |
b= | 实际的DKIM签名 | 接收方根据公钥验证此签名 |
d= | 签名域 | 用于定位签名者的DNS公钥 |
s= | 选择器 | 与域结合形成：selector._domainkey.domain |
i= | 签名身份 | 必须与d=相同或为其子域，标识签署实体 |
DKIM Validation
除了提到的要求，即i=域必须与d=域相同或为其子域外，d=和s=部分由验证器用于在DNS中查找签名者的公共DKIM密钥。该密钥是DNS中的TXT记录，总是位于选择器._domainkey.domain的位置。因此，在我们的示例中，使用s=notices和d=welcome.foo.com，公共DKIM密钥将在DNS中发现于notices._domainkey.welcome.foo.com，它可能看起来像这样：
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
验证器使用该密钥（p=部分）生成消息的哈希集；如果这些哈希匹配，则表示消息在传输过程中未被修改，因此消息可以对签名者的声誉产生影响，并可能从中受益。
除了提到的要求，即i=域必须与d=域相同或为其子域外，d=和s=部分由验证器用于在DNS中查找签名者的公共DKIM密钥。该密钥是DNS中的TXT记录，总是位于选择器._domainkey.domain的位置。因此，在我们的示例中，使用s=notices和d=welcome.foo.com，公共DKIM密钥将在DNS中发现于notices._domainkey.welcome.foo.com，它可能看起来像这样：
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
验证器使用该密钥（p=部分）生成消息的哈希集；如果这些哈希匹配，则表示消息在传输过程中未被修改，因此消息可以对签名者的声誉产生影响，并可能从中受益。
除了提到的要求，即i=域必须与d=域相同或为其子域外，d=和s=部分由验证器用于在DNS中查找签名者的公共DKIM密钥。该密钥是DNS中的TXT记录，总是位于选择器._domainkey.domain的位置。因此，在我们的示例中，使用s=notices和d=welcome.foo.com，公共DKIM密钥将在DNS中发现于notices._domainkey.welcome.foo.com，它可能看起来像这样：
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
验证器使用该密钥（p=部分）生成消息的哈希集；如果这些哈希匹配，则表示消息在传输过程中未被修改，因此消息可以对签名者的声誉产生影响，并可能从中受益。
验证失败和故障排除
我在上面提到过，DKIM 失败可能很难排查，这里我会解释原因。
有些 DKIM 验证失败的原因显而易见，例如信息未被签名，或签名域的公钥未在 DNS 中找到或语法不正确，或者信息在传输过程中显然被更改了。当发生这类故障时，很容易找出问题并推荐解决方案。然而，困难的是那些导致最令人沮丧的支持体验的情况，即信息已经签名，公钥存在于 DNS 中，信息明显未被更改，但验证器报告签名验证失败。
这些问题难以排查的原因是因为双方都无法真正重现信息被签名和验证的条件。信息在其 DKIM-Signature 标头中包含了签名时由签名者生成的哈希，但验证者可能没有访问签名者基础架构的权限，因此无法在签名者的条件下尝试重现签名。同样，签名者也可能无法访问验证者的基础架构，因此无法尝试以验证者的方式验证信息。
像我在这里描述的这种故障是罕见事件，DKIM 验证失败本身通常不会对邮件投递产生影响。虽然 DKIM 负责消息认证，实施全面的电子邮件验证技术确保您正在发送到合法地址，这些地址实际上可以接收和认证您的邮件。根据我的经验，这类故障导致的支持票比任何其他类型的 DKIM 问题都多。
我在上面提到过，DKIM 失败可能很难排查，这里我会解释原因。
有些 DKIM 验证失败的原因显而易见，例如信息未被签名，或签名域的公钥未在 DNS 中找到或语法不正确，或者信息在传输过程中显然被更改了。当发生这类故障时，很容易找出问题并推荐解决方案。然而，困难的是那些导致最令人沮丧的支持体验的情况，即信息已经签名，公钥存在于 DNS 中，信息明显未被更改，但验证器报告签名验证失败。
这些问题难以排查的原因是因为双方都无法真正重现信息被签名和验证的条件。信息在其 DKIM-Signature 标头中包含了签名时由签名者生成的哈希，但验证者可能没有访问签名者基础架构的权限，因此无法在签名者的条件下尝试重现签名。同样，签名者也可能无法访问验证者的基础架构，因此无法尝试以验证者的方式验证信息。
像我在这里描述的这种故障是罕见事件，DKIM 验证失败本身通常不会对邮件投递产生影响。虽然 DKIM 负责消息认证，实施全面的电子邮件验证技术确保您正在发送到合法地址，这些地址实际上可以接收和认证您的邮件。根据我的经验，这类故障导致的支持票比任何其他类型的 DKIM 问题都多。
我在上面提到过，DKIM 失败可能很难排查，这里我会解释原因。
有些 DKIM 验证失败的原因显而易见，例如信息未被签名，或签名域的公钥未在 DNS 中找到或语法不正确，或者信息在传输过程中显然被更改了。当发生这类故障时，很容易找出问题并推荐解决方案。然而，困难的是那些导致最令人沮丧的支持体验的情况，即信息已经签名，公钥存在于 DNS 中，信息明显未被更改，但验证器报告签名验证失败。
这些问题难以排查的原因是因为双方都无法真正重现信息被签名和验证的条件。信息在其 DKIM-Signature 标头中包含了签名时由签名者生成的哈希，但验证者可能没有访问签名者基础架构的权限，因此无法在签名者的条件下尝试重现签名。同样，签名者也可能无法访问验证者的基础架构，因此无法尝试以验证者的方式验证信息。
像我在这里描述的这种故障是罕见事件，DKIM 验证失败本身通常不会对邮件投递产生影响。虽然 DKIM 负责消息认证，实施全面的电子邮件验证技术确保您正在发送到合法地址，这些地址实际上可以接收和认证您的邮件。根据我的经验，这类故障导致的支持票比任何其他类型的 DKIM 问题都多。
