DKIM fail 表示签名验证未通过，并不是对邮件可信度的最终判定。它可能影响接收与筛选，但不能单独决定是否投递。如果还在完善 SPF、DKIM、DMARC、路由和邮箱配置，可以先阅读我们的企业邮箱指南。
邮件在发送端看起来很正常，但 Gmail、Microsoft 或 Yahoo 显示 dkim=fail。根据其他认证结果和接收方策略，可能出现垃圾邮件分类、临时限制或拒收。问题可能来自 DNS、发送系统，也可能是签名后修改邮件的安全网关。
应按技术故障处理，而不是猜测：阅读认证结果，区分错误类型，检查选择器和密钥，再调查签名后经过的处理环节。确认原因后，修复具体故障点。
dkim fail 到底是什么意思？
DKIM fail 表示接收服务器未能成功验证邮件的加密签名。原因可能是正文或已签名邮件头被修改、密钥不匹配，或其他处理问题。公钥缺失和 DNS 查询故障可能产生单独的永久或临时错误，不能全部混为同一种失败。
RFC 6376 定义了 bh= 中的正文哈希和 b= 中的邮件头签名等内容。验证失败不一定意味着伪造，也可能是过早签名、发布了不匹配的密钥，或后续节点修改了邮件。
可以把 DKIM 想成包裹的封签。封签与收到的包裹不符，说明检查未通过，但还需要调查原因，不能据此作出完整的信任判断。
先查看问题邮件的 Authentication-Results 邮件头，了解准确结果及可能的错误说明。下例展示诊断字段，但并不是一致的常规情形：同一对齐域名的 SPF 已通过时，通常也会使 DMARC 通过。
Authentication-Results: mx.google.com;
dkim=fail (body hash did not verify) header.i=@example.com header.s=tm1;
spf=pass smtp.mailfrom=example.com;
dmarc=fail header.from=example.com如果要先检查域名记录，可以对照 TrekMail 的必需 DNS 记录。
四类常见 DKIM 问题
初步排查可分为四类：正文哈希不匹配、选择器或密钥问题、DNS 公钥格式错误，以及转发或中继修改。先判断类型，有助于避免无意义的密钥轮换。
| 认证结果 | 可能含义 | 先检查哪里 |
|---|---|---|
dkim=fail (body hash did not verify) | 已签名正文部分在规范化后不一致 | 外发中继、免责声明、链接改写、规范化 |
dkim=fail (signature did not verify) | 密钥不匹配或已签名邮件头被修改 | 选择器、近期轮换、发送平台、邮件头处理 |
dkim=permerror (no key for signature) | 未找到可用公钥 | 选择器主机名、DNS 可查询性、记录格式 |
dkim=temperror | 临时 DNS 查询问题 | 权威 DNS、TTL、域名服务器可用性 |
表格用于缩小范围，具体原因仍需进一步验证。
错误类型 1：正文哈希不匹配
这表示收到的已签名正文部分经过规范化后，计算出的哈希与签名中的值不一致。判断标准不是原始正文逐字节相等，也不能由此推断 DNS 已正确配置。
RFC 6376 规定，重新计算的正文哈希与 bh= 不符时，验证失败。常见原因是签名后发生变化，也要检查邮件处理过程。
常见原因包括：
- Microsoft 365、Exchange 或安全网关在签名后添加法律声明。
- Mimecast、Barracuda、Proofpoint 等过滤服务改写链接。
- 中继修改空白或换行，超出规范化规则能够容忍的范围。
- 应用先签名，后续网关才修改 MIME 边界或添加
[External]标记。
检查 c=。c=simple/simple 使用较严格的处理方式。RFC 6376 的宽松正文规范化会忽略行尾空白，并合并行内连续空白，可以容忍部分格式变化，但不能修复实质性内容修改。
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=example.com; s=tm1; h=from:to:subject:date:mime-version;
bh=...; b=...也要调整签名位置：尽量在所有内容修改完成后，在自己能控制的最后一个发送节点签名。这可以减少内部处理造成的失败，但不能保证外部系统不再修改邮件。
涉及转发时，可参考邮件转发配置和把域名邮件转发到 Gmail。直接测试成功，并不代表真实转发路径也能保持认证结果。
错误类型 2：选择器或密钥不匹配
邮件使用选择器 X 签名，但对应 DNS 名称下没有可用公钥，或公钥与签名私钥不匹配。缺少公钥可能产生永久错误，密钥不匹配则可能导致签名验证失败。
从签名邮件头读取域名和选择器：
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=k1; ...然后查询这个准确的选择器：
dig txt k1._domainkey.example.com +short空响应可能来自记录缺失、主机名错误、缓存影响或查询故障。如果有响应，应把完整公钥与当前发送系统配置对照。迁移或多平台发送时，某个平台可能还在使用旧密钥对。
例如，应用通过 SES 发送，客服通过 Microsoft 365，营销邮件通过另一个 ESP。共享选择器更新后，其他平台若继续用旧私钥签名，就会让部分邮件出现间歇性失败。
使用 TrekMail 托管发送时，查看托管 TrekMail SMTP并确认实际发送路径中的签名。Nano 或自有发送服务可参考自备 SMTP（BYO）：此时 TrekMail 是 SMTP 客户端，应在实际发送系统配置签名。
错误类型 3：长公钥的 DNS 发布问题
公钥发布错误可能让验证无法通过，例如 DNS 面板未正确保存 2048 位密钥。结果可能是 permerror、格式错误，或查询只显示部分公钥。
RFC 8301 要求 RSA 密钥至少为 1024 位，并建议至少为 2048 位。不应仅因为面板输入问题就放弃推荐长度，而应先核对 DNS 面板的规则。
值可能被截断，或引号处理不正确。即使发送端私钥正确，也无法解决这类公钥发布问题。以下仅展示格式，并不是完整可用的密钥：
; Good DKIM TXT record pattern
k1._domainkey.example.com IN TXT (
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQE..."
"restOfThePublicKeyContinuesHere..."
)查询时检查同一条 TXT 记录的所有字符串，而不只是首段：
dig txt k1._domainkey.example.com +short更换 DNS 服务商、迁移区域或手动复制记录后，尤其应完整对照这些值。
错误类型 4：转发、中继与域名对齐
转发可能影响 SPF，如果中间系统还修改已签名数据，DKIM 也可能失败。只有没有其他成功且对齐的认证路径时，DMARC 才会失败；最终接收决定还取决于收件方。
例如，你从 example.com 发给大学用户，再由大学转发到 Gmail。SPF 可能因转发服务器而失败。只要已签名数据在规范化规则下保持不变，DKIM 就可能保留。添加页脚、改写链接或修改已签名主题可能破坏 DKIM。若没有其他成功且对齐的验证，DMARC 就无法通过。
Google 对直接发送到个人 Gmail 的普通发件人要求 SPF 或 DKIM；批量发件人则需要 SPF 和 DKIM，以及通过至少一个成功路径实现对齐的 DMARC。转发和邮件列表还涉及 ARC。ARC 可以传递原始认证信息，但是否采信由接收方决定。
SRS 和合理的路由策略也很重要。SRS 可以帮助改写后的信封发件人地址通过 SPF，但不能恢复与原始 From 的 SPF 对齐。应核实 TrekMail 的 SRS 支持和具体转发配置；SRS 不能替代 DKIM 或 DMARC 对齐。
别名较多时，可以阅读邮件别名转发及创建自有域名邮箱。看似神秘的 DKIM 错误有时来自转发路径，而不是别名名称本身。
出现 dkim fail 时的检查顺序
先看认证结果，再检查选择器和 DNS，之后检查签名路径及对齐。这样可以避免在真正原因是网关修改邮件时，反复调整 DNS。
- 打开原始邮件，找到
Authentication-Results，记录准确的 DKIM 结果。 - 读取
d=、s=和c=，这些标签位于DKIM-Signature邮件头。 - 使用
dig查询选择器，核对主机名selector._domainkey.example.com。 - 确认实际签名平台，多发送系统可能使用不同配置。
- 检查网关、过滤器或转发服务是否在签名后修改正文或已签名邮件头。
- 检查对齐：
d=域名需与可见From:域名对齐，DKIM 才能满足 DMARC。
把片段粘贴到第三方检查工具可能改变格式，制造假的正文哈希错误。应检查完整原始邮件，或导出的 .eml 文件。
统一 TrekMail 发送路径如何帮助排错
分散修改 DNS、中继和页脚，会让签名来源更难追踪。把签名放在内部修改之后，保持 DNS 可验证，并明确区分托管发送与自备发送，有助于控制配置。
| 容易出问题的方式 | 可控方式 |
|---|---|
| 内部节点在签名后修改邮件 | 在最后一个可控发送节点、所有修改之后签名 |
| 多个工具分别手动轮换密钥 | 按托管 SMTP 服务的流程管理签名和密钥 |
| 随意修改 DNS，出现重复 SPF 或错误 DKIM 名称 | 采用一致流程并逐项验证记录 |
| 转发未考虑 SRS 或 ARC | 尽量保留认证信息，并考虑接收方判断 |
TrekMail 将 Nano 作为使用自备 SMTP 的免费套餐提供。付费套餐参考价为每月 $3.50 起，并提供托管 SMTP。应按所需的密钥管理方式选择实际发送服务。使用 SES、SendGrid 或 Mailgun 时，在对应服务排查 DKIM。付费套餐可能提供 14 天试用并要求信用卡。最新价格、功能和条件见TrekMail 套餐价格。
使用自备 SMTP 时，要检查完整外发路径。选择器、密钥和签名后修改是优先检查项，但仅凭一个 DKIM 结果不能排除其他问题。
dkim fail 故障的最终检查清单
把 DKIM fail 当作具体验证结果处理。阅读细节，检查选择器与签名路径，有充分依据后再修改配置。
调整生产环境前，请检查：
- 阅读完整认证邮件头，不只看退信摘要。
- 区分正文哈希错误、签名错误、permerror 和 temperror。
- 查询准确的 DNS 选择器。
- 确认公钥完整，TXT 字符串格式正确。
- 如果内部环节修改邮件，把签名移到这些修改之后。
- 评估
c=relaxed/relaxed是否适用，不要指望它容忍实质性内容变化。 - 检查
d=与可见From:域名的 DMARC 对齐。
如果错误持续，继续针对签名系统、选择器和修改邮件的中继排查。临时 DNS 故障可以重试验证，永久配置错误则需要相应修复。
