はじめに
「SES のサンドボックス解除申請、出しておいてください」
上司にそう言われて素直に申請したら、却下（DENIED） が返ってきた経験はないでしょうか。
却下された場合、AWS のサポートケースを開くと、こんな感じのメッセージが届きます。
しかも却下理由は「セキュリティ上の理由で詳細は開示できません」の一点張りなので、何が悪かったのかすらわかりません。
この記事では、実際に却下→再申請→承認まで辿り着いた体験をもとに、再申請のコツと使えるテンプレートを共有します。
いきなり結論
私は以下の2点を補足して再申請したところ、約33時間後に承認されました。
- 同一 Organizations 内の他アカウントでの承認実績（サポートケース ID 付き）
ses:Recipientsポリシーによる送信先ドメイン制限
AWS の審査基準は非公開なので、これが決め手だったかはわかりませんが、初回と同じ内容をもう一度送っても通らないのは確実なので、「審査側の不安を潰す材料を足す」というアプローチ自体は有効だと考えています。
この記事は「こうすれば必ず通る」という保証ではありません。あくまで筆者の環境で効果があった一例です。
SES サンドボックスとは
Amazon SES は、不正利用防止と送信者レピュテーション保護のため、新規アカウントを「サンドボックス」と呼ばれる制限モードに配置します。
| 項目 | サンドボックス | 本番アクセス |
|---|---|---|
| 送信先 | 検証済みアドレス・ドメインのみ | 任意のアドレス |
| 送信上限 | 200通/24時間 | アカウントごとに設定 |
| 送信レート | 1通/秒 | アカウントごとに設定 |
| 送信認可 | 委任者も非検証アドレスに送信不可 | 制限なし |
サンドボックスの状態は リージョンごとに独立 しています。東京リージョンで解除されていても、バージニアリージョンではサンドボックスのまま、ということがあり得ます。
トランザクションメール（パスワードリセット・招待通知など）を本番環境で送るには、このサンドボックスを解除する申請（= 本番アクセスのリクエスト）が必要です。
参考: Request production access (Moving out of the Amazon SES sandbox)
初回申請で書いたこと
現在の申請フロー（2026年3月時点）
現在の流れは以下の通りです。
- リクエスト送信 — コンソール or CLI でメール種類・URL・連絡先を入力して送信
- AWS から問い合わせ — サポートケースでユースケースの詳細を聞かれる
- ユースケースを返信 — サポートケースに返信する形で用途を説明
申請方法は2つあります。
- コンソール: SES の「アカウントダッシュボード」→「設定をはじめるページを表示」→「本番アクセスをリクエスト」（事前にドメイン検証が必須）
-
AWS CLI:
sesv2 put-account-detailsコマンド
今回は CLI で申請しました。
aws sesv2 put-account-details \
--production-access-enabled \
--mail-type TRANSACTIONAL \
--website-url https://example.com \
--additional-contact-email-addresses contact@example.com \
--contact-language JA \
--region ap-northeast-1
リクエスト送信後、AWS サポートからユースケースの問い合わせがあったので、以下の内容を返信しました。
（正直、かなり丁寧に書いたつもりです。）
- メール送信のプロセス・手順 — Web アプリケーションが SES の SMTP インターフェースを利用し、イベント発生ごとに即時送信
- 送信頻度 — 50件/日程度。マーケティングメールや大量一括送信の予定なし
- 受信者リスト管理 — アプリケーション側で管理。ユーザー自身が登録・更新
- バウンス・苦情の管理方法 — SNS/CloudWatch で監視し、該当アドレスを自動で送信対象外にする
- 送信メールのサンプル — 実際に送信する招待メールの件名・本文を添付
- ドメイン認証 — SES コンソールで検証済みであることを明記
却下された
ユースケースを返信してから数日後、同じサポートケースに却下の通知が来ました。
制限引き上げリクエストを検討した結果、現時点では承認できません。
評価中に懸念事項が特定されましたが、セキュリティ上の理由で具体的な基準は開示できません。
理由を教えてくれません。 これが SES 申請のつらいところです。
却下後のアカウント状態を確認する（get-account の出力）
aws sesv2 get-account --region ap-northeast-1
{
"ProductionAccessEnabled": false,
"SendQuota": {
"Max24HourSend": 200.0,
"MaxSendRate": 1.0,
"SentLast24Hours": 0.0
},
"SendingEnabled": true,
"Details": {
"MailType": "TRANSACTIONAL",
"ReviewDetails": {
"Status": "DENIED"
}
}
}
ReviewDetails.Status が DENIED になっているのが確認できます。
再申請で何を変えたか
ここからが本題です。再申請では 2つの補足情報 を追加しました。
補足①：同一組織内の他アカウントでの承認実績
同じ AWS Organizations 内の別アカウントで、同用途・同構成で既に SES 本番アクセスが承認されていましたので、そのサポートケース ID を明示しました。
意図としては、前例を提示することで「この組織は信頼できる」という判断材料になりうると考えました。
補足②：IAM ポリシーによる送信先ドメイン制限
SES の承認 ID ポリシーで ses:Recipients 条件を使い、送信先を社内ドメインのみに限定していることを伝えました。
{
"Condition": {
"ForAllValues:StringLike": {
"ses:Recipients": [
"*@company-a.co.jp",
"*@company-b.co.jp"
]
}
}
}
意図としては、外部ドメインへの送信をポリシーレベルで拒否しているため、AWS 側から見たスパム送信リスクを大幅に低減できるのではと考えました。
再申請テンプレート
以下は実際に承認された再申請文をベースにしたテンプレートです。既存のサポートケースに返信する形で送りました。
ご担当者様
お世話になっております。
補足情報を追記の上、再度SESサンドボックス解除のご検討をお願いいたします。
■補足情報
１．同組織の他AWSアカウントでの承認実績
同一組織内の他AWSアカウントにおいて、同様の用途・構成で
SES本番アクセスが既に承認されております。
（サポートケースID：XXXXXXXXX、XXXXXXXXX）
本アカウントにおいても同一の運用ポリシーで利用いたします。
２．SES承認IDポリシーによる送信先の制限
本アカウントではSESの承認IDポリシーにおいて、
Conditionのses:Recipients条件により送信先を
社内ドメインのみに限定しております。
外部ドメインへのメール送信はポリシー上拒否される設定です。
上記を踏まえ、本番アクセスの承認を再度ご検討いただけますと幸いです。
再申請は CLI（put-account-details）ではなく、既存のサポートケースに返信する形で行います。CLI で再度申請しようとすると ConflictException になります。
却下された時の対応フロー
注意点
| ポイント | 詳細 |
|---|---|
| 却下理由は開示されない | 「セキュリティ上の理由」で一律非開示。推測して補強するしかない |
| 審査結果はケースバイケース | アカウントの状態や申請内容によって判断が異なる |
| 承認は即時ではない | 再申請から承認まで24〜48時間程度。余裕を持って申請する |
SuppressedReasons を確認 |
get-account の結果に BOUNCE / COMPLAINT が含まれている場合、既に問題が検知されている可能性がある |
まとめ
SES サンドボックス解除は「出せば通る」ものではありません。
却下されたときのアプローチとして、審査側が「このアカウントはスパムに使われない」と判断しやすい材料を揃えることが重要だと考えています。
私の場合は以下の2点を補足しました。
- 組織内の承認実績 → 「信頼できる組織である」材料
- 送信先のポリシー制限 → 「外部送信リスクが低い」材料
これが直接の決め手だったかはわかりませんが、少なくとも初回申請から情報を追加しなければ結果は変わらなかったでしょう。
SES の申請は本番リリースのクリティカルパスに乗りがちなので、最低1週間前には申請しておくことをおすすめします。
却下されても、落ち着いて補足情報を添えれば大丈夫です。