DKIM 设置是自定义域名发信配置的重要组成部分。密钥缺失、损坏、被截断，或签名域名不正确，都可能影响认证结果与收件箱投递。本文介绍运维流程：生成密钥、发布 DNS 记录、用命令行验证，并排查那些即使出现绿色状态仍可能导致 DMARC 失败的域名对齐问题。
如果需要包含 MX、SPF、邮箱和客户端设置的完整基础配置，请先阅读创建使用自己域名的邮箱。如果还在选择平台，商务邮箱指南介绍了更全面的选择因素。
大多数 DKIM 设置失败并非密码学问题，而是复制 DNS 内容出错、管理面板重复附加域名、2048 位密钥被破坏，或邮件服务商使用自己的域名签名而非你的域名。排查错误方向可能耗费数小时，一套可重复的流程能减少这种浪费。
DKIM 设置究竟做了什么
设置 DKIM 时，公钥发布在 DNS 中，邮件服务器用对应的私钥为邮件签名。接收服务器验证签名，确认签名域名对邮件承担责任，并检查被签名覆盖的关键邮件头及正文是否在传输中发生变化。
DKIM 使用非对称密码学。发送系统保管私钥，DNS 发布公钥。邮件发出时会带上 DKIM-Signature 邮件头，其中包含签名域名（d=）和选择器（s=）。接收服务器在 DNS 中查询该选择器，再根据邮件内容验证签名。机制定义见RFC 6376。
自 2024 年二月起，Google 加强了批量发件人的要求。Google 要求此类发件人同时配置 SPF 和 DKIM，并且至少一个与可见 From 邮件头的域名对齐，以通过DMARC 对齐检查。请查看 Google 的发件要求常见问题，核实最新表述。
这说明，技术上有效的签名不一定满足实际需求。DKIM 配置错误或缺乏对齐，仍可能伴随 DMARC 问题和垃圾邮件归类。
修改 DNS 前，先确定谁负责签名
正确设置 DKIM，首先要确定哪个系统真正为邮件签名。迁移、变更转发或切换供应商时，这一点尤其容易被忽略。应在哪里生成或获取DKIM 记录，完全取决于实际发送路径。
先问一个问题：该域名的出站邮件由谁发送？
- 如果由 Google Workspace 发送，在 Google Admin 中生成 DKIM 密钥。
- 如果由 Microsoft 365 发送，在那里启用 DKIM。
- 如果由 SendGrid、Mailgun 或 Amazon SES 发送，在对应供应商中认证域名。
- 如果由 TrekMail 托管 SMTP 发送，使用 TrekMail 显示的 DKIM 值。
- 如果 TrekMail 只管理邮箱，发送使用外部 SMTP，则按 SMTP 供应商的签名说明操作，再按需在 TrekMail 中配置 SMTP。
TrekMail 描述了两种路径：Nano 使用 BYO SMTP，付费套餐可以使用托管 SMTP。自带 SMTP文档提供 SES、SendGrid 和 Mailgun 示例。其送达故障排查文档还说明，托管 SMTP 使用你的域名 DKIM 密钥签名；如果签名保持有效且对齐，这有助于邮件经过转发或中继后通过 DMARC。使用前请核实当前套餐功能。
例如，邮箱存放在 TrekMail，但出站邮件走 SendGrid，那么签名方必须是 SendGrid。TrekMail 可以存储邮箱，但不会因此自动完成 SendGrid 的 DKIM 设置。
第一条基本规则是：在真正签名的系统中生成密钥。如果在其他地方生成，DNS 里可能有记录，实际发送却根本不会使用它。
DKIM 记录类型：TXT 与 CNAME
DKIM 设置通常需要发布包含公钥的 TXT 记录。一些供应商则要求发布一条或多条 CNAME，指向他们托管的密钥。两种方式都可以，关键是严格使用发送服务提供的配置值。
传统 DKIM 的 TXT 记录位于：
selector._domainkey.example.com值大致如下：
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...托管服务常使用 CNAME，这样供应商可以轮换密钥，而不必每次要求客户修改 DNS。TXT 提供直接控制，但也意味着需要自行负责必要的密钥更新。
| 方法 | 发布内容 | 适用场景 | 主要风险 |
|---|---|---|---|
| TXT | DNS 中的完整公钥 | Google Workspace，以及许多自行管理或直接接入供应商的配置 | 长密钥被截断或复制错误 |
| CNAME | 指向供应商 DKIM 记录的别名 | 托管平台及更方便的密钥轮换 | 目标错误，或多条必需记录中漏了一条 |
常见陷阱在主机名字段。如果域名是 example.com，选择器是 k1，主机名通常填：
k1._domainkey而不是：
k1._domainkey.example.com许多 DNS 面板会自动附加主域名。在这种面板中填入完整名称，可能最终发布成 k1._domainkey.example.com.example.com。接收服务器就无法在预期位置找到记录。
TrekMail 的必需 DNS 记录文档可作参考。文档也指出，有些 DNS 供应商要求将 DKIM TXT 值拆成多个带引号的部分。
在 DNS 中逐步设置 DKIM
实用流程很简单：取得选择器、发布记录、等待 DNS 更新、核实准确响应，并在供应商要求时最后启用签名。跳过验证，就不能确认设置结果。
按以下步骤操作：
- 打开发送供应商的管理界面，生成或显示 DKIM 记录。
- 准确复制选择器；除非供应商支持，否则不要改名。
- 在
selector._domainkey创建 DNS 记录。 - 原样粘贴完整 TXT 值或 CNAME 目标。
- 无其他要求时，将 TTL 设置为 3600。
- 等待 DNS 更新。
- 发送生产邮件前，用
dig或nslookup验证。 - 如果供应商界面有最后的激活开关，启用签名。
TXT 配置示例：
; DNS record
k1._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A..."CNAME 配置示例：
; DNS record
s1._domainkey.example.com. 3600 IN CNAME s1.domainkey.u123456.wl.provider.net.DNS 更新可能很快出现，但不会立即在所有地方生效。TrekMail 排查文档提到常见情况约为 5 到 15 分钟，这只是参考，不是保证。状态仍未变化时，应检查格式、重复记录和主机名，并考虑 TTL 与缓存响应。
DKIM 设置与 2048 位密钥问题
供应商和 DNS 主机支持时，现代 DKIM 配置宜采用 2048 位 RSA 密钥。它们的密码学强度更高，但也更长，旧管理面板可能处理不当。被截断的密钥尤其容易误导：看起来已发布，验证却失败。
Google 文档同样建议在支持时使用 2048 位密钥，不支持较长记录的主机可退回 1024 位。实际问题往往不在 DNS 协议，而在前面的管理面板。
2048 位 DKIM 配置损坏常见于以下情况：
- 面板悄悄截短值。
- 面板要求拆成带引号的字符串，却没有说明。
- 面板在 Base64 密钥中插入换行。
- 面板使用了供应商未预期的字符转义。
如果 DNS 主机要求拆分字符串，可按如下方式发布：
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr..."
"restOfTheKeyContinuesHereWithoutAddingSpacesInsideTheBase64Data"接收方会拼接这些部分，这是正常行为。但不要在实际密钥数据内部加空格，一个多余字符就可能使验证失败。
管理多个域名时，运维成本会在这里显现。有的注册商能正确处理长 TXT，有的不能，还有的会改写值。所以代理机构常统一使用较少的注册商，或在条件允许时采用供应商托管的 CNAME 密钥。多租户场景的整体运营方式可参阅多域名邮箱托管。
验证 DKIM：不仅看面板，还要看 DNS 和真实邮件
面板显示“已激活”并不能单独证明配置正确。完整验证需要直接查询公共 DNS、检查返回记录，再核实真实邮件头中的签名域名和选择器是否符合预期。少了这些，就只是部分检查。
先使用命令行：
# macOS / Linux
dig txt k1._domainkey.example.com +short
# Windows
nslookup -type=txt k1._domainkey.example.com应看到完整的 v=DKIM1 记录，或可拼接为完整密钥的带引号字符串。若结果为空，按顺序检查：
- 选择器是否正确。
- 主机名字段是否重复附加域名。
- 记录类型是否符合供应商要求。
- 值是否完整、未被截断。
- 旧记录是否仍在缓存中。
然后向 Gmail 或其他可查看邮件头的邮箱发送测试邮件。查找认证结果和 DKIM 签名行：
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...
Authentication-Results: ... dkim=pass header.d=example.com ...如果 DNS 正常但收件箱投递仍不理想，就要检查更高一层的因素。TrekMail 的邮件进入垃圾邮件文件夹指南提到 DNS 状态、域名预热、名单质量和内容。DKIM 解决的是认证的一部分，并不会自动获得良好声誉。
也要注意转发场景。邮件转发后 SPF 经常失败；若被签名的数据未变，有效且对齐的 DKIM 签名在许多场景中仍可支持 DMARC 通过。涉及转发时，可阅读邮件转发，不要把转发导致的 SPF 失败误认为所有认证都失败。
DKIM 设置与域名对齐陷阱
许多“正常运行”的 DKIM 配置会在对齐环节出问题。即使签名有效，如果签名域名与用户看到的 From 域名不对齐，并且没有成功且对齐的 SPF，DMARC 仍可能失败。有时原因在 DNS，但通常是供应商设置。
典型情况如下：
From: ceo@example.com
DKIM 签名域名：d=sendgrid.net
结果：DKIM 可以通过，但由于签名域名与example.com不对齐，DMARC 对齐仍可能失败。
Google 对批量发件人的要求是，可见 From 域名必须至少在组织域名层面与 SPF 或 DKIM 对齐。如果邮件供应商只使用自己的域名签名，该签名并不能提供你所需的 DKIM 对齐。
供应商可能把相关设置称为域名认证或白标配置。自定义 Return-Path 主要影响 SPF 对齐，不会单独改变 DKIM 签名域名。对于 DKIM，最终签名应类似：
DKIM-Signature: ... d=example.com; s=s1; ...这样的对齐 DKIM 有助于 DMARC，是投递配置的重要部分，但不保证邮件一定进入收件箱。
DKIM 设置的旧方式与新方式
旧方式是逐个手动处理每个域名、供应商、选择器和 DNS 特例，容易出错。新方式强调标准化：选择可重复的发送模型、集中检查 DNS，并让多个域名使用同一套操作流程。
| 旧方式 | 新方式 |
|---|---|
| 在任意工具里生成密钥，再期待它匹配发送方 | 在实际签名的发送系统中生成 DKIM |
| 逐个粘贴 TXT，等出现支持工单再处理 | 尽可能采用供应商托管签名，并用命令行验证 |
| 把每个域名当成特殊案例 | 所有客户和团队域名使用同一套流程 |
| 活动失败后才排查垃圾邮件问题 | 首次生产发送前检查 DNS、对齐和邮件头 |
TrekMail 描述了这种模型：在一个控制面板中管理多个自定义域名，使用共享存储而非逐邮箱付费，通过 IMAP 迁移已有邮箱，并按套餐选择 BYO SMTP 或内含 SMTP。文中付费套餐起价为$3.50/月，实际价格与功能请以当前套餐为准。平台面向希望减少邮件基础设施维护工作的团队、中小企业、代理机构和 MSP。
如果更大的问题是流程而非 DNS，请阅读客户邮箱管理。多域名环境中的送达问题，常与职责不清有关。
最终 DKIM 设置检查清单
完善的设置应包括正确的签名系统、正确的 DNS 主机名、完整未损坏的密钥、公共 DNS 验证，以及 DMARC 所需的对齐。任何一环出错，都可能削弱整体认证配置。
- 确认哪个系统为出站邮件签名。
- 准确发布供应商提供的选择器和记录类型。
- 主机名字段使用
selector._domainkey，除非 DNS 主机明确要求完整名称。 - 保持 2048 位密钥完整，仅在 DNS 面板要求时拆分带引号字符串。
- 用
dig或nslookup验证。 - 发送测试邮件，检查
dkim=pass和对齐的header.d。 - 上线后检查 DMARC 结果。
DKIM 的关键不是复杂，而是准确。若想减少配置依赖，可以在 TrekMail 中统一域名和发送路径，让 DNS 检查集中可见。同时，仍要核实每条实际使用的发信路线。
