AWS SES サンドボックスモードとは？本番環境への移行申請手順を完全解説

6月 17, 2026

SESでテストメールは自分宛に届くのに、実際のユーザーへ送信すると失敗する。このAWS SESサンドボックスの制約は、初めてSESを本番利用しようとしたエンジニアが必ず一度は踏む落とし穴だ。なぜ制限されているのか、どう解除するのかを実際の申請フローとともに整理する。

TL;DR：SES サンドボックスモードの要点

項目	サンドボックス	本番環境
送信先	検証済みメールアドレス・ドメインのみ	任意のアドレスへ送信可能
送信レート上限	1秒あたり1通（デフォルト）	申請した上限値
1日の送信上限	200通（デフォルト）	申請した上限値
解除方法	AWSサポートへ本番アクセス申請	—
申請後の反映	通常24時間以内（SLAなし）	—

SES サンドボックスモードの仕組み

AWSはすべての新規SESアカウントをサンドボックス環境に配置する。これはメール配信インフラの悪用防止が目的で、スパム送信者がSESを踏み台にするリスクを下げるための設計だ。サンドボックス内では、送信先が『検証済みID（Verified Identity）』として登録されたメールアドレスまたはドメインに限定される。自分のアドレスを検証済みIDとして登録すれば自分宛には届く。しかし顧客のアドレスは当然登録されていないため、送信しようとするとエラーになる。

検証済みIDには2種類ある。メールアドレス単位の検証と、ドメイン単位の検証だ。ドメイン検証を通過すれば、そのドメイン配下のアドレス宛には送信できる。ただしこれはサンドボックス内での話であり、本番移行前に顧客ドメインをすべて検証するのは現実的ではない。

