- Amazon SES is extremely cheap (around $0.10 per 1,000 emails) but splits deliverability responsibility between AWS and you; getting that split wrong is the most common reason SES accounts get suspended.
- AWS enforces reputation thresholds: keep bounce rate under 5% and complaint rate under 0.1%; at roughly 5% bounce or 0.1% complaint your account is reviewed, and near 10% bounce or 0.5% complaint it can be paused.
- Every new account starts in the sandbox (200 messages per 24 hours, 1 per second, verified recipients only); production access lifts this, commonly to around 50,000 per day initially.
- Dedicated IPs must be warmed (standard dedicated IPs manually over 4 to 8 weeks; managed dedicated IPs warm automatically), and new IPs sending large volume cold will hurt deliverability.
- Use configuration sets to separate mailstreams (marketing vs transactional) and the SES suppression list plus SNS event notifications to handle bounces and complaints automatically.
Amazon SES is the paradox of email infrastructure: it is simultaneously the most cost-effective way to send email at scale and one of the easiest platforms to get your sending suspended on. The reason is baked into its design. Unlike a traditional ESP that manages reputation for you behind a friendly dashboard, SES hands you the raw infrastructure and, with it, the responsibility for deliverability. That trade (rock-bottom pricing in exchange for owning your own reputation management) is a great deal for teams that know the rules and a trap for those who do not.
This guide covers how to run SES so it stays fast, cheap, and un-paused: the reputation thresholds AWS actually enforces, how the sandbox and sending limits work, how to warm dedicated IPs, and how to use configuration sets and the suppression list to handle bounces and complaints automatically. Get this right and SES is an outstanding deliverability backbone; get it wrong and you will meet the account-review email.
The Shared Responsibility That Trips Everyone
The single most important concept in SES deliverability is that responsibility is split. AWS provides the sending infrastructure, IP pools, and the measurement of your reputation, but you are responsible for what you send and to whom. AWS will not quietly absorb your bad list the way some managed ESPs try to; instead it measures your bounce and complaint rates continuously and takes action when you cross the line. Getting this division wrong (assuming AWS will protect you from your own list) is the number one reason SES accounts get suspended.
In practice, this means the discipline that a full-service ESP might partially handle for you (list verification, suppression, warmup, authentication) is squarely your job on SES. That is not a downside so much as a requirement: SES rewards operational competence with unbeatable economics, and punishes its absence with account reviews.
The Reputation Thresholds AWS Enforces
SES continuously measures your sender reputation and displays it on the Reputation metrics page of the SES console (and via CloudWatch). Two numbers decide your fate:
- Bounce rate. Keep it below 5%. At around 5% your account is reviewed, and sustained rates approaching 10% lead to a sending pause. Since even the SES global suppression list bounces count toward your rate, a dirty list can walk you into trouble fast.
- Complaint rate. Keep it below 0.1%, which is very low. Complaints weigh far more heavily than bounces, so even a small number needs prompt action. On a list of 10,000, roughly 10 complaints per send crosses the recommended line.
These map directly to the broader industry reality: a bounce rate under 2% is healthy and 5% is a genuine emergency, and a complaint rate above 0.1% is dangerous everywhere, not just on SES. SES simply enforces them mechanically at the account level. New in 2026, SES also surfaces inbox placement rates by sending domain and campaign through its Virtual Deliverability Manager, a real upgrade over the old delivery-only visibility, so you can now see spam-versus-inbox placement before and after sending.
The SES global suppression list can bite you silently: AWS maintains a global suppression list of addresses that recently hard-bounced for any SES customer. If you send to an address on it, the API call succeeds but SES treats the message as a hard bounce without attempting delivery, and that bounce counts toward your sending quota and your bounce rate. This means importing a stale list can spike your bounce rate from suppression-list hits alone, before you even reach real invalid addresses. Verify and clean your list before sending, every time.
The Sandbox and Sending Limits
Every new SES account starts in the sandbox, a deliberately restrictive mode: 200 messages per 24 hours, 1 message per second, and, the part that actually blocks most people, you can only send to email addresses and domains you have verified. The sandbox exists so spammers cannot spin up throwaway AWS accounts and blast mail. Getting out requires a short production-access request describing your use case, expected volume, and how you will handle bounces and complaints; approval often comes within a day or two, and a clear, honest request speeds it up.
Once in production, starting limits vary by account and region but commonly begin around 50,000 messages per day and a modest per-second rate, rising as you build a track record. Crucially, limits are scoped per AWS account and per region: production access in one region does nothing for another, and each region has its own sandbox status, quota, and rate. When you consistently approach your limit, request an increase proactively, supplying your historical metrics and forecasts; AWS analyzes your bounce and complaint rates and engagement before granting more, so a clean record is what unlocks scale.
Warming Dedicated IPs
SES offers shared IP pools (AWS manages their warmup and reputation, fine for many senders) and dedicated IPs (recommended once you send substantial volume, often cited around 100,000 per day, or when you need strict reputation isolation for a premium brand or critical mailstream). The warmup rule is the same as anywhere: a new IP with no sending history that suddenly sends 100,000 emails looks like a spam operation, and mailbox providers track IP history.
There are two flavors of dedicated IP on SES. Standard dedicated IPs must be warmed manually, a gradual per-IP ramp over roughly 4 to 8 weeks that you plan and execute yourself, increasing volume in steps. Managed dedicated IPs handle warmup automatically, adjusting how traffic splits between the new IPs and shared pools as reputation builds, which removes most of the manual burden. Whichever you choose, warm gradually (a typical ramp might move from a few thousand a day to tens of thousands over weeks), start with your most engaged recipients, and never shock a fresh IP with full volume. For the full mechanics, see our IP warmup guidance and the broader deliverability practices.
Configuration Sets and Automated Feedback Handling
Two SES features do the heavy lifting of keeping your reputation clean, and using them well is what separates a stable SES setup from a fragile one.
Separate your mailstreams with configuration sets
A configuration set is a group of rules you apply to your sends. The most important practice is to use separate configuration sets for different mailstreams, at minimum one for marketing and one for transactional. The reason is diagnostic and protective: marketing bounces and complaints should not pollute the account-wide rate AWS uses to judge you, and separating streams lets you see exactly which type of mail is driving a problem when your bounce rate climbs. The most common SES mistake is running everything through one configuration set, which leaves you blind to the source of trouble until AWS puts the account under review.
Automate bounce and complaint handling
The modern pattern is to attach event destinations to your configuration sets that publish bounce and complaint events to an SNS topic, then process those events (commonly with a small Lambda function) to automatically suppress the offending addresses. Treat every complaint like a hard bounce: immediately stop all mail to that address and add it to both the SES suppression list and your own subscriber database. Because complaints weigh so heavily, this automation is not optional at scale, it is what keeps you under the thresholds. Combine it with proper authentication (verify your domain, enable DKIM signing, align SPF and publish DMARC) and pre-send verification to keep bounces low from the start.
Before you send a single production email on SES, wire up bounce and complaint handling and verify your list, do not treat these as things to add later once you have volume. The accounts that get paused are almost always the ones that started sending first and planned to handle feedback afterward, then imported a stale list and crossed the bounce threshold on the first big send, partly from global-suppression-list hits they did not know about. Set up configuration sets, SNS event notifications, automatic suppression, and a verified clean list on day one. On SES the cleanup infrastructure is not a nice-to-have; it is the thing standing between you and an account review.
The Bottom Line
Amazon SES gives you world-class sending infrastructure at a fraction of a traditional ESP's cost, but it charges for that in responsibility rather than dollars. The senders who thrive on SES treat it as what it is: a powerful engine that measures their reputation mechanically and pauses accounts that cross clear lines. Keep your bounce rate under 5% and complaints under 0.1%, exit the sandbox with an honest production request, warm dedicated IPs gradually, separate your mailstreams with configuration sets, and automate suppression through SNS from day one. Do all that, fold it into a disciplined deliverability practice with clean lists and full authentication, and SES becomes exactly what it promises: cheap, reliable, high-deliverability email at any scale.
Frequently Asked Questions
Almost always because your bounce or complaint rate crossed an AWS threshold and your account was placed under review or enforcement. AWS recommends keeping bounces under 5% and complaints under 0.1%; at roughly those levels your account is reviewed, and sustained rates near 10% bounce or 0.5% complaint can trigger a pause. Fix the root cause, clean your list, stop mailing suppressed addresses, and authenticate your domain, then reply to the AWS review with your specific remediation steps.
Every new account starts in the sandbox at 200 messages per 24 hours, 1 message per second, and can only send to verified addresses. After you request and receive production access, starting limits vary by account and region but commonly begin around 50,000 messages per day, rising as you build a clean track record. Limits are scoped per AWS account and per region, so production access in one region does not apply to another. Check your SES account dashboard for your actual current values.
Submit a production-access request from the SES console describing your use case, your expected sending volume, and how you will handle bounces and complaints. The sandbox limits you to 200 messages per day and verified recipients only, so leaving it is required before real sending. Approval often comes within a day or two, and a specific, honest request, with a clear bounce and complaint handling plan, is the fastest route. Vague requests get delayed or rejected.
Not for most senders. Shared IP pools, whose warmup and reputation AWS manages, work well at low to moderate volume. A dedicated IP makes sense once you send substantial volume (often cited around 100,000 per day) or need strict reputation isolation for a premium brand or critical mailstream. If you take a standard dedicated IP you must warm it manually over roughly 4 to 8 weeks; managed dedicated IPs warm automatically. A new dedicated IP sending large volume cold will hurt your deliverability.
Configuration sets are groups of rules you apply to your sends, and their most important use is separating mailstreams, at minimum one set for marketing and one for transactional. This keeps marketing bounces and complaints from polluting the account-wide rate AWS uses to judge you, and lets you see which mail type is driving a problem. Attach event destinations that publish bounce and complaint events to an SNS topic so you can automatically suppress bad addresses. Running everything through one configuration set is the most common SES mistake.