Amazon SES自定义MAIL FROM域名DNS记录莫名失效问题求助

以下是针对该问题的常见排查方向和解决办法：

1. 排查DNS解析的区域性差异 #

AWS SES的验证服务器会使用全球范围内的DNS节点进行查询，而你本地使用的递归DNS可能存在缓存或者区域同步延迟问题。

• 直接模拟AWS的解析请求，使用公共DNS服务器（如8.8.8.8）查询：

  dig MX subdomain.domain.com @8.8.8.8 +short
  dig TXT subdomain.domain.com @8.8.8.8 +short
  

• 检查DNS记录的TTL设置，建议将TTL调整为300秒（5分钟），确保全球DNS节点能快速同步记录。

2. 确认MAIL FROM域名的MX记录唯一性 #

SES要求自定义MAIL FROM域名的MX记录只能包含指向SES的条目，不能有其他MX记录共存（哪怕优先级更高）。

• 执行完整MX记录查询，检查是否有冗余条目：

  dig MX subdomain.domain.com +noall +answer
  

• 如果存在其他MX记录，立即删除，只保留feedback-smtp.<你的SES区域>.amazonses.com这一条。

3. 排除CDN/域名代理的干扰 #

如果你的域名使用了Cloudflare等CDN或域名代理服务，开启代理模式可能会导致SES无法直接获取真实的DNS记录。

• 将MAIL FROM子域名的DNS记录设置为仅DNS模式（如Cloudflare的灰色云朵状态），关闭代理功能。
• 检查域名的DNSSEC配置，如果配置错误，可能导致部分DNS节点解析失败，建议暂时关闭DNSSEC后观察问题是否复现。

4. 排查DNS服务商的间歇性故障 #

SES会定期重验MAIL FROM域名的DNS记录，可能你的DNS服务商在特定时段出现短暂解析故障，刚好被SES的重验触发。

• 开启SES的CloudWatch日志，定位验证失败的具体时间点，然后核对DNS服务商的状态日志，确认该时段是否有服务波动。
• 尝试将MAIL FROM域名的DNS托管到AWS Route 53，利用AWS内部解析的兼容性，排除第三方DNS的潜在问题。

5. 简化SPF记录避免解析异常 #

如果SPF记录包含过多的include条目或复杂规则，可能导致SES验证时解析超时或判定无效。

• 简化SPF记录为仅包含SES的必要规则，例如：

  v=spf1 include:amazonses.com -all
  

• 使用本地工具（如spfquery）验证SPF记录的有效性，确保没有语法错误或递归查询问题。

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