graph TD A["アプリケーション
送信リクエスト"] --> B["Amazon SES"] B --> C{"アカウントモード確認"} C -->|"サンドボックス"| D{"送信先は検証済みID?"} C -->|"本番環境"| G["送信処理へ"] D -->|"YES"| G D -->|"NO"| E["MessageRejected エラー"] G --> F["メール配信完了"]

送信リクエスト：アプリケーションがSES APIへ送信要求を発行する。
サンドボックス判定：SESがアカウントのモードを確認する。
検証済みID照合：サンドボックスの場合、送信先が検証済みIDリストに含まれるか検証する。
許可 or 拒否：未検証アドレス宛の場合、MessageRejectedエラーが返る。
本番環境：モードが本番に移行済みであれば、検証済みID照合をスキップして送信処理へ進む。

現在のサンドボックス状態を確認する

コンソールで確認するより先に、CLIで現在の送信制限を確認しておく。ここでMaxSendRateやMax24HourSendが小さい値であれば、まだサンドボックス内にいる可能性が高い。ただし数値だけでは本番移行済みかどうかを断定できないため、後述のサポートケース確認と合わせて判断する。

aws ses get-send-quota \
  --region us-east-1

レスポンス例：

{
    "Max24HourSend": 200.0,
    "MaxSendRate": 1.0,
    "SentLast24Hours": 3.0
}

Max24HourSendが200、MaxSendRateが1.0であれば、デフォルトのサンドボックス制限値のままだ。本番移行後はこれらの値が申請した上限値に更新される。

検証済みIDの一覧も確認しておく。サンドボックス内でどのアドレス・ドメインに送信できるかを把握するためだ。

aws ses list-identities \
  --identity-type EmailAddress \
  --region us-east-1

aws ses list-identities \
  --identity-type Domain \
  --region us-east-1

SES 本番アクセス申請（サンドボックス解除）の手順

サンドボックスの解除はAWSサポートへのケース起票で行う。コンソールからSES専用の申請フォームが用意されており、汎用のサポートケースとは別フローになっている。申請内容が不十分だと却下または追加質問が来るため、最初から必要情報を揃えて記載する。

申請前に準備するもの

送信するメールの種類（トランザクションメール、マーケティングメール等）
想定する1日あたりの送信数と送信レート（通/秒）
バウンス・苦情（complaint）の処理方法（SNS通知 + 自動配信停止の仕組みなど）
オプトイン方法（ユーザーがどのように受信に同意したか）
送信元ドメインのDKIM・SPF設定状況

コンソールからの申請手順

AWSマネジメントコンソールで対象リージョンのSESを開く。
左メニューの『アカウントダッシュボード（Account dashboard）』を選択する。
『本番アクセスをリクエスト（Request production access）』ボタンをクリックする。
フォームにメールタイプ、想定送信量、バウンス処理方針を記入して送信する。

バウンス率と苦情率の管理方針を具体的に書かないと、AWSから追加質問が来て承認が遅れる。『SNSトピックでバウンス通知を受け取り、ハードバウンスは即時配信リストから除外する』といった具体的な運用フローを記載するのが実務上の定石だ。

CLI経由での申請（サポートケース起票）

コンソールUIが使えない環境や自動化パイプラインからの申請は、AWS Support APIを通じてケースを起票する。ただしサポートAPIはus-east-1エンドポイント固定であることに注意する。

🔽 CLIによるサポートケース起票コマンド（クリックして展開）

aws support create-case \
  --subject 'Request to move out of Amazon SES sandbox' \
  --service-code 'ses' \
  --severity-code 'normal' \
  --category-code 'quota-increase' \
  --communication-body 'We are requesting production access for Amazon SES in us-east-1.

Use case: Transactional emails (order confirmations, password resets) for registered users.
Expected daily volume: 5000 emails/day.
Expected send rate: 10 emails/second.

Bounce handling: We have configured SNS notifications for bounces and complaints.
Hard bounces are immediately removed from our sending list.
Complaint notifications trigger automatic unsubscribe.

Opt-in process: Users explicitly opt in during account registration.
We do not send to purchased lists.' \
  --region us-east-1

申請後の確認と送信制限の更新確認

申請が承認されると、AWSからサポートケースへ返信が届く。その後、get-send-quotaを再実行して制限値が更新されていることを確認する。承認通知が来てもすぐに反映されない場合は数分待ってから再確認する。

aws ses get-send-quota \
  --region us-east-1

本番移行後はMax24HourSendとMaxSendRateが申請値に更新されているはずだ。値が変わっていない場合はサポートケースのステータスを再確認する。

よくある誤診：『検証済みドメインがあるから本番に移行できているはず』

ドメイン検証（DKIM設定含む）とサンドボックス解除は完全に別の概念だ。ドメインをSESで検証済みにしても、アカウントがサンドボックスにある限り未検証アドレスへの送信は拒否される。

実際のインシデントパターンはこうだ。ステージング環境でドメイン検証を完了し、自ドメインのアドレス宛テストが全件成功した。本番リリース後、顧客のGmailやYahooアドレス宛に送信したところMessageRejectedが返り始めた。ログを見ると'Email address is not verified'というメッセージ。最初はDKIM設定の問題だと疑ったが、実際の原因はサンドボックス解除申請を一度もしていなかったことだった。

ドメイン検証はSESが『あなたはこのドメインの所有者だ』と確認するプロセス。サンドボックス解除はAWSが『あなたは正当な送信者だ』と判断するプロセス。この2つは独立している。

バウンス・苦情率の監視設定（本番移行後の必須作業）

本番移行後にバウンス率や苦情率が高い状態が続くと、AWSがアカウントの送信を一時停止する場合がある。これを防ぐためにSNS通知を設定しておく。

aws ses set-identity-notification-topic \
  --identity 'example.com' \
  --notification-type Bounce \
  --sns-topic arn:aws:sns:us-east-1:123456789012:ses-bounce-notifications \
  --region us-east-1

aws ses set-identity-notification-topic \
  --identity 'example.com' \
  --notification-type Complaint \
  --sns-topic arn:aws:sns:us-east-1:123456789012:ses-complaint-notifications \
  --region us-east-1

バウンス通知と苦情通知をそれぞれ別のSNSトピックに向けておくと、後続のLambdaやSQSでの処理分岐が楽になる。

graph LR A["SES 本番送信"] --> B["受信サーバー"] B -->|"配信不能"| C["バウンスイベント"] C --> D["SNS トピック"] D --> E["Lambda 関数"] E --> F["DB: 配信停止リスト登録"] F --> G["次回送信時スキップ"]

SES送信：本番環境から顧客へメールを送信する。
バウンス発生：受信サーバーが配信不能を返す。
SES → SNS：SESがバウンスイベントをSNSトピックへパブリッシュする。
SNS → Lambda：Lambdaがイベントを受け取り、該当アドレスをDBの配信停止リストへ登録する。
次回送信時にスキップ：配信停止リストを参照し、バウンスアドレスへの送信を回避する。

リージョンごとにサンドボックス状態は独立している

us-east-1で本番移行済みでも、ap-northeast-1（東京）は別途サンドボックス解除が必要だ。SESのサンドボックス状態はリージョン単位で管理される。東京リージョンでSESを使い始めるときに再申請を忘れるケースは実際に多い。

aws ses get-send-quota \
  --region ap-northeast-1

マルチリージョン構成でSESを使う場合は、使用するリージョンそれぞれで申請状況を確認しておく。

SES サンドボックスモード解除：まとめと次のステップ

AWS SESサンドボックスモードは、新規アカウントに自動適用される送信制限だ。自分宛のテストは通るが顧客への送信が失敗する場合、まずget-send-quotaでモードを確認し、本番アクセス申請をAWSサポートへ提出する。申請時はバウンス処理方針とオプトイン方法を具体的に記載することが承認を早める鍵になる。

公式ドキュメント：Moving out of the Amazon SES sandbox
バウンス・苦情管理：Monitoring your Amazon SES sending activity

用語集

用語	説明
サンドボックス（Sandbox）	新規SESアカウントに適用されるデフォルトの制限モード。検証済みIDへの送信のみ許可される。
検証済みID（Verified Identity）	SESで送信元または送信先として使用するために所有権を確認済みのメールアドレスまたはドメイン。
ハードバウンス（Hard Bounce）	存在しないアドレスへの送信など、永続的な配信失敗。継続送信はバウンス率を悪化させる。
苦情率（Complaint Rate）	受信者がスパム報告した割合。AWSが推奨する閾値を超えると送信停止リスクがある。
送信クォータ（Sending Quota）	1日あたりの最大送信数と1秒あたりの最大送信レート。本番移行後は申請値に更新される。

このブログを検索

SW BBANG J