DKIM 密钥：长度选择、DNS 发布与轮换

你的DKIM 密钥是发信 DNS 配置的重要部分。密钥太弱、格式错误或过时，可能影响认证和投递。本文描述了 Gmail 自 2024 年二月实施发件认证要求，并从 2025 年十一月进一步加强执行的背景；应以当前发件规则为准。如果仍在整理 DNS 基础配置，可以先阅读商务邮箱指南，再回来处理密钥。

简要建议是：条件允许时使用 2048 位 RSA 密钥。正确发布 DNS，长 TXT 值通常需要拆为多个带引号字符串。按计划用选择器轮换，并在切换后保留旧记录适当时间，这有助于减少运维风险。

设置新域名时，可同时阅读创建使用自己域名的邮箱和 TrekMail 的必需 DNS 记录清单，一并配置 DKIM、SPF 和 DMARC。

什么是 DKIM 密钥？

这里指 DKIM 签名配置中的公钥。邮件服务器用私钥签名，接收方从 DNS 获取公钥，验证被签名部分的完整性及签名域名的责任。这并不自动证明可见 From 发件人值得信任。

DKIM 全称为 DomainKeys Identified Mail。私钥保存在发送系统，公钥按选择器发布于 DNS，例如 s1._domainkey.example.com。

邮件到达后，接收服务器查看签名，查询密钥，并按指定的规范化方式验证。成功时，可确认：

• 签名覆盖的正文部分与邮件头没有发生影响验证的变化。
• 签名方拥有对应域名和选择器的私钥。

这不保证进入收件箱，但提供了可验证的密码学信号，供现代过滤系统参考。

DKIM 密钥应使用多长？

建议条件允许时使用 2048 位 RSA 密钥，适用于本文讨论的 2025 和 2026 年配置。标准仍允许 1024 位 RSA，但推荐 2048 位以增加安全余量。4096 位密钥会增大 DNS 响应，也可能带来额外兼容性和维护问题。

正式依据是RFC 8301：签名方必须使用至少 1024 位 RSA，且建议至少使用 2048 位。该建议应纳入现代配置规划。

接手旧邮件系统时，不要假定密钥已经合适。旧面板和邮件系统常默认生成 1024 位密钥；过去允许的配置未必是现在的优先方案。

Google 要求批量发件人配置 DKIM，并在常见问题中描述认证失败时可能限速。最新规则见Google 邮件发件指南常见问题。

为什么 2048 位 DKIM 密钥会在 DNS 中出错

2048 位公钥超过单个 TXT 字符串的 255 个八位字节上限。如果面板无法正确处理长值，可能拒绝、截断或错误保存。

容易让人困惑的是，问题通常不是密码学，而是 DNS 管理界面。

2048 位 RSA 公钥在 p= 标签中的值较长，通常要在一条 TXT 记录中拆成多个带引号字符串。将它们拼接的是 DKIM 验证方或应用程序，而不一定是 DNS 解析器。错误发布会影响验证。

常见问题：

• 面板在 255 个字符处截断记录。
• 面板往密钥中加入多余空格或换行。
• 发布成多个 TXT 记录，而不是同一记录中的多个字符串。
• 为了缩短记录，删除了 v=DKIM1; k=rsa; p= 前缀的一部分。

这些错误不会把密钥变弱，而会使其无效。

如何正确发布 2048 位 DKIM 密钥

每个选择器发布一条明确的 TXT 记录，只在该记录内部拆分字符串。验证应用会拼接它们。你的任务是保持语法正确，并用命令行核实准确的 DNS 响应。

区域文件语法示例：

s1._domainkey.example.com. IN TXT (
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
  "...rest_of_the_public_key_here...QAB"
)

许多网页管理界面要求放在同一行：

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..." "...rest_of_the_public_key_here...QAB"

然后从外部验证，不要只相信界面预览：

dig txt s1._domainkey.example.com +short

TXT 响应应完整。出现两个带引号字符串很正常。若缺段、转义异常或输出不全，应核对实际发布内容和查询工具，确认原因。

使用 TrekMail 时，可按托管 TrekMail SMTP及 DNS 向导操作。文中描述付费套餐包含托管 SMTP，并在面板中显示域名所需的DKIM 记录值。Starter 起价为每月 $3.50，付费套餐提供 14 天免费试用，需要信用卡；Nano 描述为免费并使用自带 SMTP。请核实当前功能与条件。

示例：你生成了 2048 位密钥，注册商却悄悄截断长 TXT。邮件仍能发出，直到接收方认证失败才暴露问题。因此必须从外部验证。

