📌 TL;DR

• バウンスにはハードバウンス（永続的）とソフトバウンス（一時的）の2種類がある
• ReturnPath を専用アドレスに設定するだけで、不要なNDR転送を止められる
• ハードバウンスはSESが自動でサプレッションリストに登録するが、ソフトバウンスは自前のDB管理が必要
• SNS + Lambda + DBの構成でソフトバウンスを自動処理できる
• バウンス率が悪化するとAWSアカウントが停止されるリスクがある
• SESのバウンス率が低くても転送メールが多い場合、原因は受信側サーバーのリトライ失敗にある

Part 1｜概念解説

1. メール配信の基本フロー

メール送信には複数のサーバーが連携しています。

あなたのアプリ
    │
    │ boto3 / SMTP
    ▼
Amazon SES
    │
    │ SMTP
    ▼
受信側MTAサーバー（Gmailなど）
    │
    ▼
受信者のメールボックス

主な用語

実例

封筒で例えると：
　From        = 手紙の中に書く「差出人」（受信者が見る）
　Return-Path = 封筒の裏に書く「返送先住所」（郵便局＝MTAだけが使う）

💡 ポイント: FromとReturn-Pathは別物。Return-Pathを指定しないと、SESはFromアドレスをReturn-Pathとして扱い、NDRが意図しない宛先に届く。

2. バウンスとは何か

バウンス（Bounce） = メールが受信側に届かず、送信側に返ってくること。

送信したメール
    │
    ▼
受信側MTAが判定
    │
    ├─ 永続的に届かない ──→ ハードバウンス（Permanent）
    │
    └─ 一時的に届かない ──→ ソフトバウンス（Transient）

ハードバウンス vs ソフトバウンス

💡 ポイント: ソフトバウンスはSESが自動対処しないため、放置するとバウンス率が静かに上昇し続ける。

3. NDRとReturn-Path

NDR（Non-Delivery Report） = メールが届かなかったときに、送信側へ自動返送される配達失敗通知のこと。基本的に1バウンス = 1NDRですが、中継サーバーが複数ある場合や転送設定によってずれることがあります。

Return-Pathを指定しなかった場合

あなたのアプリ
    │  From: noreply@example.com
    │  Return-Path: （未指定 → Fromと同じになる）
    ▼
受信側MTA
    │
    │  届かなかった場合
    ▼
From（noreply@example.com）へ NDRを返送
    │
    ▼
意図しない宛先にNDRが届く ⚠️

Return-Pathを指定した場合

client.send_email(
    Source='noreply@example.com',         # Fromアドレス（人間向け）
    ReturnPath='bounce@example.com',      # バウンス専用の受信口（サーバー向け）
    Destination={'ToAddresses': [to]},
    Message={...}
)

💡 ポイント: ReturnPath を専用アドレスに設定するだけで、不要なNDR転送を止められる。最優先で対処すべき設定。

4. SESのフィードバック機能

SESはメール送信後の結果を3種類の通知として受け取れます。

通知の流れ

Amazon SES
    │
    │ 通知を発火
    ▼
Amazon SNS（通知の中継役）
    │
    ├──→ Lambda（自動処理）
    ├──→ SQS（キューに溜める）
    └──→ メール（人間が確認）

SNSを挟むことで通知の受け取り方を柔軟に変えられ、将来的に通知先を追加・変更する際もSNS側の設定変更だけで対応できます。

💡 ポイント: 大量バウンスが同時発生する場合はSQSを挟んでまとめて処理する構成が有効。小規模であればSNS → Lambda直結でも十分。

5. サプレッションリスト

サプレッションリスト = 「このアドレスには送らない」とSESが記録しているブロックリストのこと。

自動登録の仕組み

ハードバウンス発生
    │
    ▼
SESが自動でサプレッションリストに追加
    │
    ▼
次回以降、そのアドレスへの送信をSESがブロック
    │
    ▼
バウンスとしてカウントされない ✅

ソフトバウンスは自動登録されないため、自前のDBで管理する必要があります。

💡 ポイント: SESのサプレッションリスト（ハードバウンス）＋自前DB（ソフトバウンス）の二段構えが基本構成。

6. 送信レピュテーション管理

送信レピュテーション = SESにおける「信頼スコア」のようなもの。バウンス率・苦情率をAWSが監視していて、悪化するとアカウントが制限されます。

監視される主な指標

段階的なペナルティ

レピュテーション悪化
    │
    ▼
① AWSからの警告メール
    │
    ▼
② 送信一時停止（Probation）
    │
    ▼
③ アカウント停止 ← 最悪のケース

💡 ポイント: 一度停止されると復旧にAWSへの申請が必要で時間がかかる。バウンス率は日頃から監視しておくことが重要。

7. バウンス率の確認方法

CloudWatchでアラートを設定する

