Blog
Amazon SES sandbox: how to get production access
October 6, 2026 · 7 min read
Every new Amazon SES account starts in the sandbox, and nothing you build will reach a real customer until AWS lets you out. The request is a short form, and a lot of them are refused. This is what the sandbox limits, what AWS wants to see, and how to write the request.
What the sandbox limits
In the sandbox, SES lets you:
- Send only to addresses you have verified, plus the SES mailbox simulator. A customer's address won't work.
- Send a small daily quota, typically 200 messages in 24 hours.
- Send about one message per second.
The sandbox is per region. Getting out in us-east-1 does nothing for eu-west-1, so request access in the region you actually send from.
Before you ask
Reviewers are checking that you are a legitimate sender who will handle problems. Have these ready first:
- A verified domain you own with all three DKIM records published. Check it with the free SES DNS checker. A verified sender is a stronger request than a bare email address.
- A working website that matches what you say you send. Reviewers do visit it.
- A plan for bounces and complaints. Ideally this is already running, which is the SNS setup in the next post. If it isn't, say honestly what you will build rather than implying it exists.
What the form asks
In the SES console, open the Account dashboard and choose Request production access. The fields are:
- Mail type: Transactional (sent because of something a user did) or Marketing (promotional or bulk).
- Website URL.
- Use case description: the part that decides the outcome.
- Additional contact addresses and a contact language.
AWS usually replies within about a day, and the answer arrives as a support case.
Writing the use case
A good description answers the questions a reviewer would otherwise have to ask you:
- What do you send, and what triggers it? “Password reset and order confirmation emails, sent when a user requests one” is clear. “Emails to customers” is not.
- How many, and how fast? Give honest estimates per day and your peak rate.
- How do you get recipients' addresses? Sign-up, checkout and double opt-in are good answers. Purchased or scraped lists are against the AWS Acceptable Use Policy and are refused.
- How do you handle bounces and complaints? Name the mechanism: SNS notifications, a suppression list, and what you do with each.
- For marketing mail, how do people unsubscribe?
If you'd rather not start from a blank page, the free request writer asks these exact questions and assembles your answers into a request. It runs in your browser and adds nothing you didn't type.
If you are denied
A denial is not final. AWS replies in the same support case, and you can answer and reopen it. Read the reply for what they objected to, fix that specific thing and respond with the change. Common causes:
- The description was too vague. Rewrite it with the specifics above.
- Bounce and complaint handling was missing or only promised.
- The website didn't match the use case, or wasn't live.
- The recipient list sounded purchased, rented or scraped.
Don't exaggerate
Don't inflate volumes or claim compliance programs you don't have. If your sending later looks different from what you wrote, AWS can pause the account, which is worse than a denial.
After approval
Your quota rises and the recipient restriction goes away, but a new quota is still limited. Watch your bounce and complaint rates from day one: AWS reviews accounts whose rates run high, and handling both automatically is what keeps you in good standing.