指南 · DKIM 配置

产品团队应如何安全地配置 DKIM？

配置 DKIM 的步骤是：选择一个由组织拥有的签名域名，为每个服务商或签名系统分配唯一的选择器，在受保护的服务中生成密钥对，只在 selector._domainkey.example.com 发布公钥，并配置实际的出站路径，为每一封预期的邮件签名。从外部邮箱取得原始邮件字节并验证签名；当 DMARC 依赖 DKIM 时，确认 d= 域名与可见的 From 域名对齐，然后逐步推广。在生产流量切换之前，把选择器归属、轮换、撤销和回滚方案记录在案。

生成密钥之前，先梳理每一条真实的出站路径

从清单开始，而不是从 DNS 记录开始。列出每个可以使用组织可见 From 域名发出邮件的系统：应用工作进程、事务性服务商、营销平台、支持工具、身份系统、工单软件、中继和应急路径。对每个系统，记录其负责人、邮件类别、信封发件人、可见 From 域名、当前 DKIM d= 域名、选择器、签名组件，以及之后是否有其他中继修改邮件。为某一服务商发布的 DKIM 密钥，对从未使用其私钥的另一条路径毫无作用。同样，显示一个已验证域名的通用服务商控制台，并不能证明每个租户、区域、邮件流、模板或备用路径都已签名。使用每条路径的受控样本并保留原始邮件头。在启用签名之前决定哪些路径获得授权；DKIM 验证域名对签名所承担的责任，而不验证收件人同意或邮件内容的真实性。

选择支持 DMARC 对齐的签名域名

DKIM 的 d= 标签标识签名域名。请选择一个由组织控制、并能在邮件流整个生命周期内管理的域名。当 DMARC 依赖 DKIM 时，d= 域名必须在适用的宽松或严格对齐规则下，与可见 RFC 5322 From 字段中的域名对齐。由服务商拥有的签名域名可以产生有效的 DKIM 结果，但对组织的 From 域名来说仍然不对齐。请综合考虑归属、信誉隔离、委派的 DNS 和故障隔离，决定每个邮件流应由根域名还是专用子域名签名。不要仅仅为了规避信誉或策略问题而另造域名。请记录组织域名之间的关系和预期的 DMARC 模式。根据最终收到的邮件头测试对齐；切勿仅凭一次选择器查询就推断对齐，因为邮件可能使用了另一个 d= 值。

把选择器作为运维身份来分配

选择器允许域名发布多个密钥，并在不替换一个全局记录的情况下更换它们。创建确定性的选择器策略，用于标识服务商或签名者及轮换代次，而不泄露机密信息。例如，product-a-2026q3 可能比 default 更清晰，但名称应遵守 DNS 约定和您的工具限制。绝不要仅为减少 DNS 记录而在无关服务商、环境或租户之间复用同一私钥。维护一个登记表，包含选择器、d= 域名、用途、签名服务、负责人、创建时间、算法、公钥指纹、部署状态、轮换截止时间和停用证据。发布前检查确切的选择器名称：查询的是 `selector._domainkey.signing-domain`。在可见 From 域名、Return-Path 域名或错误 DNS 区域意外创建的记录，不会验证预期签名。在使用旧选择器签名的延迟邮件和重试邮件都过期前，避免删除它。

生成并保护私钥

如果服务商支持，请在托管密钥服务或严格受控的签名系统中生成密钥对。私钥绝不能进入公共 DNS、源代码仓库、浏览器代码、CI 输出、分析系统、普通日志、工单、文档、提示词或共享聊天。只向需要该密钥的邮件组件授予签名权限，将生产环境与较低级别的环境隔离，并记录管理访问。RFC 8301 更新了 DKIM 的加密要求，规定签名方必须使用至少 1024 位的 RSA 密钥，并应当使用至少 2048 位；它还提到了较长密钥在 DNS 运维上的限制。请参考所选签名方和收件方群体当前的能力和建议，而不是照搬过时的示例。如果考虑使用 Ed25519，RFC 8463 定义了它在 DKIM 中的用法，但必须测试互操作性，并在需要时保留兼容的签名策略。轮换必须能够在不导出私钥的情况下完成。

准确发布公钥

