DKIM 配置指南：选择器、密钥与 DNS 记录

DKIM（域名密钥识别邮件）为你发出的每封邮件加上加密签名，接收方可以用你发布在 DNS 里的公钥加以验证。它是唯一能在转发后幸存的认证方式，是 Gmail 和 Yahoo 对批量发件人的硬性要求，而且——关键在于——它失败时是无声的：邮件照样投递，只是进了垃圾箱。本指南讲解选择器与密钥如何配合、DNS 记录怎么发布才正确，以及如何在不弄坏在途邮件的前提下轮换密钥。

想先了解 SPF、DKIM、DMARC 的整体配置顺序，请读 认证总览；本篇假定 SPF 已就绪，只深入 DKIM。

DKIM 的工作原理：签名与密钥

邮件服务器发信时会附加一个 DKIM-Signature 信头，典型示例：

DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=sel-branded-2026;
    c=relaxed/relaxed; q=dns/txt;
    h=from:to:subject:date:mime-version:content-type;
    bh=<正文哈希>; b=<签名>

配置时最要紧的是两个标签：

• d=——签名域。DMARC 就是拿它与可见的 From 域名做对齐检查，所以它必须是你的域名（宽松对齐下子域名也可以）。
• s=——选择器（selector），标识本封邮件用的是哪对密钥。它让你能同时发布多把公钥，正是零停机轮换的基础。

接收方取出 d= 和 s=，去 DNS 查询公钥，然后对照收到的邮件验签。任何被签名的信头或正文在途中被改动，验证都会失败。

DNS 记录：selector._domainkey

公钥以 TXT 记录发布在 <selector>._domainkey.<domain>。对应上面的选择器：

sel-branded-2026._domainkey.yourdomain.com  TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

值里各标签的含义：

• v=DKIM1——标识这是一条 DKIM 密钥记录。
• k=rsa——密钥类型，RSA 是通用默认。
• p=——base64 编码的公钥。当 p= 为空（v=DKIM1; k=rsa; p=）时表示密钥已吊销——接收方必须将引用该选择器的签名视为永久失败。

配对的私钥留在发送系统内部，绝不能外流：不要贴进工单、聊天记录或代码仓库。持有私钥的人就能以你的域名签名发信——这比完全没有 DKIM 糟糕得多。

密钥长度：用 2048 位

新密钥的当前推荐是 2048 位 RSA。两端的取舍：

• 1024 位已属弱密钥。部分接收方已经降权或直接拒收 1024 位密钥的签名，而且趋势只会收紧。不要再生成 1024 位密钥。
• 4096 位很少值得。更大的密钥让 DNS 记录长到部分解析器触碰 UDP 包长上限而被截断，一些 DNS 面板干脆存不下。除非有明确需求且做过解析测试，否则留在 2048 位。

注意密钥长度是密钥对的属性，在你生成它的地方设定——邮件服务器配置或 ESP 管理后台——而不是在 DNS 里改的东西。

规范化与 h= 信头列表

签名信头里有两个部分控制"到底签了什么"：

• c= 规范化——哈希前如何归一化消息。relaxed/relaxed 容忍无害的空白与换行变化（前一个值作用于信头，后一个作用于正文），simple 则要求逐字节保持原样。两者都用 relaxed 是常见且更有韧性的默认；正文用 strict 会因为中间环节的合法重排而挂掉。
• h= 信头列表——哪些信头被签名覆盖。from 是必签项；合理的列表通常还包括 to、subject、date、mime-version、content-type。签的信头越多，篡改越难——但事后才被添加的信头（比如 ESP 补的 list-unsubscribe）绝不能出现在列表里。

还有一个标签要确保你的签名器不要输出：l=（body length）。它只签正文的前 N 个字节，技术上允许中间人在签名之后追加内容而验证依然通过，同时也会让接收方降低对你邮件的解读评级。现代签名器都省略它；如果你的系统有这个选项，关掉。

发布记录：255 字符与引号

