AWS SES发往自有域名邮件遭拦截（550反伪造策略拒绝）

针对你遇到的发往<my_domain>.com域名的邮件被反伪造策略拦截（错误码smtp; 550 Rejected by header based Anti-Spoofing policy）的问题，以下是具体排查和解决步骤：

1. 排查自有域名的邮件接收端反伪造规则 #

问题核心大概率是你域名托管的邮件服务（比如AWS Workmail、Google Workspace等）的反垃圾/反伪造策略在生效。这些服务默认会严格校验发件人域名的真实性，当SES发送的邮件头部发件人（noreply@<my_domain>.com）与实际MAIL FROM域名不匹配，或未通过SPF/DKIM验证时，就会触发拦截。

• 登录你域名的邮件服务控制台，找到反垃圾邮件/反伪造策略设置：
  • 若使用AWS Workmail，进入对应组织的「邮件流规则」，添加允许规则：匹配发件人域名<my_domain>.com且SPF验证通过的邮件，跳过反伪造检查。
  • 若使用第三方邮件托管商，查看是否有针对自有域名发件人的严格拦截规则，调整为允许经过SPF/DKIM验证的邮件。

2. 补全自定义MAIL FROM的DKIM配置 #

你已设置自定义MAIL FROM子域名notifications.<my_domain>.com，但可能遗漏了DKIM签名配置——这是反伪造验证的关键环节：

• 进入AWS SES控制台，找到你的域名Identity，切换到「MAIL FROM Domain」标签页，复制系统生成的两条DKIM CNAME记录（格式类似s1._domainkey.<my_domain>.com指向xxxx.amazonses.com）。
• 登录Route53，找到你的域名托管区，添加这两条CNAME记录，TTL保持默认值即可。
• 等待DNS生效后，用dig命令或DNS查询工具验证记录是否生效。

3. 修正SPF记录覆盖自定义MAIL FROM #

你的SPF记录需要同时覆盖主域名发件和自定义MAIL FROM域名：

• 若主域名原SPF为v=spf1 include:amazonses.com -all，修改为：

  v=spf1 include:amazonses.com include:notifications.<my_domain>.com -all
  

• 或者给自定义MAIL FROM子域名单独配置SPF记录：在Route53添加一条TXT记录，主机记录为notifications，内容为v=spf1 include:amazonses.com -all。

4. 用VDM和邮件日志定位具体拦截点 #

• 打开Virtual Deliverability Manager的详细诊断报告，确认拦截发生在SES端还是收件端邮件服务：
  • 若为SES端拦截，检查域名Identity的验证状态，确保noreply@<my_domain>.com和自定义MAIL FROM域名都已完成验证。
  • 若为收件端拦截，查看邮件服务的日志（比如Workmail的邮件跟踪功能、第三方托管商的投递日志），获取更具体的拒绝原因，针对性调整规则。

5. 验证SPF/DKIM有效性 #

• 用MXToolbox、Mail-Tester等工具，分别测试noreply@<my_domain>.com和notifications.<my_domain>.com的SPF、DKIM验证状态，确保两项都显示「Pass」。
• 发送测试邮件到自己域名的邮箱，同时抄送一个第三方测试邮箱，对比两者的投递结果，确认是否只有自有域名的邮件被拦截。

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