How to get Amazon SES production access: what AWS actually looks for
Every new Amazon SES account starts in sandbox mode, and you cannot run a real email campaign from the sandbox. Getting out requires submitting a production access request — a short form that AWS reviews, usually within about 24 hours.
The form is easy to fill out badly. Vague answers get rejected, and a rejection means rewriting and resubmitting while your launch waits. This guide covers what the sandbox actually restricts, what AWS is looking for in the request, and how to write one that gets approved the first time.
What is the SES sandbox?
The sandbox is AWS's default state for every new SES account. It exists for one reason: to stop spammers from creating fresh AWS accounts and blasting mail on day one. Until you convince AWS you're a legitimate sender, three limits apply:
- You can only send to verified email addresses. Every recipient must be individually verified in the SES console — they get a confirmation email and have to click it. Fine for testing with your own addresses; impossible for a real list.
- 200 emails per 24 hours. A hard daily cap.
- 1 email per second. A hard rate cap.
The recipient restriction is the one that actually blocks you. Even a 50-person newsletter can't work if all 50 people have to click an AWS verification link first.
To be clear about what the sandbox doesn't restrict: you can verify your sending domain, set up DKIM, configure everything, and send test emails to yourself. The sandbox is a fine place to build; it's just not a place to launch.
What you can still do while in the sandbox
Don't wait for approval to start setup. Everything below works in sandbox mode, and doing it first makes your production request stronger:
- Verify your sending domain and add the DKIM CNAME records to your DNS
- Add a DMARC record (start with
p=none) - Verify your own address and send test campaigns to yourself
- Wire up bounce and complaint tracking (if you use a platform like Sendra, this happens automatically when you connect your SES account)
- Import and organize your contact list in whatever software you're using
A production request from an account with a verified domain and authentication in place reads as a serious sender. A request from a blank account reads as someone in a hurry.
How to request SES production access
- Open the SES console and go to Account dashboard (or click the sandbox banner).
- Click Request production access.
- Fill out the form:
- Mail type — "Marketing" for newsletters and campaigns, "Transactional" if that's genuinely your use case.
- Website URL — your website or landing page. It should be live and should plausibly belong to someone who sends the email you're describing.
- Use case description — the field that decides the outcome. Details below.
- Additional contacts — an email AWS can reach for follow-up questions. Use one you actually check.
- Submit and watch for AWS's response, both in the SES console and by email.
How to write the use case description
This free-text field is where requests are won or lost. AWS's reviewers want confidence on three questions: what are you sending, who agreed to receive it, and what happens when something goes wrong? Answer all three explicitly.
1. What you send, and to whom. Be concrete. Not "marketing emails to our users" but:
"We send a weekly product newsletter to users who opted in through the signup form on ourcompany.com. Expected volume is about 2,000 emails per week."
2. How recipients opted in. This is the heart of the review. Say explicitly that every recipient opted in, and describe the mechanism: a signup form on your site, a checkbox at account creation, a double opt-in confirmation. If you imported a list, say where it came from and that it consists of existing opt-in subscribers.
3. How you handle bounces, complaints, and unsubscribes. AWS wants to know bad addresses get removed and unhappy recipients can leave. Something like:
"Bounces and complaints are processed automatically via SNS notifications: hard bounces are suppressed and complainers are unsubscribed immediately. Every email includes a one-click unsubscribe link, honored instantly."
If you're using sending software, name it — "we use Sendra, which handles bounce/complaint suppression and includes unsubscribe links in every campaign" is a legitimate and useful thing to say.
4. Request a realistic volume. Ask for limits that match your actual list. If you have 3,000 subscribers and send weekly, you don't need 500,000 emails per day, and asking for it invites scrutiny. Quota increases later are routine; start modest.
Common reasons SES production requests get rejected
Rejections usually trace back to one of these:
- Generic descriptions. "We want to send emails to our customers" gives the reviewer nothing. Specificity is the single biggest factor.
- No mention of opt-in. If you don't say how people joined your list, AWS assumes the worst.
- No bounce/complaint story. Silence on this reads as "we haven't thought about it."
- Purchased or scraped lists. If your list wasn't built from people who asked to hear from you, no phrasing fixes that — and sending to it would tank your account anyway.
- Mismatched details. A website that doesn't exist, doesn't match the described use case, or has no visible way to sign up for the emails you claim to send.
- Unrealistic volume requests from brand-new accounts.
If you're rejected, AWS says so by email, sometimes with questions. You can reply with more detail or submit a new request. Treat it as a request for specifics, not a verdict — plenty of legitimate senders get approved on the second pass after tightening their description.
How long does SES production access take?
AWS typically reviews requests within 24 hours. Some clear in a few hours; some take a couple of business days, especially if the reviewer replies with follow-up questions. Build the wait into your launch plan — submit the request as soon as your domain is verified, not the day you want to send.
Don't submit duplicate requests while waiting; answer follow-ups promptly and completely, since each round-trip adds a day.
What you get after approval
Once approved:
- You can send to any email address — no more per-recipient verification.
- Your daily quota increases, typically to 50,000 emails per 24 hours to start.
- Your rate limit increases beyond 1 email per second.
- You can request further quota increases as your volume grows. AWS also raises limits automatically over time for senders with healthy metrics.
Production access is a starting line, not a finish line. AWS monitors your bounce and complaint rates continuously, and sustained bad metrics can get your sending paused even after approval. Keep hard bounces under 5% and complaints under 0.1%, and if your domain is new, warm it up — start with your most engaged contacts and grow volume over a few weeks rather than sending to the full list on day one.
Where Sendra fits
If you're setting up SES for email marketing, Sendra checks your SES account status during onboarding and warns you if you're still in sandbox mode, so you won't discover the limits mid-launch. You can complete the whole setup — connect SES, verify your domain, import contacts, build your first campaign — while the production request is pending, then send the moment AWS approves.
Sendra also gives you concrete things to cite in your request: automatic unsubscribe links in every campaign, and automatic bounce and complaint suppression via SNS. Those are exactly the answers AWS's form is fishing for.
The full reference lives in our docs: SES sandbox and production access.
Quick checklist
Before you submit:
- Domain verified in SES, DKIM records added
- Website live, with a visible signup path for the emails you describe
- Use case description names the email type, audience, opt-in mechanism, and expected volume
- Bounce, complaint, and unsubscribe handling described explicitly
- Requested volume matches your actual list size
- Contact email is one you monitor
Get those six right and the sandbox is usually a one-day speed bump, not a blocker.