CUSTOMIZE 当我们谈到“Email Authentication”时，我们指的是一种技术，这种技术为消息的接收者提供了一定程度的确定性，确保消息实际上是来自消息声称的来源。
当我们谈论“邮件认证”时，我们指的是一种向邮件接收者提供一定程度确信的方法，即邮件确实来自所声称来源的技术。这类技术背后的理念是建立起某种程度的防御，以防止欺诈性邮件，例如钓鱼和欺骗邮件，这些邮件可能削弱接收者对接收邮件的信任。不过，发送经过认证的邮件并不意味着该邮件是好的或受欢迎的；它仅仅意味着可以可靠地建立经过认证方的声誉，并在邮件接受和放置决策中使用。
目前，使用中有两种形式的邮件认证：
发送者政策框架 (SPF)
域名密钥识别邮件 (DKIM)
在今天的文章中，我将介绍DKIM是什么以及它如何运作。
DKIM 概览
与其身份验证对应的 SPF 不同，SPF 提供了一种方法让域授权主机代表其发送邮件，DKIM 提供了一种方法，使实体（域、组织、个人等）能够对消息负责，而与实际发送消息的实体无关。虽然在许多情况下，负责实体和发送实体会是相同的，或至少是密切相关的，但在 DKIM 中，并不要求必须如此。
我希望通过这篇文章，你能够学习并理解以下关于 DKIM 的概念：
DKIM 是一种“基于内容”的身份验证，不同于“基于路径”的 SPF。
负责实体通过在消息头中插入一对加密哈希来“签署”消息，以此申明其责任。
DKIM 验证由接收域尝试生成相同的两个哈希来完成。
在许多情况下，DKIM 验证在发送服务器传输完整消息之前无法完成。
验证失败可能难以排查。
“Content-Based” Authentication
DKIM Signing 和 Validation
希望进行DKIM签名邮件的组织将首先生成两个加密密钥。其中一个密钥保持私密，并可供发送服务器用于邮件的签名，另一个则公开在DNS中，供接收域尝试验证签名。生成这些密钥和安装它们的方法依赖于平台，超出了本文的范围，虽然稍后我将描述在DNS中发布公用DKIM密钥。
DKIM-Signature 标头
为了开始我们对DKIM的理解，让我们先看看一个DKIM签名头：
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签名头是一系列键值对，有些对读者更感兴趣，而其他的则不太重要，但我将在此描述它们。
首先，我们来看一下对读者来说大多只是顺便了解的部分：
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=部分的域相同或为其子域。
这些部分对接收服务器感兴趣的原因是它们提供了帮助接收方验证签名所需的信息。
DKIM Validation
除了要求i=域必须与d=域相同或是d=域的子域外，验证器还使用d=和s=位来查找DNS中的签名者的公用DKIM密钥。该密钥是DNS中的TXT记录，它总是位于selector._domainkey.domain的位置。因此，在我们的示例中，使用s=notices和d=welcome.foo.com，公用DKIM密钥将位于DNS中的notices._domainkey.welcome.foo.com，并且它可能看起来像这样：
notices._domainkey.welcome.foo.com. 描述性文本 "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 问题产生更多的支持票。
