AWS SES未接收Gmail用户投诉事件问题排查求助

针对你描述的情况——旧配置原本能正常接收Gmail投诉，开启「Include original email headers」后失效；新配置（配置集方案）同样无法接收Gmail投诉，但Yahoo/Outlook正常——可以从以下几个方向排查：

一、旧配置核心排查点（开启原始邮件头后失效） #

• 检查消息大小限制：开启原始邮件头后，SES发送给SNS的投诉通知payload会显著增大。SNS Topic默认消息大小上限是256KB，如果Gmail投诉附带的原始邮件头超过这个阈值，消息会被直接丢弃。可以查看SNS的CloudWatch指标NumberOfMessagesFailed是否有增长，或者临时关闭该选项测试Gmail投诉是否恢复。
• 验证SNS到SQS的订阅过滤策略：如果SNS Topic的订阅设置了过滤规则，可能误过滤了包含原始邮件头的Gmail投诉消息。检查订阅的过滤策略，确保没有针对邮件头内容的不合理限制。
• 检查SQS的死信队列与权限：
  • 若SQS配置了死信队列，查看是否有被拒收的Gmail投诉消息；
  • 确认SQS的访问策略允许对应的SNS Topic向其发送消息（订阅创建时会自动生成权限，但手动修改后可能丢失，需验证策略中包含SNS服务主体及目标Topic ARN的权限）。
• 确认SES身份的反馈配置未变更：开启原始邮件头后，检查SES身份（域名/邮箱）的投诉反馈目标是否仍指向原SNS Topic，避免修改配置时误切换了目标。

二、新配置（配置集方案）补充排查点 #

• 验证配置集头部正确性：发送邮件时的X-SES-CONFIGURATION-SET头部必须与AWS控制台中配置集的名称完全一致（区分大小写），拼写错误会导致事件无法关联到配置集。
• 检查配置集事件目标设置：确认配置集的事件目标已勾选「投诉」事件类型，未勾选则不会触发该类事件的通知。
• 查看SES与SNS的日志指标：通过CloudWatch日志查看SES是否捕获到Gmail的投诉事件，以及是否成功将事件发送到SNS Topic；同时检查SNS的NumberOfNotificationsDelivered指标，确认消息是否正常流转。

三、通用验证步骤 #

• 查看SES反馈统计：在SES控制台的「反馈」页面查看投诉统计，确认Gmail的投诉事件是否被SES正常接收（如果统计里没有Gmail投诉数据，可能是SES未捕获到，需检查域名的DKIM/SPF配置是否符合Gmail要求）。
• 测试Gmail投诉的具体流程：用Gmail邮箱发送测试投诉，然后依次检查：SES是否生成投诉事件→SNS是否收到并转发→SQS/HTTPS端点是否接收成功，逐步定位故障节点。

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