IETF Datatracker 于 2026 年 11 月 1 日列出 DKIM2 签名规范的活动草案版本 -09；这次更新不要求你替换现有 DKIM 测试或改生产发信流程。适用条件：继续验收当前实际使用的 DKIM 和邮件收件结果；只有自家测试链路明确支持 DKIM2，才在隔离环境单独验证，并把结果标成草案测试。(IETF DKIM2 草案记录)
这篇给维护自家产品发信与域名认证的开发者、独立开发者和后端工程师，帮你判断现有 DKIM 验收是否还要保留。
如果你负责邮件回归，重点看认证证据与真实收件的区别。
如果你在评估邮件认证更新，重点看何时值得建隔离实验。
最后核查于 2026 年 11 月 7 日：对照了 IETF DKIM 工作组文档页、当前 DKIM2 签名草案及现行 DKIM 规范 RFC 6376，并核对相关邮件头与 SMTP 规范。Datatracker 当时列出的版本是 draft-ietf-dkim-dkim2-spec-09，状态为活动中的 Internet-Draft；文档标示的到期日为 2027 年 5 月 5 日。Internet-Draft 是工作文档，不是已发布 RFC；草案可能继续修订，因此测试结论要绑定版本，不能把这次核查结果当作永久状态。
成熟度：草案版本不能直接变成上线要求
截至上述核查日期，DKIM2 签名规范仍处于草案阶段。当前 DKIM 则有已发布的 RFC 6376 标准作为规范基础，并有后续 RFC 更新。对你来说，这意味着生产验收仍要围绕自家发信链路实际使用的 DKIM 机制，不必因为草案编号更新就把现有回归测试改成 DKIM2 测试。
草案更新值得跟踪，但“草案存在”与“你能在生产链路中验证”是两回事。不要仅凭媒体讨论、技术演示或某个实现的说法，推断接收方或邮件服务商已普遍支持。涉及实现支持时，应逐项核实实现方的正式说明，并确认自己的发信、接收与验证工具是否覆盖对应能力。
兼容性：DKIM 邮件签名与 DKIM2 实验不是一组断言
现行 DKIM 验收通常针对你实际发出的邮件：确认预期的 DKIM-Signature 是否存在，并检查接收侧是否报告 DKIM 验证通过或失败。接收端的 Authentication-Results 头字段用于记录认证方法与结果；它是接收侧提供的认证证据，不等同于邮件到达了哪个文件夹，也不是用户完成注册或密码重置的业务证明。(RFC 8601 对 Authentication-Results 的定义)
DKIM2 草案描述的方向不同：邮件经过处理链时，参与系统可记录对邮件内容或头字段所做的变化，并形成可验证的签名链。这个机制属于草案定义的协议设计，不能反推你的生产系统已经能生成或验证 DKIM2。具体字段、算法及验证要求，应以当前版本草案为准；不要把旧版本实验结果直接当作新版本规范的验收结果。(当前 DKIM2 签名草案)
在当前 -09 草案中，签名值采用 mldsa44 标识时，编码后的签名值长度为 3228 个字符。这是该版本草案里的具体参数，不是现有 DKIM 邮件的通用要求，也不代表任何收件系统已经支持它。如果你在隔离环境实现相关处理，这类长度和头字段折行行为可以纳入兼容性检查；若没有实现，就不要把它加入现有生产邮件的通过条件。
证据：认证通过、发送记录与收件到达各有边界
邮件验收常见的误区，是拿一种证据替代整条链路。你应把证据拆成三类：
- 邮件头中的认证结果：例如接收侧
Authentication-Results中的dkim=pass。它说明该接收侧报告了相应认证结果，不代表邮件一定进入收件箱，也不能证明业务动作完成。(RFC 8601 对认证结果字段的说明) - 发件系统或接收方日志：用于核对发件系统是否提交、接收服务器是否接受或拒绝，以及是否出现传输错误。SMTP 接收服务器接受邮件用于转发或最终投递，和你在目标收件箱中实际看到邮件，并不是同一项观测。(RFC 5321 对 SMTP 传输的说明)
- 受控收件地址中的实际邮件：确认指定收件环境收到了一封邮件，能补足“邮件是否实际到达此处”的证据；但单凭收件本身，不能验证 DKIM2 签名、链条或草案所述机制。
因此，普通开发者测试收件地址可以用于观察当前邮件的实际收件表现，不能被当作 DKIM2 验证器。即使同一封邮件在某个地址成功收到，也不能由此推断其他接收方的过滤结果或生产投递表现。
如果排障重点是“邮件为什么还没出现”，先核对地址、发件记录和等待窗口，再决定是否重发；可参考邮件到达时间窗与排障步骤，避免连续提交验证码后把多封邮件混在一起。如果测试地址需要长期保留或用于账户恢复，则应改选适合长期联系的方案，而不是把一次性收件箱当永久邮箱；临时收件箱与转发别名的区别说明了两者适用场景。
成本：具备独立实现与复核工具，才值得开隔离实验
是否单独测试 DKIM2，先看三个前提：自家链路有明确的 DKIM2 实现；有与生产分开的可控测试域名和配置；有能对照当前草案复核结果的验证工具。缺少其中任一项，就保留当前 DKIM 回归测试并跟踪草案，不要为了“覆盖新标准”造一个无法复核的通过项。
| 选择 | 适用条件 | 验收内容 | 主要限制 |
|---|---|---|---|
| 继续现行 DKIM 测试 | 生产链路目前只使用 DKIM | 核对签名、接收侧认证结果及受控地址中的实际邮件 | 不能证明 DKIM2 能力 |
| 并行开展隔离实验 | 自家有 DKIM2 实现、独立配置和可复核验证工具 | 单独验证草案规定的签名与处理链，并标记所用草案版本 | 实验结果不能代替生产验收，也不能代表其他接收方支持 |
| 暂缓实现，设置复核触发点 | 没有 DKIM2 实现或验证条件 | 保留当前 DKIM 回归，监控草案版本、状态和官方实现说明 | 草案状态变化后仍需重新评估 |
风险控制：把草案版本、原始邮件与结果分开存档
草案持续更新时，最容易造成误判的不是测试失败，而是团队把旧版实验报告误当成新版规范的证明。每次隔离测试都单独记录：
- 草案文档标识和版本，例如
draft-ietf-dkim-dkim2-spec-09，以及核对日期。 - 使用的测试域名、DNS 配置、发件实现和验证工具版本。
- 原始邮件头、验证输出及复现步骤；不要只保存一个“通过”状态。
- 当前 DKIM 回归结果与 DKIM2 草案实验结果，分别归档、分别设定通过条件。
遇到 IETF 发布新草案、工作组文档状态改变或出现正式标准时，先比较新旧文档的变更摘要，再复核相关字段、算法和验证要求。只有确认自家实现受影响，才调整隔离实验；除非实际使用的生产标准和链路发生变化，否则不要把草案试验直接升级为生产门槛。
实操：从现行基线到隔离验证
- 确认生产基线。记录自家系统当前使用的签名机制、发件域名和既有验收断言。不要仅凭发送 API 返回成功，就把邮件认证和收件都标记为通过。
- 发送一封自家测试邮件。使用你有权测试的产品环境或预发环境，保留发件日志和原始邮件。不要用未经授权的第三方平台注册流程造测试账号。
- 核对现行 DKIM 结果。检查邮件头中预期的
DKIM-Signature，并从接收侧记录Authentication-Results。若结果与预期不符，先定位签名生成、邮件改写或接收侧判定，而不是切换到 DKIM2 断言。 - 单独确认收件表现。通过受控收件地址核对邮件是否到达该测试收件环境。把“认证结果”和“实际收件”记为两个结果；任一通过都不替代另一项。
- 评估 DKIM2 实验条件。确认有独立实现、隔离域名和可复核工具后，才按当前草案设计实验。将报告标为草案测试，附上具体版本；没有条件时继续现有回归并暂缓实现。
- 草案变更后重新比对。检查版本、状态和变更摘要，确认旧实验断言是否仍适用。未经复核，不要把旧结果迁移到新版草案或写成生产兼容承诺。
结论：按当前能力选择继续、试验或暂缓
如果你现在只有 DKIM 能力，继续执行既有签名验收和实际收件检查；如果你已经有独立 DKIM2 实现、测试域名和验证工具，可以并行开展隔离实验；如果这些条件不齐，就暂缓实现并设置草案状态复核点。三条路径都不要求仅因草案更新而改生产发信配置。
常见疑问
DKIM2 的规范地位目前如何？
不是。截至 2026 年 11 月 7 日，IETF Datatracker 将签名规范列为活动中的 Internet-Draft，当前版本是 2026 年 11 月 1 日发布的 draft-ietf-dkim-dkim2-spec-09。它仍是工作草案，不是已发布 RFC；草案内容和状态可能继续改变，不能据此推断邮件服务商已普遍部署。
草案版本变化是否要求重做 DKIM 回归？
不会自动失效。现有测试仍应核对你实际发送的邮件是否带有预期的 DKIM-Signature、接收侧认证结果如何，以及测试收件地址是否实际收到邮件。DKIM2 草案更新只意味着你应记录版本并持续复核；除非自家链路已经实现 DKIM2，否则不要把草案试验写成现行验收门槛。
现有邮件测试要怎样覆盖 DKIM2？
只有当自家环境确实能生成并验证 DKIM2 签名时，才适合并行检查两者。把 DKIM2 测试放在与生产隔离的域名和配置中，单独记录草案版本、原始邮件头及验证结果。若链路不支持 DKIM2，继续执行现有 DKIM 回归与实际收件检查，不要制造无法验证的通过项。
当前链路不支持 DKIM2 时，邮件验收从哪里做起？
按当前发送链路验收：检查发件服务的发送记录，查看接收侧 Authentication-Results 中的 DKIM 结果，并在受控收件地址确认邮件确实到达。三类证据分别说明发送处理、认证判定和收件表现；它们都不是 DKIM2 协议验证，也不能单独证明业务流程的全部环节。
如果你要确认自家当前邮件是否实际到达，可以把 MyTempBox 的受控收件作为现行发信验收的一种补充：页面打开后即可使用临时收件地址，无需注册，适合短期测试注册信或通知邮件。它只能帮助你观察该测试地址是否收到邮件，不能替代 DKIM2 协议验证，也不构成邮件必达保证；若账户需要长期找回、持续收信或回信，应选用稳定邮箱或适合长期使用的转发方案。
常见问题
DKIM2 草案目前是正式标准吗？
不是。截至 2026 年 11 月 7 日，IETF Datatracker 将签名规范列为活动中的 Internet-Draft，当前版本是 2026 年 11 月 1 日发布的 draft-ietf-dkim-dkim2-spec-09。它仍是工作草案，不是已发布 RFC；草案内容和状态可能继续改变，不能据此推断邮件服务商已普遍部署。
DKIM2 更新会让现有 DKIM 邮件测试失效吗？
不会自动失效。现有测试仍应核对你实际发送的邮件是否带有预期的 DKIM-Signature、接收侧认证结果如何，以及测试收件地址是否实际收到邮件。DKIM2 草案更新只意味着你应记录版本并持续复核；除非自家链路已经实现 DKIM2，否则不要把草案试验写成现行验收门槛。
测试邮件需要同时检查 DKIM 和 DKIM2 吗？
只有当自家环境确实能生成并验证 DKIM2 签名时，才适合并行检查两者。把 DKIM2 测试放在与生产隔离的域名和配置中，单独记录草案版本、原始邮件头及验证结果。若链路不支持 DKIM2，继续执行现有 DKIM 回归与实际收件检查，不要制造无法验证的通过项。
没有 DKIM2 实际签名支持时，怎样验收测试邮件？
按当前发送链路验收：检查发件服务的发送记录，查看接收侧 Authentication-Results 中的 DKIM 结果，并在受控收件地址确认邮件确实到达。三类证据分别说明发送处理、认证判定和收件表现；它们都不是 DKIM2 协议验证，也不能单独证明业务流程的全部环节成功。