セルフホスト環境（v2026.7.3、release/2026.7、us-east-1のSES SMTP、組み込みPostgreSQL 18）で再現しました。
設定
aws_sns_topic_arn_allowlistには正確なトピックARNが含まれています（SNSコンソールで確認済み）。/webhooks/awsへのSNS HTTPSサブスクリプションは確認済みです。同じサブスクリプションは、release/2026.4および2026.5.0で2026年3月から6月にかけてバウンスを正しく処理していました。
観察結果
bounce@simulator.amazonses.com 宛てにテストメッセージを2通送信しました。それぞれがコンテナに到達する1つの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 がキューに登録されたことを示しています。その後、ジョブは mail.messageId（SESによって割り当てられたもの）が EmailLog.message_id（Discourse自身の Message-ID、Email::Sender 内で email_log.message_id = @message.message_id として設定される）と一致しないため、next if email_log.nil? で終了します。
Git履歴は上記の分析と一致しています：#7284（2019年）はまさにこの理由でIDの一致チェックを削除し、61f12e1（2026年6月）はSESによって割り当てられたIDを使用してそれを再導入しました。release/2026.7では、そのコミット以降ジョブに変更はありません。
現在のESRでSESをセルフホストしている場合の実際の影響は、バウンス処理がサイレントに無効化され、新しいダッシュボードの通知が管理者を何も機能しない設定に誘導してしまうことです。修正が反映された時点で、release/2026.7へのバックポートが望まれます。