この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

SESでメール送信の仕組みを組んでいると、バウンスや苦情（Complaint）が発生したときの通知フローもちゃんとテストしたくなる。ただ本番同然に実在アドレスへバウンスを発生させると、自分のSES送信品質（バウンス率・苦情率）に直接ダメージが入る。それを避けるための仕組みがメールボックスシミュレーターだった。

何ができるか

SESが用意している専用ドメイン simulator.amazonses.com 宛にメールを送ると、宛先ごとに決まったレスポンスが返ってくる。

• success@simulator.amazonses.com → 正常配信扱い
• bounce@simulator.amazonses.com → SMTP 550（Unknown User）でハードバウンスとして拒否される。バウンス通知はメールまたはSNS経由で受け取れる
• complaint@simulator.amazonses.com → 受信者が「迷惑メールとして報告」した体でISPからSESに苦情が返る
• ooto@simulator.amazonses.com → 不在通知（Out of the Office）の自動応答をシミュレート
• サプレッションリスト登録済みアドレス宛のケースも別途用意されている

効くポイント

• これらのアドレス宛のメールは、SESのバウンス率・苦情率の計算にはカウントされない
• 送信クォータ（24時間あたりの送信可能数）にもカウントされない
• サンドボックス環境でも使える。通常サンドボックスは宛先アドレスの事前検証が必要だが、シミュレーター宛はその検証なしで送れる
• 送信レート制限（1秒あたりの送信数上限）自体は普通にかかる

つまり「実際のメール配信基盤には手を出さずに、自分の受信側（バウンス処理、苦情処理のロジック）だけを検証したい」という用途にちょうどいい。

使い方

普段どおりSESのAPI・CLI・SMTPインターフェース・コンソールのいずれかから、宛先を上記アドレスに向けて送るだけ。設定は不要。

ラベル付きアドレス（bounce+label1@simulator.amazonses.com のような形式）も使えるので、VERP（Variable Envelope Return Path）的にどのメールがどのバウンスに対応するかを追跡するテストにも使える。

結論

自分の環境（受託開発案件で新規にメール通知を組む場面）では、まずこのシミュレーターでバウンス・苦情それぞれの通知（SNS経由）がLambda側で正しくハンドリングされるかを確認してから、実アドレスでの検証に進むのが安全そうだった。