2048 位密钥的 base64 公钥长约 340 字符，超过单个 TXT 字符串 255 字节的限制。因此值必须在 DNS 面板里拆成多个带引号的字符串：

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
"...公钥剩余部分..."

DNS 客户端会在使用前把字符串拼接起来，公钥得以完整到达。这一步的实际翻车点是引号（密钥里多一个引号或空格，整条记录无法解析）和截断（有些面板会悄悄截断超长值——要验证实际发布出去的内容，别相信表单）。如果你的 ESP 提供指向其密钥的 CNAME 记录，那通常更省事：一条 CNAME、无需拆分，服务商还会在自己的侧轮换密钥。

用双选择器轮换密钥

定期轮换 DKIM 密钥——每年一次是合理的默认节奏——并且始终让新旧密钥重叠：

1. 在新的 selector 下生成新密钥对并发布其 TXT 记录，旧 selector 的记录保持在线。此时两把密钥并存。
2. 把签名器切换到新 selector。从这一刻起新邮件都用新密钥签名。
3. 观察 1–2 周。切换前签名的邮件可能还在对端队列里，验签时会重新查 DNS；旧记录必须等这些邮件消化完才能下线。
4. 删除旧记录——更好的做法是保留它但把 p= 置空，明确标记密钥已吊销，而不是留下一个语义含糊的 NXDOMAIN。

切换第一天就删旧记录是最典型的轮换事故：所有在途邮件验签失败，看起来就像伪造邮件，而且偏偏赶在你的 DMARC 策略最严格的时候。

验证配置

用 DKIM 检测检查已发布的公钥——输入域名和服务商使用的 selector，它会确认记录可解析、可正常解析出可用密钥。想看签名实际运作，发一封测试邮件并读原始信头——邮件头分析器会替你解析 DKIM-Signature 和接收方的 Authentication-Results，生产环境里的 DKIM 失败也正是在这里暴露（见 DMARC 失败排查指南）。各服务商控制台的具体路径见 Google Workspace 与 Microsoft 365 指南；DNS 面板的坑都收集在 DNS 服务商配置指南里。

常见错误

• selector 名写错。DNS 标签必须与 s= 值完全一致——一个拼写错误意味着接收方查询一个不存在的域名，所有签名全部失败。
• 密钥值里混入引号或空格。手工拆分 TXT 时 base64 中间多一个空格、或引号出现在中间，整条记录都无法解析。要验证实际发布出去的，而不是你粘贴的。
• 混淆公钥和私钥。DNS 记录里放的是公钥（p=）；私钥配置在发送系统里。私钥一旦出现在任何公开位置就是安全事件——立即轮换。
• 轮换时直接删旧记录。在途邮件仍需要旧公钥。先让新旧 selector 重叠 1–2 周，再移除旧记录。
• 把 DKIM 当成"加密"。DKIM 是签名，不是加密。没有任何内容被隐藏——签名只证明邮件未被篡改并标识签名域。

常见问题

应该有几个 selector？

正常状态是每个发送服务一个在用 selector；轮换期间暂时有两个。一些大型发件方也会按服务分 selector（比如 CRM 用 s1、邮件服务器用 mta），纯粹为了管理清晰。

DKIM 会加密我的邮件吗？

不会。DKIM 做的是签名，不是加密；任何人都能读到正文。端到端加密是另一套技术（S/MIME、PGP），与投递率无关。

为什么只在某一个接收方那里 DKIM 失败？

最常见的是该接收方解析器侧的 DNS 传播或拆分问题，或中间环节改动了邮件（邮件列表是重灾区）。用 邮件头分析器读该接收方的 Authentication-Results，看失败原因是"找不到 selector 的密钥"（DNS 问题）还是"签名验证不过"（邮件被改动）。

p= 为空是什么意思？

表示密钥已吊销。接收方必须将引用该 selector 的签名永久视为失败。这是退役密钥的正确终态——比直接删记录更好。

多久轮换一次密钥？

对多数组织而言每年一次是合理默认；怀疑私钥可能泄露时立即轮换。无论节奏如何，上文流程——新 selector、切换、观察、清理——都一样适用。