打开率下降时，不要只改主题，也要结合测量限制检查 DNS，尤其是DKIM 记录。打开率本身并不能证明 DKIM 出错。
SPF 检查某个信封域名的连接 IP，DKIM，即 DomainKeys Identified Mail，则像对签名覆盖数据加盖的封印。它提供密码学验证，但不证明个人身份或邮件所有数据直到收件箱都未变。自 2024 年起，Google 与 Yahoo 对适用批量发件人加强验证要求。缺少有效 DKIM 可能导致过滤或拒收，却不代表所有邮件必然不可见。
对独立创始人，配置可能是示例中十分钟的工作，不是承诺时限。对管理 500 个域名的 MSP，密钥轮换、选择器与 DNS 语法检查是持续任务，也可能在周五晚上 9 点变成需要处理的问题。
本指南从运维角度介绍DKIM 记录的 DNS 工作方式、TXT 单字符串 255 字节限制，以及 ESP 绿色标记与真实发送状态不一致时的诊断方法。
什么是 DKIM 记录
DKIM 记录在 DNS 中发布公钥，通常使用 TXT。收件服务器用它验证所声明签名域名的签名与覆盖的数据，并不自动证明可见 From 或作者个人身份真实。
密钥位于 selector._domainkey.yourdomain.com，其中 selector标识签名方选择的密钥。缩略示例：
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC...v=DKIM1指定版本，k=rsa指定算法，p=是 Base64 编码公钥。以上片段不完整，不能部署。对应私钥应由签名方安全保管，绝不能发布到 DNS。创建 DKIM 记录的完整指南解释各字段与配置步骤。
DKIM 签署哪些数据
DKIM 不只是安全设置中的复选框。它把签名覆盖数据与签名域名联系起来，按指定规范检查完整性，不是证明个人身份或所有消息字节完全未改。
签名方处理选定邮件头，通常包括 From、Subject、Date、To与Message-ID，以及邮件正文，按规范化规则计算哈希，通常采用 SHA-256。From 必须签署，其他列举头部依具体签名而定。用私钥生成对应签名，再放入 DKIM-Signature头随邮件传送。
Gmail、Outlook 或其他收件方通常进行以下检查：
- 读取
DKIM-Signature中的域名与选择器。 - 查询
selector._domainkey.yourdomain.com处的公钥。 - 使用公钥验证密码学签名，不是解密邮件内容。
- 重新计算所收到签名覆盖数据的相关哈希。
- 比较结果并检查其他有效性条件，成功可得到 DKIM pass，错误可导致 DKIM fail。
通过验证确认两项有限属性：相对于发布密钥的签名真实性，以及按规范化和签名范围验证的完整性。允许的规范化可能不保留每个字节，也不是所有头部都必须签署。有效公钥使验证成为可能。机制说明见RFC 6376，也可用于与管理员讨论实现是否合规。
转发与 DKIM 的作用
客户高管把账单发给企业联系人，对方又转到个人 Gmail。若原信封域名未改而转发 IP 未被授权，SPF 可能失败。但只有既没有成功且对齐的 SPF，也没有任何有效对齐的 DKIM 时，DMARC 才失败。随后过滤或拒收取决于收件方。
若签名及覆盖数据在规范化后仍有效，且公钥可用，DKIM 可能在转发后保留。最终服务器能验证原始签名，虽然连接 IP 不同。中间节点不必然破坏验证，但它对数据的修改可能造成影响。
重要发送路径不能只依赖 SPF。配置适当 DKIM，并结合SPF 设置；基础见邮件 SPF 记录。DMARC 可使用两个验证途径中的任意一个成功对齐结果，不要求两者同时通过。
TrekMail 支持的转发可能使用 SRS，把信封发件人改为转发方域名以便检查其 SPF，但不恢复原始 From 的 SPF 对齐。具体托管或 BYO SMTP 路径的 DKIM 支持及签署行为，应按当前文档与实测检查，不能假定全部发送都自动签署。
用选择器管理多个 DKIM 密钥
DKIM 选择器告诉收件服务器从哪里获取公钥。选择器错误是常见故障来源，但不能把它当作已经证实的多数配置错误原因。
SPF 在每个验证 DNS 名称只允许一个 SPF 策略。DKIM 可在不同选择器名称下发布多个密钥，例如 selector._domainkey.yourdomain.com。按实际需要可同时启用十个选择器，例如每个发送服务一个，但仍受供应商功能和实际配置限制，不表示套餐无限制。
为何使用多个选择器
同时使用 Google Workspace 做企业邮件、Mailchimp 做简报时，通常建议各自独立密钥与选择器。共享私钥在技术上可能，但会扩大访问范围与泄露影响。可分别配置：
- Google Workspace：可能使用
google，发布名称为google._domainkey.yourdomain.com。 - Mailchimp：示例为
k1或k2，对应k1._domainkey.yourdomain.com。请核查实际分配值。 - TrekMail：示例选择器
tm1及名称tm1._domainkey.yourdomain.com，按实际指南选择 TXT 或 CNAME。
营销平台泄露时，可针对其 k1选择器撤销，而不主动改变 Google 企业密钥。不过，不保证完全无中断，也不隔离全部信誉影响。选择器指南介绍语法、命名与查找 ESP 分配值的方法。
典型配置错误
DNS 界面自动追加域名，本想发布 google._domainkey.yourdomain.com，结果成了 google._domainkey.yourdomain.com.yourdomain.com。错误名称的记录存在，正确名称的查询却可能得到 NXDOMAIN。之前的 ESP 验证标记并不排除这种情况。检查 DNS 状态帮助定位查询，但不是即时诊断保证。
密钥长度与轮换
密钥强度是 DKIM 安全的重要因素。要求会变化，五年前适当的配置也应按今天的规则重新评估。
采用 2048 位 RSA 密钥
1024 位 RSA 曾广泛使用。Google 按其当前规则要求最低长度，并在支持时推荐 2048 位；Yahoo 要求需单独核查。旧 cPanel 或 Postfix 的 1024 位设置，例如 2019 年前配置，值得检查，但并不只因年代旧就自动无效。
512 位密钥不适合当前要求。dkim=perm_fail且理由为“weak key”或“policy”可能提示此类问题，但应核实具体诊断。准备新的 2048 位密钥并受控切换，不能忽略在途邮件直接删除旧公钥。现行规则见Google 发件指南。
多久轮换一次
年度轮换可作为运维政策，但不是所有环境统一的强制最低周期。服务器被入侵、秘密管理配置错误或权限过宽导致私钥泄露时，应及时遏制、撤销并替换。攻击者可能在密钥仍被接受时签署邮件，而非必然无限期使用，或只能等邮件域名信誉受损才发现。
像保护敏感密码一样保护 DKIM 私钥。生产系统五年不检查不是合理默认方式。权限保护、轮换与事故响应需要一起安排。
如何处理 TXT 的 255 字节限制
首次转为 2048 位时可能遇到长度问题。一个 2048 位公钥的 Base64 编码约为 400 字符，而 DNS TXT 每个字符串上限为 255 字节。部分面板自动拆分，部分会拒绝或可能错误处理，不能断言大多数服务商都静默截断。
长内容可拆为同一 TXT 记录内多个带引号字符串，RFC 6376 规定收件方将其连接验证。多个独立 TXT 密钥记录不是相同做法。
不完整的单字符串示例，不能作为有效密钥部署：
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3...两个字符串的拆分原理，需用完整真实公钥替换占位内容：
( "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7bq3"
"...rest_of_key_here..." )输入语法依 DNS 服务商而异。括号适用于区域文件等语法，面板可能需要另一种输入形式。常见服务商 DNS 设置包括 Cloudflare、Route 53、GoDaddy 等说明。确认最终是一条 TXT，而非多条独立记录。
支持的 CNAME 委派可减少本地输入长密钥的工作。示例名称远短于 255 字符，但 CNAME 受不同 DNS 限制，且同名不能并存 TXT。服务商管理目标仍需考虑目标 TXT、缓存、密钥匹配及旧签名。相同选择器直接换钥可能破坏在途邮件，应采用协调轮换与重叠选择器。
配置验证流程
发布 DKIM 后，不能只信“Verified”标记。面板与解析器可能缓存信息，名称和内容也可能改变。查询权威 DNS、其他相关解析器，并检查真实邮件；单个实时 DNS 查询不是唯一或完整的证据。
步骤 1：查询发布名称
Linux/macOS 可使用以下命令。Windows 在命令提示符中使用 nslookup：
# macOS / Linux
dig txt selector._domainkey.yourdomain.com +short
# Windows
nslookup -q=txt selector._domainkey.yourdomain.com将 selector替换为实际选择器，yourdomain.com替换为真实域名。
核查解析到的公钥数据，v=DKIM1可标识版本，但公钥 TXT 中该项可省略。NXDOMAIN表示被查询的解析器认为名称不存在。出现 NXDOMAIN时检查选择器、完整名称、权威答案和缓存。30 分钟后再查只是示例，并非全球已更新的保证。
步骤 2：验证公钥内容
名称存在但验证仍失败时，检查实际输出：
dig txt selector._domainkey.yourdomain.com +short检查两方面：
- 截断：Base64 字符串少于 200 字符，而预期为 2048 位密钥，可能意味着不完整。但长度仅为线索，要验证字符串连接和解码后的实际公钥。
- 字符变化：面板可能改变或另行显示 Base64 中的换行、空格与反斜杠，并非每个合法空白都破坏密钥。比较解码公钥与可信来源，区分显示转义和真实内容。
步骤 3：发测试邮件并读头部
发往自控 Gmail，在三点菜单选择“显示原始邮件”。查看可信收件系统添加的 Authentication-Results：
Authentication-Results: mx.google.com;
dkim=pass header.i=@yourdomain.com header.s=selector header.b=AbCdEfGh;
spf=pass (...);
dmarc=pass (...)dkim=pass表示该签名验证成功，不保证 DMARC 对齐或收件箱投递。fail、neutral、perm_fail与temperror应结合实现与理由阅读；命名可能不同，Neutral 也不必然表示坏配置。完整设置指南与首次配置检查表帮助核对相关验证步骤。
DKIM 故障的三种场景
记录存在、选择器正确、DNS 看似可用，邮件仍验证失败时，需要调查实际数据与处理步骤，“应该能用”不足以解释问题。
完整故障指南还介绍其他错误类型。以下三种场景是实践示例，不是已证实的生产故障排名。
场景 1：“Body Hash Did Not Verify”
正文哈希不匹配可能影响邮件送达。收件方获取的签名覆盖正文经过规范化后，与签名中的哈希不一致。这不证明头部签名已通过密码学验证，也不说明责任必然在发件人。
可能原因：
- 外部发件人警告：网关添加“外部邮件：请谨慎处理”类提示。若先改签名覆盖正文再验证 DKIM，可能使签名失效。Microsoft 365 的邮件流规则等配置应核查处理顺序。
- 法律声明页脚：网关添加 15 行法律声明。若原服务器先签名，再追加页脚，可能改变正文哈希。必要时应在最后受控修改之后由网关签名。
- 安全工具改写 URL：Mimecast、Proofpoint 与 Defender for Office 365 可能把
google.com改成protect.mimecast.com/s/...。改动签名覆盖正文可能破坏验证，但要考虑规范化与覆盖范围。
应在自己控制的基础设施完成最后修改后签名。收件方之后的修改并不能由发件方晚签名解决，应在修改前检查，或按具体流程处理。TrekMail 的签名位置也需按实际路径验证，不能据此保证收件方看到的内容完全相同。更多诊断见发送错误排查。
场景 2：对齐问题
可信头部中可能显示：
dkim=pass (signature was valid)DKIM 通过，DMARC 却可能失败。原因之一是DKIM 未对齐，且没有其他有效对齐途径。进入垃圾箱并不是必然结果。
DMARC 不仅检查签名有效性，还比较 d=域名与Header From域名。Strict 要求完全一致，relaxed 可允许相同的适当组织域名。
示例：
Header From: ceo@yourcompany.com
DKIM d= tag: sendgrid.net签名对sendgrid.net有效。收件方按发件域名及其 DMARC 策略检查与 yourcompany.com的对齐。sendgrid.net != yourcompany.com说明此签名未对齐。只有既没有成功对齐 SPF，也没有另一有效对齐 DKIM 时，DMARC 才失败。
ESP 支持的域名验证或自有签署，可采用适当DKIM 密钥，使 d=使用yourcompany.com而非sendgrid.net。功能与具体值依服务商而异。阅读其指南和DMARC 对齐说明，不要把供应商签名本身视为错误。
场景 3：旧密钥或弱密钥
过时密钥可能产生永久 DKIM 错误。dkim=perm_fail且理由为“policy”或“weak key”可能指向 512 或 768 位密钥，但不证明准确长度。此类长度不满足当今相关要求，应核查具体接收诊断。永久 DKIM 结果也不等于必然永久 SMTP 拒收。
先生成新的 2048 位密钥对与新选择器，发布并检查后再切换签名。旧公钥应保留给仍需验证的旧邮件，除非安全事故要求紧急撤销。下方本地生成建议和 DKIM 记录生成器指南帮助安排安全操作。
安全生成密钥
配置 DKIM 需要密钥对。搜索结果中的首个网站可能直接在屏幕显示密钥。使用前应先判断生成发生在何处、谁能访问私钥。
浏览器显示私钥并不自动等于泄露，例如可信、可核查的本地生成。但未知服务器端工具可能保存或暴露秘密，没有充分信任就不应使用它生成生产密钥。密钥被接受期间攻击者可能签署邮件，不是撤销后仍可无限使用，也不必然没有迹象。
比较生成方式
| 方式 | 安全评估 | 适用人员 | 说明 |
|---|---|---|---|
| 服务商管理：TrekMail、Google、Microsoft | 防护适当时可行 | 信任服务商及其管理模型的用户 | 核查保存和访问措施，不能假定都有 HSM。DNS 只需公钥。 |
| 本地使用 OpenSSL | 系统与密钥处理安全时适当 | 自托管 Postfix 或 Exim 管理员 | 控制权限、备份与传输路径，属于手动过程。 |
| 网页 DKIM 生成器 | 未知服务仅用于可丢弃测试 | 隔离开发环境与测试域名 | 不要把生产私钥交给未知工具，本地浏览器生成应另行评估。 |
自有且安全管理的服务器可使用 OpenSSL：
# Generate the private key
openssl genrsa -out dkim-private.key 2048
# Extract the public key
openssl rsa -in dkim-private.key -pubout -out dkim-public.key
# View the public key for DNS (strip headers, format as single line)
cat dkim-public.key用正确权限保护私钥文件，不能放进 DNS 或不受控传输。最后命令只显示公钥 PEM，不自动去掉头尾；发布 DKIM 前应正确整理公钥数据。有人要求通过邮件发送私钥以供“验证”时，应视为严重社会工程风险信号。
创始人、代理商及其他运维人员可交由防护适当的服务商生成密钥，但要明确保护方式与责任，不能只信“托管”标签。
手动与自动化管理
轮换会显示每条 DKIM 记录的维护成本。发布的密钥需要定期检查。年度操作示例如下：
每域名年度手动示例流程
- 生成新 RSA 密钥对与新选择器，例如
s2026。 - 在
s2026._domainkey.yourdomain.com发布新公钥。 - 48 小时是示例缓冲，应确认实际公开和相关缓存状态后再切换。
- 受控调整签名服务使用新私钥，并发测试邮件。
- 示例保留两个公钥选择器 7 天；实际应按队列、在途邮件及签名验证期限安排。
- 过渡期结束或需要紧急安全撤销时移除旧公开选择器。
- 按保存与事故处理规则，在安全切换后销毁旧私钥。
示例有 7 步，每年 50 个域名即 350 次操作。实际工作与容错取决于工具。漏掉步骤 5 可能影响在途旧签名。步骤 6 则需分清必要过渡保留与不必要的持续信任。
| 方式 | 各域名年度工作 | 人为错误风险 | 适合 100+ 域名吗 | 成本 |
|---|---|---|---|---|
| 手动自托管 Postfix | 7 个示例步骤及测试 | 取决于工具和检查 | 适当自动化时可行 | 基础设施与运维时间 |
| ESP 自有域名验证 | 初次设置与按服务流程轮换 | 取决于服务商流程 | 取决于 ESP 工具 | 依服务与合同而异 |
| TrekMail CNAME 方式 | 配置委派并持续检查 | 减少本地更改，但不为零 | 1,000+ 需按现行套餐和运维条件确认 | 核查当前包含服务 |
单个域名通常可手动维护。对 50 个域名，清单、监控与自动化有助于避免漏轮换。缺少它们可能导致周五排错，但不是必然。
TrekMail 的 DKIM 管理
TrekMail 面向多域名运维，例如创始人的五个副项目或 MSP 的 800 个客户域名。实际 DKIM 功能应按当前指南检查。
通过 CNAME 轮换
支持的 CNAME 设置中，向导可提供以下例子。应使用实际分配的名称与目标：
tm1._domainkey.yourdomain.com CNAME tm1._domainkey.trekmail.net委派可能减少轮换时本地 DNS 操作。服务商管理目标，但同一选择器直接替换密钥可能使旧签名失效，应协调重叠选择器、缓存与在途消息。CNAME 不变并不保证无中断或无监控需要。对 80 个域名，集中管理可能有帮助，却不能取消所有提醒与检查。
原文列 Pro 每月 $8、100 个域名，并以每年 700 次手动操作比较。现价、限额与实际节省工作应核查，该算式不是保证节省。
DNS 配置向导
可用向导可能集中生成 MX、SPF、DKIM、DMARC 建议并检查。但发送清单、真实值、DNS 发布、缓存与实际邮件仍需验证，标记也不是普遍保证。参考必需 DNS 记录。
固定套餐而非只按用户收费
原文列 Starter 每月 $3.50、50 域名、每域名 100 用户；Pro 每月 $8、100 域名、每域名 300 用户；Agency 为 1,000+ 域名。这些历史条件及共享存储模式应按现行套餐核实。创建更多邮箱不表示无限使用或没有任何额外费用。
DKIM 的可用性、配置与实际签署路径依当前套餐和 SMTP 模型而定，应核查服务范围，不能从固定收费推导所有路径默认同样验证。
自主管理与 TrekMail 比较
| 自主管理 | TrekMail 依当前服务范围 | |
|---|---|---|
| 首次 DKIM 设置 | 生成密钥、设置 Postfix、发布 DNS 与测试 | 添加域名、发布适当委派并验证实际签名 |
| 年度轮换 | 示例手动 7 步 | 服务商支持的轮换仍需检查 |
| 添加域名 | 按实际需求重新设置与测试 | 发布实际分配 CNAME 或 TXT 并检查 |
| DKIM 故障排查 | 检查日志与 DNS，必要时用 SSH | 状态面板和文档结合真实邮件头 |
| 100 域名成本 | 服务器与运维时间 | 历史例子每月 $8，需核查当前条件 |
结论
适当的DKIM 记录是 2025 年及以后稳健邮件配置的重要部分，适用发件人也必须满足相关规则。但缺少 DKIM 不等于每封都 DMARC 失败，或每次转发必然丢失信誉。应检查适用规则及所有有效对齐验证途径。
先配置支持情况下适当的 2048 位 RSA 密钥、正确选择器、完整 TXT 与可见 From 对齐。再安排受控轮换、适当 DMARC 政策及Google Postmaster Tools可用监控数据；数据可能不完整或延迟。
SPF、DKIM 与 DMARC 对比说明彼此关系和准备顺序。有送达故障时，避免邮件进入垃圾箱指南提供起点，应按已确认原因调整顺序。
多域名手动管理会增加工作和错误风险。名称、截断或轮换问题可能影响对应发送流，CNAME 可减少本地任务，却不消除整个故障类别。查看套餐或了解免费产品：10 个域名、不需信用卡是原文条件，实际使用前应确认现行规则。
