排查AWS SES DKIM配置中的CNAME记录问题

我处理过不少类似的SES DKIM验证卡壳的问题，给你梳理几个最常见的排查方向和解决办法，按步骤来应该能搞定：

1. 先揪最容易犯的低级错误：CNAME记录复制/配置错误 #

• 逐字核对SES控制台生成的3条CNAME记录的主机名和值，别小看复制粘贴，多一个空格、少一个字符、甚至把主机名和值搞反的情况太常见了。尤其是DKIM的标识符都是长串随机字符，很容易手滑。
• 注意DNS服务商的自动补全：有些DNS平台会自动在你输入的主机名后面追加你的域名后缀。比如SES给的主机名是abc123._domainkey.yourdomain.com，你在DNS里只需要输入abc123._domainkey就行，要是全输进去，最后会变成abc123._domainkey.yourdomain.com.yourdomain.com，这种无效记录肯定过不了验证。

2. 确认DNS记录已经全网生效 #

• 别光等SES的提示，自己手动验证DNS记录是否能被解析。用终端的dig或者nslookup命令查每条CNAME：

  dig abc123._domainkey.yourdomain.com CNAME
  

  看看返回的结果是不是和SES提供的CNAME值完全一致。如果本地能查到但SES还是没验证，可能是DNS传播延迟，这时候可以查不同地区的DNS服务器，确认记录已经全球同步。
• 检查TTL设置：如果之前设的是长TTL（比如默认的86400秒=24小时），那旧记录的缓存时间会很长，建议改成短TTL（比如300秒）后再重新添加记录，加快生效速度。

3. 确保你在正确的DNS服务商操作 #

• 很多人同时用多个DNS平台（比如域名注册商的DNS、Cloudflare、Route 53等），但只有域名NS记录指向的权威DNS服务器上的配置才会生效。先查一下你的域名当前的权威DNS：

  dig yourdomain.com NS
  

  确认你添加CNAME记录的服务商就是这些NS对应的平台，别在没用的DNS服务商上瞎忙活。

4. 排查DNSSEC或特殊DNS功能的干扰 #

• 如果你的域名开启了DNSSEC，要确保CNAME记录的签名配置正确，否则SES验证时会因为签名不通过而失败。可以暂时关闭DNSSEC（如果业务允许），等DKIM验证通过后再重新开启。
• 像Cloudflare这类CDN服务商的特殊功能（比如CNAME Flattening、Proxy模式）可能会干扰DKIM记录的解析。可以把DKIM对应的CNAME记录改成DNS Only模式，关闭代理，等验证通过后再调整回去。

5. 重置DKIM配置试试 #

• 有时候SES控制台的缓存或者生成的DKIM记录可能有异常，你可以在SES控制台删除当前的DKIM配置，重新生成新的3条CNAME记录，再重新添加到DNS里。这种重置操作经常能解决一些莫名其妙的验证失败问题。

如果上面的步骤都试过还是不行，可以再检查一下域名是否有特殊的DNS限制（比如SPF记录冲突、子域名的DNS继承问题），但大部分情况下，前面的几点就能找到问题所在。

内容的提问来源于stack exchange，提问作者smeeb