Amazon SES Explained: Sandbox, Sending Quotas and Responsible Email
What the Amazon SES sandbox allows, how to request production access properly, and the bounce, complaint and consent practices that keep sending healthy.
Every new Amazon Simple Email Service (SES) account starts in the Amazon SES sandbox, a restricted mode that lets you build and test your integration before you can email real customers. This guide explains what the sandbox allows, how sending quotas work, how to request production access through the official process, and the bounce, complaint and consent practices that keep an SES account healthy.
What Amazon SES is for #
Amazon SES is AWS’s email sending (and receiving) service. Applications use it to send transactional messages such as password resets, receipts and notifications, and also marketing email to people who have opted in. You connect through the SES API, the AWS SDKs or an SMTP interface.
SES is inexpensive and scales well, which is exactly why AWS protects it carefully. Its shared sending infrastructure depends on every customer behaving well, so AWS enforces verification, sandbox restrictions and reputation monitoring. For a summary of the service’s features, see our Amazon SES overview.
The sandbox: what you can and cannot do #
The sandbox applies separately in each AWS Region where you use SES. While your account is in the sandbox in a Region:
- You can only send to verified email addresses or domains, or to the SES mailbox simulator.
- You can send a limited number of messages per 24-hour period (at the time of writing, 200).
- You can send at a limited rate (at the time of writing, one message per second).
These limits are enough to build and test your integration end to end, including bounce and complaint handling, but not to email real users. Check the current values in the SES console’s account dashboard.
Testing safely with the mailbox simulator
SES provides simulator addresses at simulator.amazonses.com that produce specific outcomes without affecting your reputation metrics. For example, sending to success@simulator.amazonses.com simulates a delivery, bounce@simulator.amazonses.com a hard bounce, and complaint@simulator.amazonses.com a spam complaint. Use them to confirm your notification handling works before you go live.
Verified identities #
SES only sends from identities you have proven you control. There are two kinds:
| Identity type | How it is verified | When to use it |
|---|---|---|
| Email address | Click a link in a verification email SES sends to that address | Quick tests, or a single sender address |
| Domain | Publish DNS records (DKIM CNAME records with Easy DKIM) | Production sending from any address at the domain |
For production, verify the domain. Easy DKIM gives you three CNAME records to publish; once SES detects them, messages are DKIM-signed with your domain. Also consider a custom MAIL FROM domain (a subdomain such as mail.example.com) so SPF aligns with your domain for DMARC. Our guide to SPF, DKIM and DMARC explains why alignment matters and how to publish a DMARC policy.
Requesting production access #
To move out of the sandbox in a Region, submit a production access request through the SES console (the account dashboard has a “Request production access” option). The request is reviewed by AWS, and AWS aims to respond within about a day, sometimes asking follow-up questions.
What a good request includes
AWS wants to understand that you will send email people expect and want. Be specific and honest about:
- Mail type: transactional, marketing, or both.
- Your website URL, so reviewers can see the product and how people sign up.
- Use case: what messages you send, to whom, and how often. “Order confirmations and password resets for customers of our SaaS app, roughly a few hundred per day” is far better than “sending emails”.
- How recipients opt in: for example, account sign-up with confirmed email, or a double opt-in newsletter form.
- How you handle bounces and complaints: describe your SNS notifications or event destinations, and that you remove or suppress those addresses automatically.
- How people unsubscribe from non-transactional mail.
How sending quotas work #
Once in production, your account has two quotas per Region:
- Sending quota: the maximum number of recipients per 24-hour rolling period.
- Maximum send rate: the maximum number of recipients per second.
Both count recipients, not API calls, so one message to five addresses uses five units. SES may raise quotas automatically as you build a history of good sending. If you need more ahead of a known increase in volume, request it through the official quota increase process (Service Quotas or an SES sending limit increase case), explaining your expected volume and how you maintain list quality.
When you exceed the send rate, the API returns a throttling error. Build your sending code to respect the rate (a queue with a controlled worker pool works well) and retry with exponential backoff rather than failing silently.
Bounces, complaints and your reputation #
AWS monitors two metrics for every SES account: the bounce rate and the complaint rate. Both are visible in the SES console’s reputation metrics and in CloudWatch.
- Hard bounces are permanent failures, usually an address that does not exist. Never send to that address again.
- Soft bounces are temporary (full mailbox, server busy). SES retries these for a period before reporting a failure.
- Complaints happen when a recipient marks your message as spam and their mailbox provider reports it back through a feedback loop.
AWS documentation recommends keeping the bounce rate under 2 percent and the complaint rate under 0.1 percent. If rates climb higher, the account can be placed under review, and sustained high rates can lead AWS to pause sending. These thresholds exist because high bounce and complaint rates indicate a list or consent problem that harms deliverability for everyone on shared IPs.
Setting up notifications
You can receive bounce and complaint events in two ways:
- Identity notifications sent to Amazon SNS topics per verified identity.
- Configuration sets with event destinations, which publish sends, deliveries, bounces, complaints, opens and clicks to SNS, CloudWatch, Amazon Data Firehose or EventBridge.
Configuration sets are the more flexible option for production. Subscribe a small function or worker that updates your own user database: mark hard-bounced addresses as undeliverable and treat complaints as unsubscribes.
The account-level suppression list
SES maintains an account-level suppression list. When enabled for bounces and complaints, SES automatically adds addresses that hard bounce or complain, and stops sending to them from your account. You can view, add and remove entries through the console or API. It is a safety net, not a substitute for updating your own database, and you should only remove an address if you are sure the underlying problem is fixed (for example, the recipient corrected a typo in their address).
Consent and list hygiene #
The best way to keep bounce and complaint rates low is to send only to people who asked for your mail.
- Never buy, rent or scrape lists. It violates the AWS Acceptable Use Policy and SES terms, and it reliably produces bounces and complaints.
- Confirm addresses at sign-up with a verification link, which also stops typos entering your list.
- Separate transactional and marketing streams using different configuration sets, and ideally different subdomains, so a marketing problem does not affect password resets.
- Offer easy unsubscribe on marketing mail, including one-click List-Unsubscribe headers, which major mailbox providers now expect from bulk senders.
- Prune inactive recipients who have not engaged in a long time.
- Follow the law that applies to your recipients, such as CAN-SPAM in the US or GDPR and ePrivacy rules in the EU.
SMTP connections from EC2 #
If your application runs on Amazon EC2, note that AWS restricts outbound traffic on port 25 from EC2 instances by default as an anti-abuse measure. Connect to the SES SMTP endpoint on port 587 or 2587 with STARTTLS (or 465 or 2465 with TLS) instead, using SES SMTP credentials, or use the SES API. Our overview of AWS core services explains how SES fits alongside EC2, IAM and the rest of the platform.
Official references #
The Amazon SES documentation covers the sandbox, production access requests, sending quotas, the suppression list and event publishing in detail, and current rates are on the Amazon SES pricing page.
Frequently asked questions #
Is the Amazon SES sandbox per account or per Region?
Per Region. Production access granted in one AWS Region does not apply to others, so request it separately in each Region where you plan to send email.
How long does SES production access take?
AWS typically responds within about one business day, and may ask follow-up questions. Clear details about your use case, opt-in process and bounce and complaint handling help the review go smoothly.
What happens if my bounce or complaint rate is too high?
AWS may place the account under review and, if rates stay high, pause sending. Fix the cause, such as poor list quality or missing consent, and respond to AWS through the case it opens.
Do I still need my own bounce handling if I use the suppression list?
Yes. The account-level suppression list stops SES from sending to problem addresses, but your application should also record bounces and complaints so your own user data and unsubscribe status stay accurate.