CloudWatch
    │
    ├─ メトリクス監視
    │   ├─ Reputation.BounceRate
    │   └─ Reputation.ComplaintRate
    │
    ▼
アラート発火
    │
    ▼
SNS → メール通知 / Slack通知

💡 ポイント: バウンス率はパーセンテージではなく小数で表示される（例: 0.001 = 0.1%）。SESコンソールで現在値、CloudWatchで時系列の推移を確認するのがベストプラクティス。

Part 2｜問題対応

8. SNS + Lambda によるバウンス自動処理

ソフトバウンスをDBで自動管理するための実装パターンです。

全体構成

SES
 │ バウンス発生
 ▼
SNS トピック
 │ 通知を中継
 ▼
Lambda
 │ バウンス種別を判定
 ├─ ハードバウンス → DBを即座に無効化
 └─ ソフトバウンス → DBのバウンス履歴を更新
 ▼
RDS / PostgreSQL
 │ is_activeを管理
 ▼
次回送信時にフィルタリング

Lambdaの実装例

def lambda_handler(event, context):
    message = json.loads(event['Records'][0]['Sns']['Message'])
    bounce_type = message['bounce']['bounceType']
    email = message['bounce']['bouncedRecipients'][0]['emailAddress']

    if bounce_type == 'Permanent':
        # ハードバウンス → 即無効化
        db.execute("UPDATE users SET is_active = FALSE WHERE email = %s", [email])
    else:
        # ソフトバウンス → バウンス回数を記録
        db.execute("UPDATE users SET bounce_count = bounce_count + 1 WHERE email = %s", [email])

送信前フィルタリング

送信リスト取得
    │
    ▼
DBで is_active = TRUE のみに絞り込み
    │
    ▼
SESで送信

LambdaをRDSに接続するためのインフラ設定

【必要な設定】

1. VPC設定
   └ LambdaをRDSと同じVPCに配置

2. サブネット設定
   └ プライベートサブネットに配置
     （RDSはインターネットから直接アクセスさせない）

3. セキュリティグループ設定
   └ RDSのSG：LambdaのSGからのインバウンドを許可
   └ LambdaのSG：RDSへのアウトバウンドを許可

💡 ポイント: LambdaはVPC外のサービス（SNSなど）にアクセスするためにNATゲートウェイまたはVPCエンドポイントも必要になる場合がある。

9. 送信失敗メール転送問題

システム構成

ユーザー
    ↓ 問い合わせメール送信
問い合わせ窓口メアド
    ↓ 社内転送設定
開発者メアド
    ↓ AWS SESで返信送信
ユーザー

問題の概要

SESで送信したメールの一部が受信側メールサーバーで最終的に配信できず、NDR（配信不能レポート） が問い合わせ窓口メアドに返送されます。その結果、社内の転送設定によって開発者メアドに大量転送されています。

なぜSESのバウンス率が低いのに転送メールが多いのか

これはSESと受信側サーバーの認識の違いによるものです。

SESが送信
    ↓
SESは送信完了としてカウント（バウンスとして認識しない）
    ↓
受信側サーバーが一時的に受信できない
    ↓
受信側サーバーが数時間〜数日リトライを繰り返す
    ↓
最終的に諦めてNDRを問い合わせ窓口メアドに返送
    ↓
社内転送設定により開発者メアドに転送される

SESで対処できない理由

• SESはこのバウンスを認識していない
• SESが認識していないためSNS通知も発生しない
• つまりアプリケーション側・SES側での対処は不可能

解決策

Exchange管理者へ以下を依頼する。

問い合わせ窓口メアドへの転送ルールに、NDR・配信不能メールを転送しない条件を追加してほしい

Exchangeのトランスポートルールで以下の条件のメールを転送対象から除外します。

結論

💡 ポイント: SESのバウンス率が低くても転送メールが多い場合、原因はSES側ではなく受信側サーバーのリトライ失敗にある。この問題はSES・アプリケーション側では解決できず、Exchangeのフィルター設定が唯一の対処法。

❌ やりがちなミス

📝 自分のメモ・気づき

• SESのバウンス率は小数表記なのでパーセントに変換して読む必要がある
• NDRとバウンスは基本1対1だが、中継サーバーや転送設定でずれることがある
• SNSを挟む理由は「今」ではなく「将来の拡張性」のため。小規模ならLambda直結でも十分
• ソフトバウンスは自動対策がないため、放置するとじわじわバウンス率を押し上げる
• ReturnPathの設定は最も優先度が高く、難易度も低い。最初に対処すべき
• SESのバウンス率が正常でも転送メール問題が起きる。SES外の問題はExchange側で対処する

参考リンク

• Amazon SES 公式ドキュメント
• SES バウンス管理
• CloudWatch でSESメトリクスを監視する