在自托管环境中复现了该问题，运行版本为 v2026.7.3（release/2026.7），SES SMTP 位于 us-east-1，使用嵌入式 PostgreSQL 18。
配置详情
aws_sns_topic_arn_allowlist包含准确的 Topic ARN（已与 SNS 控制台核对）。- 已确认 SNS HTTPS 订阅指向
/webhooks/aws；同一订阅在 2026 年 3 月至 6 月期间，在 release/2026.4 和 2026.5.0 版本上均能正确处理退信（bounces）。
观察结果
向 bounce@simulator.amazonses.com 发送了两条测试消息。每条消息都生成了一次到达容器的 SNS POST 请求：
"POST /webhooks/aws HTTP/1.1" "Amazon Simple Notification Service Agent" 200 402
/logs 中没有任何记录，/admin/email-logs/bounced 下也没有内容。由于 WebhooksController#aws 在白名单或签名验证失败时会返回 406，因此返回 200 表明这两项检查均已通过，且 Jobs::ProcessSnsNotification 已被入队；随后该任务在 next if email_log.nil? 处退出，因为 mail.messageId（由 SES 分配）从未等于 EmailLog.message_id（Discourse 自身的 Message-ID，在 Email::Sender 中通过 email_log.message_id = @message.message_id 设置）。
Git 历史记录也印证了上述分析：#7284（2019 年）正是出于此原因移除了 ID 匹配逻辑，而 61f12e1（2026 年 6 月）又使用 SES 分配的 ID 重新引入了该逻辑。在 release/2026.7 中，自该提交以来任务代码未再变更。
对于当前 ESR 版本上的 SES 自托管用户而言，其净效应是：退信处理被静默禁用，而新的仪表板提示反而将管理员引导至一个最终毫无作用的配置。一旦修复方案落地，欢迎将其回移（backport）至 release/2026.7。