From SES Sandbox to 50,000 Emails/Day: The Production Access Playbook
Every AWS account starts in the SES sandbox. Two hundred emails a day, every recipient individually verified, no exceptions. For a startup, that's not a limit — it's a ceiling you hit the first time you send a real welcome-email batch.
Here's the playbook for getting out. It's the exact path that got MailAnvil approved for 50,000 emails/day, written so you can copy the process instead of guessing at it.
Why the Sandbox Exists
SES is a shared reputation system. When one account blasts spam through it, deliverability drops for everyone. So AWS gates production sending behind a manual review: prove you're sending legitimate transactional mail, and the limits come off.
The sandbox baseline:
| Limit | Sandbox | Production |
|---|---|---|
| Daily sending quota | 200 emails | 50,000+ (negotiable) |
| Send rate | 14/second | 50+/second (higher on request) |
| Recipients | Must verify each one | Any recipient on a verified domain |
| Verified domain | Required | Required (plus DKIM/SPF/DMARC) |
The 200/day ceiling is the real blocker. A single OTP flow at modest traffic — signup, login, password reset — burns through that in under an hour.
The Approval Flow, Step by Step
1. Verify your domain (not just an email address)
Sandbox mode lets you verify individual addresses. Production access requires a verified domain with authentication records in place:
SPF: v=spf1 include:amazonses.com ~all
DKIM: three CNAME records (1024-bit, match your region)
DMARC: v=DMARC1; p=none; rua=mailto:[email protected]
If your DNS lives on Cloudflare, the DKIM records are three CNAME entries that SES generates for you. Copy them exactly — a missing or truncated record is the most common rejection reason.
2. Write the use case AWS actually wants to see
This is the step people flub. AWS isn't asking for a business plan. They want to confirm four things:
- What you send — "transactional OTP emails, password resets, order confirmations." Not "marketing newsletters."
- How you get addresses — "all recipients are users who signed up or initiated the action." Explicit opt-in. No purchased lists.
- How you handle bounces and complaints — "we process SES bounce/complaint notifications and suppress those addresses automatically within seconds." If you can't say this, you're not ready.
- Opt-out path — a working unsubscribe mechanism, even for transactional mail.
A submission that covers these four points in plain language has a far higher approval rate than a polished essay that skips bounce handling.
3. Request the increase
In the SES console: Account dashboard → Request production access, or open a support case under Service limit increase. State your current volume, your projected volume, and paste the use case. A typical approval lands in 24–72 hours; AWS sometimes replies asking for one clarification (usually about complaint handling).
4. Don't send 50,000 on day one
Approval removes the ceiling. It does not give you a good sender reputation. New domains still need warmup:
Day 1–3: 500 emails/day
Day 4–7: 2,000 emails/day
Week 2: 10,000 emails/day
Week 3: 25,000 emails/day
Week 4: full approved volume
Skip warmup and the approval is wasted — Gmail's reputation system will shunt you to spam regardless of what AWS allowed.
What Changes After Approval
Production access is not just a bigger number. Three things shift:
Deliverability is now your responsibility. AWS stops holding your hand. Bounce rates above 5% and complaint rates above 0.1% will get the account throttled or suspended. You need real-time bounce/complaint processing, not a weekly cleanup script.
Suppression becomes non-negotiable. The moment a recipient hard-bounces or clicks "mark as spam," that address must never be sent to again — at the enqueue layer and the send layer. SES tracks this per-account; repeat offenders get shut down.
Monitoring moves from nice-to-have to critical. You need visibility into send rate, bounce rate, complaint rate, and per-domain reputation. A silent drop in inbox placement is a silent churn event.
The Shortcut: Don't Run SES Yourself
The playbook above works. It's also a week of engineering effort that has nothing to do with your product:
- Building the bounce/complaint webhook handler
- Maintaining the suppression list (with TTLs and re-add logic)
- Implementing retries with exponential backoff on soft bounces
- Watching the reputation dashboard and reacting to spikes
That's the case for a managed transactional email API that already runs SES behind the scenes. You get the 50,000/day capacity and the deliverability infrastructure without owning the AWS relationship.
MailAnvil is built exactly this way: SES as the sending backbone, with domain verification, DKIM signing, bounce/complaint suppression, and rate limiting handled at the API layer. Production access is already granted — you start at production capacity, not at the sandbox ceiling.
The Bottom Line
The SES sandbox is not a bug; it's a filter. It separates senders who've thought through bounce handling, suppression, and opt-in from everyone else.
If you're building a product and just need reliable transactional email, skip the case ticket and the warmup anxiety — use an API that's already through the door. If you want to run SES yourself, the playbook above is the path: verify your domain, write a use case that names bounce handling explicitly, and warm up your volume over a month, not a weekend.
Either way, the goal is the same: inbox placement that holds as you scale from your first OTP to your first 50,000 emails a day.
MailAnvil is an MCP-native transactional email API for Indonesian developers — IDR pricing, QRIS/GoPay payments, Bahasa support, and Cloudflare-native infrastructure with production SES capacity. Try it free at mailanvil.com.