Amazon SES is one of the cheapest and most reliable ways to send application email at volume. It is also gated: every new account starts in a sandbox that prevents real use, and getting out requires an approved request.
What the sandbox restricts
In sandbox mode an SES account can only send to verified addresses and domains. That is enough to test your integration and nothing else, because you cannot send to a customer who has not verified an address with you first.
Sandbox accounts also carry very low sending and rate limits, so even within verified recipients you cannot test at realistic volume.
Getting production access
Production access is requested through the console. AWS reviews the request and wants to see that you have thought about deliverability and abuse, specifically:
- What mail you will send and to whom.
- How recipients opted in.
- How you handle bounces and complaints.
- How recipients unsubscribe.
Vague requests are commonly rejected. A request that names the mail types, describes a bounce and complaint handling process, and explains list hygiene is far more likely to be approved.
The review takes time, and rejections mean iterating. That delay is the reason accounts already in production mode are sold: the limits are the product.
Understanding the two limits
| Limit | What it controls |
|---|---|
| Sending quota | Maximum messages in a 24 hour period |
| Sending rate | Maximum messages per second |
Both matter, for different reasons. The daily quota caps total volume. The rate limit caps burst throughput, which is what you hit when a campaign or a queue drains all at once. An account described as having 50K or 100K limits is describing the daily quota.
Limits increase over time with good sending behaviour, and they can be reduced or the account suspended if bounce and complaint rates climb.
Reputation is the real constraint
Production access gets you permission to send. It does not get you delivered. AWS monitors two metrics closely:
- Bounce rate. Sustained high bounce rates indicate poor list hygiene and will trigger review.
- Complaint rate. Recipients marking mail as spam is the strongest negative signal there is.
Keep both low by removing hard bounces immediately, honouring unsubscribes promptly, and never sending to purchased or scraped lists. Configure the bounce and complaint notifications through SNS so you find out automatically rather than by discovering your account suspended.
Authentication
Set up domain authentication before sending. Publish the DKIM records SES gives you, add SES to your SPF record if you use a custom MAIL FROM domain, and publish a DMARC policy. Without these, a meaningful proportion of your mail will be filtered regardless of your sending reputation.
SES versus running your own mail server
If you are sending application email, use SES or a comparable service. Running your own mail server on a DigitalOcean or Hetzner box with port 25 open means owning IP warming, blocklist monitoring, retry logic and reputation management yourself. That is a real job, and SES exists so it does not have to be yours.
Run your own only when you need to receive and relay mail, not just send it.
Before you deploy
Change the delivered credentials, enable multi-factor authentication, create a dedicated IAM user with SES send permissions only rather than using broad credentials in your application, set a billing alert, and configure bounce and complaint handling before your first real send.
Common questions
How long does production access review take?
It varies. Well-documented requests move faster; vague ones are often rejected and have to be resubmitted.
Do limits apply per region?
Yes. SES quotas are regional, so an increase in one region does not apply in another.
What bounce rate is too high?
AWS publishes thresholds at which accounts come under review. Keeping well below them, rather than near them, is the safe approach.