Getting out of the SES sandbox: what AWS is actually asking for
A denied SES production access request usually means a vague answer, not a broken setup. What AWS's form asks and what a strong answer looks like.
A denied Amazon SES production access request almost never means AWS found something wrong with your account. It means your answer didn’t tell AWS what it needed to know. The request form is short, four fields and a checkbox, and every one of those fields is standing in for a question: what kind of mail is this, where does it come from, did the recipient ask for it, and what happens when they don’t want it anymore. Answer any of those vaguely and the request reads the same as one AWS has good reason to be cautious about.
The fix isn’t a magic phrase. It’s putting a real, checkable answer in a field that most guides treat as an afterthought.
Key takeaways
- The sandbox caps you at 200 messages per 24 hours and 1 per second, to verified recipients only. AWS’s own SES documentation.
- The console’s request form has no free-text “describe your use case” box anymore. What you write in Website URL is doing more work than it looks like.
- AWS aims to give an initial response within 24 hours. If it asks for more, that’s not a denial, it’s a request for the specifics you didn’t include.
- A denial reply that lists changes you’ve already made outperforms one that lists changes you’re planning to make. That’s AWS’s own instruction for any account review, not a guess.
What the sandbox actually restricts
Every new SES account starts in the sandbox, and the restriction is per AWS Region. Per Amazon’s own SES documentation, a sandboxed account can:
- send only to email addresses and domains you’ve verified yourself, or to the SES mailbox simulator
- send a maximum of 200 messages in a 24-hour period
- send at a maximum rate of 1 message per second
Bulk suppression-list actions and the suppression-list API calls are also disabled at the account level while you’re sandboxed. You can build and test everything else, campaigns, templates, DNS, DKIM, but you can’t run a real send until AWS lifts the sandbox.
The form is shorter than most guides describe
A lot of what’s written about this request describes a form with a free-text “use case” box, a mailing-list description, separate fields for bounce handling and unsubscribes. That form existed: an AWS messaging blog post from April 2024 walks through exactly those fields. The current console form doesn’t have them. What you get is:
| Field | What it asks |
|---|---|
| Mail type | Marketing or Transactional, whichever is most of your volume |
| Website URL | The site the content comes from |
| Additional contacts | Up to 4 emails to loop in, optional |
| Preferred contact language | English or Japanese |
| Acknowledgement | One checkbox: you only send to people who asked for it, and you have a bounce and complaint process |
There’s nowhere to type “here’s how our opt-in works.” The website URL field is the closest thing to it, which is why a live site that actually shows a signup flow, a privacy policy and an unsubscribe link does more for a request than any wording would. A placeholder page or a bare domain answers none of the questions AWS is actually asking.
What AWS is actually evaluating
The fields disappeared; the criteria didn’t. Amazon’s own enforcement FAQ, describes the same account in production the same way it would evaluate a request to leave the sandbox: does this sender have consent, and does this sender have a process for what happens when consent turns out to be wrong.
Concretely, that’s:
- List acquisition. Where the addresses came from, and whether the recipient did something specific to ask for mail. AWS’s guidance is blunt: don’t buy, rent, or share addresses.
- Bounce and complaint handling. Whether failures and spam reports feed into something that stops future sends to that address, automatically, not “we check periodically.”
- Unsubscribe. A working, visible way to opt out, honored immediately.
Those same three things are what keeps an account healthy once it’s approved. AWS enforces two thresholds on every SES account, sandboxed or not: an account is placed under review at a 5% bounce rate and can be paused at 10%; it’s placed under review at a 0.1% complaint rate and can be paused at 0.5%. AWS’s own recommendation is to keep bounces under 2% and complaints under 0.1%, well clear of the bounce line and right at the complaint one. A production access request is AWS deciding whether to bet that you’ll stay under those numbers. Showing the process that keeps you there, rather than asserting that you will, is the actual content of a strong request.
One thing that measurably helps: verifying a sending domain before you submit. AWS’s own documentation calls this a best practice that speeds up approval, and the console surfaces the request option directly from the setup page once a domain is verified.
A vague request and a specific one
AWS’s own guidance from the same 2024 blog post names the failure mode directly: don’t write “Please remove from sandbox and move to production.” That sentence answers none of the four questions. Compare the shape of the two:
A vague request describes the goal (“we want to send marketing email to our users”) and stops. It leaves the website URL as a bare domain, a coming-soon page, or a link that doesn’t resolve. It has no answer for bounces beyond “we’ll deal with it.”
A specific request names the actual list: who signs up and where, whether it’s single or double opt-in. It says what happens to a bounce or a complaint in concrete terms, an SNS notification into an automated suppression step, not a re-send. It points to a live site whose content matches the volume and type claimed on the form. None of this needs to be long. It needs to be checkable.
How long it takes, honestly
Per AWS’s documentation: the Support team aims to give an initial response within 24 hours. If AWS can grant the request outright, it does so inside that window. If it needs more information first, resolution takes longer, and there’s no published number for how much longer. Don’t read a slow response as a soft denial. AWS doesn’t have a mechanism to notify anyone but the account holder either way, so if you’re waiting, keep an eye on the Support Center case rather than assuming silence means no.
Testing your bounce and complaint handling against the SES mailbox simulator before you submit doesn’t just make your request stronger, it means the answer you give is already true rather than aspirational, which is the difference AWS is actually checking for. The simulator works from inside the sandbox and sends fake bounce, complaint and delivery events on request, without touching your real sending quota or reputation metrics.
If AWS denies it
There’s no separate appeals form. You reply to the same AWS Support case. AWS’s own guidance for responding to any account-level review is specific on one point that generalizes well here: list the changes you’ve already made, not the ones you’re planning to make. A request that says “we will add double opt-in” is a promise; a request that says “the signup form has required double opt-in since last month, here’s the confirmation email it sends” is evidence.
If you’re connecting your own AWS account through EmailFig, the request itself happens entirely inside AWS. We can’t file it, speed it up, or see why AWS said no; what we do is check for the change and start sending the moment it lands. The full click path, including where that check happens, is in Leave the SES sandbox: request production access. Once you’re out, your send rate and daily quota come from your own AWS limits for the first time, and the bounce and complaint thresholds above are the ones that keep mattering.
Where this fits
This whole process is one step in a bigger picture: Amazon SES for email marketing, the complete guide covers what SES gives you and what it doesn’t, sandbox included.
It belongs specifically to BYOS, EmailFig’s plan family that sends through your own connected AWS account. It’s also why BYOS costs less per month than managed at the same list size: you’re paying Amazon directly for what you send, at the rates in what Amazon SES actually costs, instead of paying for it bundled in. If opening an AWS account and clearing this request isn’t a step you want to own, managed plans send on EmailFig’s own sending identity and skip it entirely. Both start free up to 4,000 contacts, no card required, and BYOS and managed sit side by side on pricing.
Sendy, BigMailer and the other hosted SES front ends all put you through this same request, since none of them can file it on your behalf either. Our BigMailer comparison covers what differs once you’re through it.