Amazon SESのサンドボックス解除、承認までの流れはアカウントの状況によって変わるようです

はじめに

クラウド事業統括本部の浅野です。

2026年9月現在、メールMFAまわりの検証をしていて、Amazon SESのサンドボックス解除の申請をしました。

SESの申請手順が以前と変わっていて、用途をフォームではなくサポートケースで聞かれるようになった、という話はすでにいくつかの記事で見かけます。それは知っていたのですが、いざ自分で申請してみると、自分のアカウントは用途を聞かれてやりとりが発生した一方で、同じ最新のフォームでも何も聞かれず数分で承認された、という事例も見つけました。

どうやらアカウントや申請内容によって、審査の進み方が分かれているようです。この記事は、その違いに気づいて調べてみた記録です。

フォームから用途の記入欄がなくなっている

まず、全員に共通する前提から。サンドボックス解除、つまり本番アクセスの申請は、SESのアカウントダッシュボードに出るサンドボックスの通知から始まります。

この通知から「設定を開始」ページに進むと、「本番アクセスをリクエスト」のボタンがあります。

このボタンから開くのが申請フォームです。以前はこのフォームの中に用途を書く欄がありましたが、今はそれがなく、入力するのはメールタイプ、ウェブサイトのURL、連絡先、希望言語、同意チェックだけです。

そのまま承認される人と、用途を聞かれる人がいる

ここが本題です。用途欄がなくなったのは全員共通ですが、そのあとの進み方は人によって違います。

公式ドキュメントによると、フォームを送ると24時間以内に最初の返答があり、問題がなければそのまま承認されます。ただし「追加の情報が必要な場合は時間がかかることがある」とも書かれていて、このときに用途などをあらためて聞かれます。今回の自分は、この後から聞かれるパターンでした。

そのまま承認される人と、後から用途を聞かれる人に分かれるわけですが、何がこの違いを決めているのかは公式には示されていません。あくまで推測ですが、申請の内容やアカウントの状態を見て、追加の確認が必要かどうかが判断されているのだと思います。

実際、世に出回っている記事内でも、同じ最新のフォーム同士で結果が分かれています。

何が違いを生むのか

何が分かれ目になっているのかは公式には示されていないので、ここからは今回の自分のケースをもとにした推測です。ありそうな理由は次の3つだと考えています。

• アカウントの立ち位置。直接契約した作りたてのアカウントで、利用実績も課金実績もほとんどない状態でした。AWSのリセール（請求代行）を通じて契約していて、その契約のもとで利用実績が積み上がっているアカウントだと、同じような申請でもあっさり承認されるケースがあるようです
• ドメイン。当日取得したばかりの.clickドメインでした。安価に取得できるTLDとして認識されている可能性があり、TLDの選択が審査に影響した可能性はあると思っています
• 用途。自分の申請では、ペネトレーションテストという用途を記載しました。マーケティングやトランザクション通知といったメール送信の一般的な用途と比べると、セキュリティ検証という特殊な目的なので、審査側が追加の確認を必要と判断した可能性があります

警戒されそうな条件がそろっていたので、用途を聞かれたのは当たり前だと思います。なかでもアカウントの立ち位置は、影響が大きいように感じています。

なお、送信元ドメインはSESでDKIMの検証を済ませた状態で申請しましたが、それでも用途は聞かれました。DKIMやSPFが整っているかどうかは、この分かれ目にはあまり関係していないのかもしれません。

今回の申請の流れ

ここからは、自分が実際にたどった流れです。

フォームを送ると、ステータスがレビュー中になります。

しばらくすると、AWSから追加の情報提供を求める連絡が届きました。一般的には、送信の頻度、受信者リストの管理、バウンスや苦情への対応などについて説明を求められます。ダッシュボードのステータスも「さらに情報が必要です」に変わります。

届いた連絡はこちらです。件名以外は伏せています。

案内にしたがって、サポートケースの「返信」から用途などの情報をあらためて伝えると、審査に進みます。

申請の内容

今回申請した内容です。

• 用途: メールでのMFA、ワンタイムコードのログインを試す検証用のWebアプリ
• 送信元ドメイン: SESでDKIMの検証を済ませた独自ドメイン。TLDは.click
• メールタイプ: トランザクション
• 送信量: 少量で、一時的な検証利用

今回は英語で、用途と送信量、一時的な利用であることを簡単に伝えました。とはいえ日本語で書いても問題なさそうな感触でした。

参考までに、今回実際に送った文面はこちらです。

Security verification environment for email-based MFA penetration testing.
The app sends one-time passcodes (OTP) for email-based MFA login.
Low volume, temporary use for a single verification.

今回はかなり簡略化しましたが、本来は次のような項目を埋めておくと審査がスムーズだと思います。

• 送信するメールの内容と目的（例: MFAのワンタイムコード、登録完了通知など）
• 送信の頻度と、1日あたりの想定送信数
• 受信者リストの集め方（オプトインの有無）と管理方法
• バウンス・苦情への対応方法
• 配信停止（オプトアウト）の手段

流れを時刻で並べるとこうなります。

承認までの日数: 約3日（土日を除くと実質2営業日ほど）

申請したのは土曜で、承認は火曜の夜でした。日数にすると約3日ですが、あいだに土日を挟んでいるので、営業日でいえば月曜と火曜の2日ほどです。公式ドキュメントでは、必要な情報がそろっていれば24時間以内に承認されるとありますが、今回はそれより少しかかりました。

追加の情報を求める連絡は、申請してから1分ほどで届きました。用途はこの連絡が来てから初めて聞かれるので、フォームを送った時点ではまだ審査は始まっていないようです。

承認されると送信できる量が増えます。aws sesv2 get-accountで実際に測った値を残しておきます。

承認前は200通/24h・1通/秒でしたが、承認後は50,000通/24h・14通/秒まで上がりました。これは以前からよく紹介されている標準の値と同じでした。

承認後のアカウントダッシュボードはこのようになります。送信制限が50,000通/24h・14通/秒に上がり、ステータスも正常のままです。

注意点

用途を聞かれた場合、フォームを送っただけでは申請は完了しません。追加の情報を求める連絡が届いたら、その案内にしたがって情報を提出するまで審査は進まないので、届いたら早めに対応しましょう。

最後に

自分は用途を聞かれて3日ほどかかりましたが、何も聞かれずに数分で承認される人もいます。

この記事でいちばん伝えたかったのは、同じ手順でも、承認までの経緯はアカウントやドメインの状況で変わりうるという点です。直接契約の新規アカウントなのか、リセール経由で実績のある契約の配下なのか、ドメインや用途がどう見られるか、といった点が条件分岐のトリガーになると推測しています。

もし自分の申請が用途を聞かれる側だったとしても、慌てず、用途や送信量、バウンスや苦情への対応を求められたら丁寧に伝えれば大丈夫です。スムーズに通したいなら、取得直後の安価なドメインは避けて評判の良いドメインを使い、用途をはっきり説明できるようにしておくのが良さそうです。今回は以上です。