当我们谈到 "电子邮件认证 "时，我们指的是一种技术，它为邮件的收件人提供某种程度的确定性，即该邮件确实来自于声称的邮件来源。这种技术背后的想法是实现对欺诈性电子邮件的某种程度的防御，例如网络钓鱼和欺骗，这些邮件可能侵蚀收件人对接收电子邮件的信任。也就是说，发送经过认证的电子邮件的行为并不能断言该电子邮件是好的或想要的电子邮件；它只意味着该邮件是这样的：经过认证的一方的声誉可以可靠地建立并用于电子邮件的接受和放置决策。

目前有两种形式的电子邮件认证在使用。

• Sender Policy Framework (SPF)

• 域名密钥识别的邮件（DKIM）

在今天的文章中，我将介绍什么是DKIM以及它如何工作。

DKIM概述

Unlike its authentication counterpart SPF, which provides a way for a domain to authorize a host to send mail on its behalf, DKIM provides a way for an entity (domain, organization, person, etc.) to take responsibility for a message, independent of the entity that actually sent the message. While in many cases the responsible entity and the sending entity will be the same, or at least closely related, with DKIM there’s no requirement that this be so.

我在这篇文章中的目标是让你学习并理解以下关于DKIM的概念。

• DKIM是一种 "基于内容 "的认证，与 "基于路径 "的SPF不同。

• 负责任的实体通过在信息头中插入一对加密哈希值来 "签署 "信息，以证明其责任。

• DKIM的验证是由接收域尝试生成相同的两个哈希值来完成的。

• 在许多情况下，在发送服务器传输完整的信息之前，DKIM验证是无法完成的。

• 验证失败可能很难排除故障。

• 
  

"基于内容的 "认证

DKIM被称为 "基于内容 "的认证，而不是 "基于路径 "的认证，因为一封邮件是否通过DKIM的验证，完全基于它被签署和尝试验证之间的内容是否有变化。

DKIM签名和验证

希望对邮件进行DKIM签名的组织将首先生成两个加密密钥。其中一个密钥是私有的，可供发送服务器用来签署邮件，另一个则在DNS中公开，供接收域在试图验证签名时使用。生成这些密钥和安装它们的方法与平台有关，超出了这篇文章的范围，尽管稍后我将描述在DNS中发布公共DKIM密钥的情况。

DKIM-签名标头

为了开始我们对DKIM的理解，让我们先看一下DKIM-签名头。

DKIM-Signature: v=1; a=rsa-sha256。 d=welcome.foo.com; s=通知; c=放松的/轻松的; 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/Hi243Sc=;b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=。

DKIM-签名头是一系列的键值对，有些是读者比较感兴趣的，但我将在这里描述所有这些键值对。

首先，我们要看的是那些大多是读者顺便感兴趣的。

• v=1; – Specifies the DKIM version (1 is the only valid value)

• a=rsa-sha256; – ǞǞǞ algorithm used to construct the cryptographic hashes

• c=relaxed/relaxed; – There are two sets of rules regarding removal of whitespace in the headers and body that can be applied when creating the hashes in a DKIM signature; these rules are called “canonicalization rules” (hence the key of c) and the rulesets are either “relaxed” or “strict”.

• t=1454417737; – ǞǞǞ timestamp of when the signature was created.

这三个标题部分包含实际的签名信息。

• bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; - This is the hash of the body of the message.

• h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type;- This is a list of the headers that were used to create the signature data shown below.

• b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; - This is the acutal DKIM signature data

这三个部分是将验证签名的接收服务器最感兴趣的。

• d=welcome.foo.com;- This identifies the domain that signed the message

• s=通知；- The selector; domains can have multiple selectors that they use when signing messages.

• i=@welcome.foo.com; - This is the identity on whose behalf the message was signed. Syntactically, this will look like an email address, and might even be one; the localpart of the email address can be empty, as in this example, and the domain part must be the same as, or a subdomain of, the domain in the d= part of the signature.

这些部分之所以引起接收服务器的兴趣，是因为它们提供了必要的信息来帮助接收方验证签名。

DKIM Validation

In addition 到 requirement mentioned that the i= domain must be the same as or a sub-domain of the d= domain, the d= and s= bits are used by the validator to look up the signer’s public DKIM key in DNS. The key is a TXT record in DNS, and it’s always found 在 location selector._domainkey.domain. So, in our example here, with s=notices and d=welcome.foo.com, the public DKIM key would be found in DNS at 通知。_domainkey.welcome.foo.com, and it might look something like this:

notices._domainkey.welcome.foo.com。descriptive text "v=DKIM1\; h=sha256\;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzNNoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB/。s=email"

验证器使用该密钥（p=位）来产生它自己的一组信息哈希值；如果这些哈希值相匹配，那么该信息在传输过程中没有被改变，因此该信息可以为该信息的签名者的任何声誉作出贡献，并可能从中受益。

验证失败和故障排除

我在上面提到，DKIM的故障可能很难排除，我将在这里解释为什么会这样。

有些DKIM验证失败有明显的原因，比如邮件没有被签署，或者签署域的公钥在DNS中找不到，或者句法不正确，也可能是邮件在传输过程中被明显改变了。当这些类型的故障发生时，很容易找出问题并推荐一个解决方案。然而，最棘手的问题，以及导致最令人沮丧的支持经验的问题，是这样的情况：信息被签署，公钥在DNS中存在，信息没有被明显改变，但验证器报告说签名未能验证。

这些问题难以解决的原因是，双方都没有真正的方法来重现邮件被签名和验证的情况。邮件的DKIM签名头中有签名者在签名时生成的哈希值，但验证者可能无法访问签名者的基础设施，因此无法尝试在签名者的条件下重现签名。同样地，签名者很可能无法访问验证者的基础设施，因此也没有办法尝试以验证者的方式验证信息。

像我在这里描述的失败是很少发生的，DKIM验证失败本身通常不会对发送位置产生影响。根据我的经验，这种故障比任何其他类型的DKIM问题都更容易导致支持票。