在精确的 `selector._domainkey.signing-domain` 所有者名称处发布 TXT 记录。DKIM 密钥记录包含 v=DKIM1 等标签、需要时的密钥类型，以及含有无私钥包装的公钥材料的 p=。遵循签名方的确切记录格式和您的 DNS 服务商的引号行为。保存前，检查 DNS 界面是否会自动追加区域、拆分长字符串或转义字符。发布后直接查询权威名称服务器，然后查询独立递归解析器并重建完整 TXT 值。一个 TXT 记录内的多个字符串会被 DNS 客户端连接，而多个相互竞争的资源记录可能造成歧义。保留之前的响应和 TTL 以供回滚。不要仅为消除检查工具提示就在生产环境发布更宽泛的密钥或保留测试标志，从而降低安全性。可见记录证明 DNS 已发布，不证明发件人使用匹配的私钥。

配置最终签名方和签名字段

请在把最终邮件交给出站传输的那个组件上配置签名，或者确保之后没有任何组件会修改已签名的内容。DKIM 签名覆盖正文哈希以及 h= 中列出的邮件头字段。RFC 6376 要求有效签名必须对 From 邮件头字段进行签名。请根据产品情况纳入与身份相关的关键邮件头，了解重复邮件头是如何被选取的，并避免对下游必要系统必须改写的字段进行签名，除非该转换是受控的。请审慎选择规范化方式。宽松（relaxed）规范化可以容忍规定范围内的空白和邮件头格式变化，但不允许任意修改正文。简单（simple）规范化则更加脆弱。签名之后插入页脚、改写链接、修改 MIME 边界、转换传输编码、添加主题标签以及规范化换行符，都可能导致验证失败。请在完成所有已批准的转换之后，对完全渲染好的邮件进行签名，并禁止不受信任的用户选择 d=、s=、邮件头列表或密钥。

端到端验证实际收到的原始邮件

通过每一条与生产环境一致的真实路径，向团队自己管理的外部测试邮箱发送受控邮件。保留原始邮件本身，而不是复制出来的正文或重新序列化的工单附件。检查 DKIM-Signature 的 d= 和 s= 值、已签名邮件头列表、正文哈希、算法、规范化方式、时间戳以及过期时间（如有）。从独立的网络查询公钥，并用遵循标准的验证工具对原始字节进行验证。在遵守 RFC 8601 信任边界的前提下，将可信收件方的 Authentication-Results 邮件头与您的验证结果进行比较。测试纯文本、multipart alternative、预期的附件、Unicode 主题、长邮件头、模板、跟踪转换、重试和中继路径。负面测试应包括：在测试夹具中故意修改一个已签名的邮件头、缺失的选择器、已过期或已停用的选择器，以及绕过签名的路径。切勿为了制造测试而篡改真实客户的邮件。

把 DKIM、DMARC 和投递作为独立的结果来评估

DKIM 通过意味着验证方发现了由所标识签名域名对已签字段和正文生成的有效签名。它不验证每一个未签名邮件头、不确认作者是否为人、不证明收件人同意、不确立法律合规性，也不保证受理和收件箱送达率。DMARC 会单独评估通过 DKIM 或 SPF 的域名是否与可见 From 域名对齐，并应用域名所有者的策略。对于受控测试，至少记录 DKIM 结果和原因、d= 域名、选择器、可见 From 域名、对齐结果、SPF 结果、DMARC 结果、收件方和时间戳。请勿在日常指标中保留完整收件人地址和内容。SMTP 服务商受理、收件服务器受理、后续退信、邮箱文件夹位置和互动均是之后的状态。如果 DKIM 通过但邮件被拒绝或过滤，请调查 DMARC 对齐、SPF、IP 和域名信誉、投诉率、邮件策略、速率和收件方指导，而不是反复轮换密钥。

轮换密钥时不留下验证空窗

使用相互重叠的选择器。首先生成一个受保护的新密钥，并在新选择器下发布其公钥记录。验证权威和递归 DNS，配置签名方使用新选择器，并通过每一条路径发送受控测试邮件。监控使用新旧选择器的签名所占比例及其验证结果。在排队邮件的最长存留时间、重试窗口和 DNS 缓存时间之外再加上明确的安全余量，在此期间保留旧公钥。然后停止使用旧选择器进行任何签名，确认没有活跃配置仍引用它，再按照策略停用其记录。私钥泄露后的紧急撤销可能需要更快地删除记录、暂停流量、轮换服务商凭据并进行事故通报；请提前把这种取舍写进文档。在常规轮换中，不要原地覆盖同一个选择器，因为被缓存的旧公钥会导致用新私钥签名的邮件验证失败。

