DKIM 验证：电子邮件认证最佳实践
电子邮件
·
2017年4月8日
关键要点
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= 值。
在以下位置查找公钥：
重新生成标题和正文的哈希值。
将它们与电子邮件中的 bh= 和 b= 值进行比较。
如果匹配，消息通过 DKIM。
是什么原因导致DKIM失败？
消息在传输中被更改（如果使用严格的规范化，甚至空白也会发生变化）
DNS中公钥不正确或缺失
DNS格式错误
选择器被移除或错误旋转
身份不匹配（i=必须与d=相同域或子域）
为什么 DKIM failures 可能会很难 troubleshoot？
因为签署者和验证者在完全不同的环境中运行——双方都无法重建对方的哈希条件或签名状态。
这使得不透明的“哈希不匹配”故障成为最令人生气的诊断问题。
DKIM 失败是否意味着电子邮件会进入垃圾邮件？
不一定。
DKIM 只是一个信号。如果域名声誉良好并通过其他检查（SPF、DMARC 对齐、低投诉率），单独的 DKIM 失败通常不会对 Inbox 产生影响。
为什么要使用 DKIM？
保护信息的完整性
建立域名声誉
实现DMARC对齐
帮助邮箱提供商区分合法发件人与欺骗者
DKIM被视为所有严肃电子邮件发件人的最佳实践。
当我们谈论“邮件认证”时，我们指的是一种向邮件接收者提供一定程度确信的方法，即邮件确实来自所声称来源的技术。这类技术背后的理念是建立起某种程度的防御，以防止欺诈性邮件，例如钓鱼和欺骗邮件，这些邮件可能削弱接收者对接收邮件的信任。不过，发送经过认证的邮件并不意味着该邮件是好的或受欢迎的；它仅仅意味着可以可靠地建立经过认证方的声誉，并在邮件接受和放置决策中使用。
目前，使用中有两种形式的邮件认证：
发送者政策框架 (SPF)
域名密钥识别邮件 (DKIM)
在今天的文章中，我将介绍DKIM是什么以及它如何运作。
DKIM 概览
与其认证对应物SPF不同，SPF提供了一种方式让域授权主机代表其发送邮件，DKIM提供了一种方式让一个实体（域、组织、个人等）对邮件负责，这与实际发送邮件的实体无关。虽然在许多情况下，责任实体和发送实体是相同或至少紧密相关的，但在DKIM中没有要求必须如此。
我希望通过这篇文章，你能学习和理解关于DKIM的以下概念：
DKIM是一种"基于内容"的认证，与"基于路径"的SPF不同。
责任实体通过在邮件头中插入一对加密哈希“签署”邮件来断言其责任。
DKIM验证由接收域尝试生成相同的两个哈希完成。
在许多情况下，DKIM 验证不能完成，直到发送服务器传输完整消息。
验证失败可能很难排查。
“Content-Based” Authentication
DKIM 被称为“基于内容”的身份验证，而不是“基于路径”，因为消息是否通过 DKIM 验证完全取决于内容在签名时和尝试验证时之间是否发生了变化。
DKIM Signing 和 Validation
希望进行DKIM签名邮件的组织将首先生成两个加密密钥。一个密钥是私有的，供发送服务器用于邮件签名，另一个则需要公开发布在DNS中，以便接收域尝试验证签名。生成这些密钥并安装的方法取决于平台，不在本文讨论范围之内，不过稍后我将描述如何在DNS中发布公用DKIM密钥。
The DKIM-Signature Header
DKIM Validation
验证失败和故障排除
我在上面提到过，DKIM 失败可能很难排查，这里我会解释原因。
有些 DKIM 验证失败的原因显而易见，例如信息未被签名，或签名域的公钥未在 DNS 中找到或语法不正确，或者信息在传输过程中显然被更改了。当发生这类故障时，很容易找出问题并推荐解决方案。然而，困难的是那些导致最令人沮丧的支持体验的情况，即信息已经签名，公钥存在于 DNS 中，信息明显未被更改，但验证器报告签名验证失败。
这些问题难以排查的原因是因为双方都无法真正重现信息被签名和验证的条件。信息在其 DKIM-Signature 标头中包含了签名时由签名者生成的哈希，但验证者可能没有访问签名者基础架构的权限，因此无法在签名者的条件下尝试重现签名。同样，签名者也可能无法访问验证者的基础架构，因此无法尝试以验证者的方式验证信息。
像我在这里描述的这种故障是罕见事件，DKIM 验证失败本身通常不会对邮件投递产生影响。虽然 DKIM 负责消息认证，实施全面的电子邮件验证技术确保您正在发送到合法地址，这些地址实际上可以接收和认证您的邮件。根据我的经验，这类故障导致的支持票比任何其他类型的 DKIM 问题都多。
