定义
DKIM（DomainKeys Identified Mail）是一项使用公钥密码学对外发邮件进行签名的认证规范。它让接收方邮件服务器得以确认邮件确实来源于其所声明的域名，并验证邮件正文与所选头部在传输过程中未被改动。签名域名将其公钥发布到 DNS 中；接收方服务器获取该公钥，对嵌入在 DKIM-Signature 邮件头中的签名进行验证。
DKIM 由两个早期的、相互重叠的提议演化而来——Yahoo 的 DomainKeys 与 Cisco 的 Identified Internet Mail——并于 2007 年首次以 IETF RFC 4871 形式发布。当前权威规范是 RFC 6376，发布于 2011 年 9 月，并由 RFC 8301（2018）与 RFC 8463（2018）更新，强制要求采用更稳健的密码算法。DKIM 在邮件生态中部署广泛，是任何能提供有效保护的 DMARC 策略所必备的组成部分。
工作原理
当机构的邮件服务器发送邮件时，DKIM 签名模块（内置于 Postfix、Exim、Microsoft Exchange 等 MTA，或由 SendGrid、Mailgun、Amazon SES、Postmark 等事务邮件服务商提供）会执行以下操作。
签名方先选定一组要纳入签名的头部——通常包括 From、To、Subject、Date、Content-Type——并采用两种规范化算法之一进行规范化处理：simple（最小空白规范化）或 relaxed（更宽容，能容忍传输途中头部的细微改写）。邮件正文同样被规范化并使用 SHA-256 哈希（自 RFC 8301 起，旧版 SHA-1 已被弃用）。签名方再对头部哈希加上一段结构化的签名元数据字符串，使用 RSA 或 Ed25519 计算数字签名，并把 DKIM-Signature 头部插入邮件最上方。
DKIM-Signature 头部包含：v=1（版本）、a=rsa-sha256（算法）、d=example.com（签名域名，即 d= 标签）、s=selector1（选择器，用于查找特定公钥）、h=from:to:subject（已签名头部）、bh=<正文哈希>、b=<base64 签名>。
域名所有者将对应公钥以 DNS TXT 记录的形式发布在 <选择器>._domainkey.<域名> 路径下。当 Gmail、Outlook、Yahoo Mail 或任何符合 RFC 6376 的 MTA 收到这封邮件时，便会查询该 DNS 记录、获取公钥并验证加密签名。签名有效则 DKIM 结果为 pass。若签名缺失、无效，或已签名头部和正文在传输途中遭到改动，结果便是 fail 或 neutral，并随之传给 DMARC 评估引擎。
选择器（s= 标签）允许同一域名同时发布多枚 DKIM 公钥——便于在不停服的情况下轮换密钥，或将不同发送系统的密钥相互隔离（例如 marketing._domainkey.example.com 与 transactional._domainkey.example.com）。
您会在哪里遇到它
DKIM 是任何依赖邮件投递服务的基础部署要求。Amazon SES、SendGrid（Twilio 旗下）、Mailgun（Sinch 旗下）、Postmark、SparkPost 等事务邮件服务商在域名验证过程中将 DKIM 签名列为必填配置。服务商会生成一对 RSA-2048 或 Ed25519 密钥，将公钥以 DNS TXT 记录形式呈现，并要求域名所有者发布它，方可启用从该域名发送邮件的能力。
对于派发邮箱确认投票的竞赛平台而言，DKIM 签名尤为关键，因为确认邮件必须通过主要邮箱服务商的认证检查——Google Workspace / Gmail、Microsoft Outlook 及 Exchange Online Protection、Yahoo Mail、Apple iCloud Mail 与 ProtonMail。未签名邮件或签名失败的邮件，被投入垃圾箱乃至完全屏蔽的概率大大提升，导致投票者无法完成确认动作。
Mail-Tester、GlockApps、MXToolbox DKIM Lookup 等邮件测试工具能在生产发送之前帮助发件方检查并校验 DKIM 配置。Google Postmaster Tools 与 Microsoft SNDS 则提供汇总层面的投递率数据，反映 DKIM 通过率随时间的变化。
实际示例
某竞赛平台为域名 votes.example.com 配置了 DKIM 选择器 s=contest，并在 contest._domainkey.votes.example.com 处发布公钥。每封外发的确认邮件都携带由对应私钥签名的 DKIM-Signature 头部。当投票者的 Gmail 账号收到这封邮件时，Gmail 入站过滤器查询 DNS、验证签名、记录通过结果，并将其交给垃圾邮件分类器。已确认通过的 DKIM 加上 SPF 对齐，便满足 DMARC 合规所需条件。
某竞赛管理员阅读 RFC 8301 后，将 1024 位的 RSA 密钥（在密码学上已不再够强）轮换为 2048 位 RSA 密钥。旧选择器在 DNS 中保留七天以覆盖传输途中的邮件，再将其移除。所有新邮件都使用更新后的选择器与密钥。
相关概念
DKIM 与 SPF 记录 协同——SPF 负责认证发送服务器的 IP 地址；以及 DMARC——后者依据 SPF 与 DKIM 结果定义策略动作与报告机制。两类信号必须并行解读；如果 d= 域名与 RFC5322.From 域名未对齐，仅 DKIM 通过并不足以让邮件 DMARC 合规。在竞赛运营场景下，DKIM 失败的实际影响在 邮箱确认投票 中有详细说明，因为确认邮件能否进入收件箱直接决定投票能否计入。