从签名本身向外排查故障

如果缺少签名，请确认邮件是否走了未签名的邮件流、未授权的 From 域名、备用中继或其他模板路径。如果找不到密钥，请检查确切的 s= 和 d= 查询、区域委派、权威应答、DNSSEC 或解析器错误以及传播情况。如果正文哈希不匹配，请比较签名前与接收到的原始 MIME，找出签名之后的转换。如果签名不匹配，请确认发布的公钥与正在使用的私钥匹配，并检查规范化方式和已签名的邮件头。如果 DKIM 通过而 DMARC 失败，请评估与可见 From 域名的对齐情况。将暂时性的 DNS 查询错误与持续存在的配置故障分开归类，并且只在 SMTP 响应为暂时性错误时才进行有上限的传输重试。当出现跨域签名、未知密钥、大范围验证失败或怀疑密钥泄露时，请暂停受影响的邮件流。保留经过隐私最小化处理的证据，并在每次受控复测中只改变一个变量。

使用您的发信系统的 DKIM 文档

在实际的发信系统和 DNS 权威服务中配置 DKIM，验证原始接收邮件，并依赖当前 IETF 标准和服务商特定文档。

常见问题

DKIM 公钥发布在哪里？

将其作为 TXT 记录发布在 selector._domainkey.signing-domain，使用出站签名中将会包含的确切选择器和 d= 域名。

DKIM 私钥应该放在 DNS 中吗？

不应该。DNS 中只包含公钥材料。请将私钥保存在托管签名方或机密信息边界之内，并配备范围严格的访问权限和轮换管控。

一个 DKIM 选择器可以在所有邮件服务商之间复用吗？

请避免这种设计。按服务商、签名方、环境或风险边界分别使用独立的选择器和私钥，这样轮换或泄露就不会影响无关的路径。

DKIM 通过是否意味着 DMARC 通过？

不一定。DMARC 要求通过验证的 DKIM d= 域名与可见 From 域名对齐，除非有对齐且通过的 SPF 来满足 DMARC。

为什么加了页脚或改写了跟踪链接后 DKIM 会失败？

DKIM 覆盖选定的邮件头和正文哈希。签名创建之后，超出所选规范化规则范围的下游修改都可能使签名失效。

应如何轮换 DKIM 密钥？

先发布并验证新选择器，在受控条件下将签名切换到新选择器，监控结果，在重试和缓存窗口内保留旧公钥，然后再停用它。

DKIM 决定邮件能否进入收件箱吗？

不决定。DKIM 提供的是有限范围内的域名签名证据。收件方在决定投递结果之前，仍会独立评估 DMARC、SPF、信誉、投诉、内容、发送速率和邮箱策略。

公开 DNS 记录能证明 DKIM 签名已启用吗？

不能。请根据已发布密钥验证原始接收邮件，并确认 DKIM-Signature 邮件头中的 d= 和 s= 值。

参考来源

继续学习

如何检查应用邮件的 DKIM检查 DKIM 的正确方法：查看真实邮件的签名，查询其选择器和域名，验证邮件本身，读取收件方的验证结果，并测试对齐。如何对应用邮件进行 DMARC 检查检查 DMARC 记录的发现、语法、SPF 和 DKIM 对齐、策略、报告以及真实的应用邮件，同时不把一次 DNS 查询误当作投递结果。如何检查应用邮件的 SPF 记录为应用邮件检查正确的 SPF 域名、语法、机制、嵌套 DNS 查询预算、来源 IP 授权、结果以及 DMARC 对齐。如何评估邮件送达率服务从范围、证据、身份验证、反馈环、抑制列表、隐私、可迁移性和运维契合度等方面评估邮件送达率服务。SMTP 邮件协议：应用邮件是如何传输的了解 SMTP 提交、中继、信封、响应码、TLS、重试和邮件内容如何影响应用邮件的工作流程。