1. Introduction (简介)

DomainKeys Identified Mail (DKIM) 允许个人、角色或组织通过将域名 [RFC1034] 与消息 [RFC5322] 关联来声明对消息的某些责任，而他们被授权使用该域名。这可以是作者的组织、运营中继或其代理之一。责任断言通过加密签名进行验证，并通过直接查询签名者的域来检索适当的公钥。消息从作者到接收者的传输通过中继进行，这些中继通常不会对消息内容进行实质性更改，从而保留 DKIM 签名。一条消息可以包含多个签名，来自同一个或不同的与消息相关的组织。

DKIM 采用的方法与以前的消息签名方法（例如 Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751]、OpenPGP [RFC4880]）不同，因为:

• 消息签名作为消息头字段编写，使人类接收者和现有的 MUA (Mail User Agent) 软件不会对出现在消息正文中的签名相关内容感到困惑。

• 不依赖于由知名、可信证书颁发机构颁发的公钥和私钥对。

• 不依赖于部署任何新的互联网协议或服务来进行公钥分发或撤销。

• 签名验证失败不会强制拒绝消息。

• 不尝试将加密作为机制的一部分包含在内。

• 消息归档不是设计目标。

DKIM:

• 与现有电子邮件基础设施兼容，并尽可能透明。

• 需要最少的新基础设施。

• 可以独立于客户端实现，以减少部署时间。

• 可以增量部署。

• 允许将签名委托给第三方。

1.1. DKIM Architecture Documents (DKIM 架构文档)

建议读者熟悉 [RFC4686]、[RFC5585] 和 [RFC5863] 中的内容，它们分别提供了 DKIM 开发的背景、服务概述以及部署和运营指导和建议。

1.2. Signing Identity (签名身份)

DKIM 将消息签名者的身份问题与消息的声称作者问题分开。特别是，签名包括签名者的身份。验证者可以使用签名信息来决定他们想要如何处理消息。签名身份作为签名头字段的一部分包含在内。

参考理由: DKIM 签名指定的签名身份不需要与任何特定头字段中的地址匹配，因为接收者邮件系统（包括 MUA）的解释方法广泛。

1.3. Scalability (可扩展性)

DKIM 旨在支持电子邮件识别问题所特有的极端可扩展性要求。有数百万个域和更多数量的单独地址。DKIM 试图保留当前电子邮件基础设施的积极方面，例如任何人都可以在没有介绍的情况下与任何其他人通信的能力。

1.4. Simple Key Management (简单密钥管理)

DKIM 与传统的分层公钥系统不同，因为不需要证书颁发机构基础设施。验证者直接从声称的签名者域中的存储库请求公钥，而不是从第三方请求。

DNS 被提议作为公钥的初始机制。因此，DKIM 目前依赖于 DNS 管理和 DNS 系统的安全性。DKIM 旨在可扩展到其他密钥获取服务，因为它们变得可用。

1.5. Data Integrity (数据完整性)

DKIM 签名将 "d=" 名称与消息的部分或全部计算哈希关联（参见第 3.7 节），以防止签名在不同消息中被重用。验证签名断言哈希内容自签名以来未发生更改，并且不会断言有关"保护"消息端到端完整性的任何其他内容。