如何降低 DKIM 密钥轮换对邮件的影响

创建新选择器、发布新公钥、切换签名，并在适当过渡期保留旧选择器。避免直接覆盖活跃密钥。使用新选择器有助于延迟或重试的旧邮件仍能通过验证。

较谨慎的流程：

1. 生成新的 2048 位密钥对。
2. 分配新选择器，如 s2。
3. 在 DNS 发布 s2._domainkey.example.com。
4. 将出站签名切换到 s2。
5. 保留 s1 适当的数天过渡期。
6. 确认旧签名邮件不再依赖密钥后，移除 s1。

7 天可以作为过渡期示例，但不是通用保证，应根据邮件队列、重试和 DNS 缓存调整。若私钥已泄露，立即撤销可能比保留旧邮件验证更重要。

除非能控制签名、缓存和延迟邮件的各种影响，否则不要在同一选择器下替换旧密钥。选择器正是用于区分密钥的。

多个发送系统共用域名时，应记录每个选择器归属，便于排查 CRM、工单平台、网页应用和普通邮箱的错误。

什么时候应轮换 DKIM 密钥？

按固定计划轮换，并在可能泄露、切换供应商或迁移发送平台后额外处理。半年一次可作为起点，高风险环境可能需要更短周期。可预测的政策比随机单次操作更有利于管理。

若私钥可能泄露，应立即行动；没有异常时也应按计划轮换并验证。

提前轮换的合理原因：

• 将出站邮件迁移到新供应商。
• 停用曾拥有签名权限的供应商。
• 曾通过不安全流程导出密钥。
• 发现用途不明的旧共享管理员账号。

不应作为拖延理由的说法：

• “以后有空再做。”
• “现在还能通过，所以没问题。”
• “不记得私钥在哪里。”

管理大量客户域名时，这成为流程问题而不只是密码学问题。这也是多域名邮箱托管的重要性所在：一个域名可手动管理，五十个需要规范流程。

是否应该为 DKIM 使用 Ed25519？

Ed25519 密钥短得多，可以减少 RSA-2048 长 TXT 的问题，但必须检查接收方兼容性。它在 RFC 8463 中被标准化用于 DKIM；需要广泛互通时，RSA-2048 往往是更保守的起点。

主要优点是体积。Ed25519 公钥远小于 RSA，DNS 发布也更简单。

主要缺点是不同接收方和工具的支持差异。RSA-2048 应用广泛，也不保证通用兼容。如果平台支持双签名，且了解下游路径，可将 Ed25519 与 RSA 一起测试。

多数管理员可采用以下思路：

• 优先以 RSA-2048 作为基础配置。
• 只有理解接收方支持并能充分测试时，才使用 Ed25519。
• 不要仅因 DNS 记录更短就改成只用 Ed25519。

旧方式与新方式：规模化管理 DKIM

旧方式是逐个编辑 TXT，把长公钥粘贴到不同注册商界面，并依赖大家记得轮换。新方式是集中、可重复地管理 DNS 和签名，让密钥生命周期成为邮件平台流程的一部分。

旧方式：

• 每个域名使用不同 DNS 界面。
• 轮换依赖容易被忽略的日历提醒。
• 注册商的一次拼写错误影响客户邮件，直到投递变差才被发现。

新方式：

• 多个域名采用同一流程。
• 托管 SMTP 有助于统一签名配置。
• 减少反复排查长 TXT 和认证配置偏差的工作。

TrekMail 描述的固定费用多域名托管不按用户收费，并包含共享存储、IMAP 邮箱、内置 IMAP 迁移、catch-all、转发、Nano 的 BYO SMTP 和付费套餐的托管 SMTP。当前功能请确认。已有多个转发规则时，也要检查认证变化，可参考将域名邮件转发到 Gmail。

对团队和代理机构而言，潜在收益是规范重复流程，而不是让 DNS 保证不出错。文中 Starter 价格从$3.50/月开始，请核实最新条件。

关于 DKIM 密钥的总结

条件允许时采用 RSA-2048，正确发布 DNS，核实实际查询结果，并按计划用选择器轮换。现有 1024 位密钥应评估升级。如果 DNS 面板破坏长 TXT，应修正发布方式，或交给合适的平台管理。

不要单独看 DKIM。SPF、DMARC 与实际发送基础设施也要配置正确。下一步可阅读 TrekMail 的必需 DNS 记录和创建使用自己域名的邮箱指南。