An Amazon SES account goes under review when AWS detects a problem with the email you send and gives you time to fix it. The most common triggers are a bounce rate of 5% or more or a complaint rate of 0.1% or more. You can still send while under review, but if the problem isn't fixed by the end of the review period, AWS may pause your account's sending, and it may pause at 10% bounces or 0.5% complaints. To recover, find the source, fix it, and reply to AWS's support case with what you've already changed.
This guide is based on AWS's sending review FAQ and reputation metrics documentation, checked in October 2026. Thresholds and process can change, so confirm on those pages.
Under review vs sending paused
These are two different states:
- Under review: AWS has found an issue and is giving you time to correct it. You can keep sending. AWS emails the address on your AWS account (which may not be the address you send from) and opens a case in the AWS Support Center.
- Sending paused: you can't send email through SES at all until AWS reviews your changes and lifts the pause.
A pause usually follows an unresolved review, but not always. AWS may pause sending without a review first if the problem is very serious, if your mail violates the AWS Service Terms, or if your account has been under review for the same issue several times before. That last point matters: if one campaign caused the review, stopping that campaign isn't enough. AWS expects you to fix whatever process produced it.
The review is about SES, but it can touch other services: AWS says it may deny quota increases for other AWS services that send outbound messages, such as Amazon SNS, until the review is lifted.
What triggers an SES review?
Bounce and complaint thresholds
As of October 2026, AWS publishes these thresholds:
| Metric | AWS recommends | Under review at | Sending may be paused at |
|---|---|---|---|
| Bounce rate | Below 2% | 5% or more | 10% or more |
| Complaint rate | Below 0.1% | 0.1% or more | 0.5% or more |
Some details that change how you read your own numbers:
- Only hard bounces count, and only to domains you haven't verified. "Address does not exist" counts; "mailbox full" and bounces caused by a blocked IP don't.
- Complaints only come from feedback loops. The complaint rate counts complaints from mailbox providers that send feedback to SES. Gmail doesn't send complaint data to SES, so a Gmail user clicking "Report spam" won't show up in your SES complaint rate, but Gmail still counts it against you. Gmail and Yahoo require bulk senders to stay under 0.3%, ideally under 0.1%; see our Gmail and Yahoo bulk sender guide.
- There's no fixed time window. AWS calculates both rates over a "representative volume", an amount of mail that reflects your typical sending, which differs per account and changes as your sending changes. For that reason AWS says you can't reproduce its exact figure from the console or
GetSendStatistics, though watching those numbers still gives you early warning.
Other triggers
Bounces and complaints are the visible ones, but the reputation metrics page lists other notifications that can lead to a review or a pause:
- Spamtraps: addresses that should never receive mail, often old addresses that have bounced for a long time, or typo domains. Even a few hits hurt, and AWS doesn't say how many trigger action.
- Direct and mailbox provider feedback: recipients complaining to SES directly, or a mailbox provider reporting your mail outside the usual feedback loop. These don't appear in your complaint rate.
- Anti-spam organization, domain blocklist and internal review findings: content or links flagged as unsolicited, or links to domains on a blocklist such as Spamhaus's domain list.
- Listbombing and vulnerable sites: a signup, contact or "email a friend" form abused by bots to send mail you didn't intend.
- Compromised credentials: leaked SMTP passwords or IAM access keys used to send spam from your account.
- Manual investigation: an SES investigator found unsolicited mail, phishing (including simulated phishing) or another unsupported use case.
How to check your account status
Open the SES console and choose Reputation metrics. AWS says this page shows the same information its team uses to judge an account's health. The account status is one of:
| Status | Meaning |
|---|---|
| Healthy | No current issues |
| Under review | Fix the issue before the review period ends, or sending may be paused |
| Pending end of review decision | Under review; AWS will review manually before acting |
| Pending sending pause | Issue not resolved; AWS typically pauses, but will review first |
| Sending paused | You can't send until AWS lifts the pause |
The bounce and complaint sections have their own status too. Almost healed means the metric caused the review but has stayed below the maximum since it began, and will turn healthy if it stays there.
To watch this from code, call GetAccount in the SES v2 API and read EnforcementStatus. SES emits no EventBridge event when it pauses or reinstates a whole account, so you have to poll. Don't use GetAccountSendingEnabled for this: that flag only reflects whether you turned sending off yourself. AWS also records pauses as an "SES sending paused" event in the AWS Health Dashboard.
A step-by-step recovery plan
AWS will typically give you only a high-level summary, such as "a problem with bounces." It can't give you a full list of the addresses that bounced or complained. The diagnosis is yours.
1. Stop the bleeding
If you can, stop the mail that's causing the problem. AWS recommends stopping all sending until it's fixed, because continuing can make it worse. If you can't stop everything, pause marketing and bulk sends and keep only transactional mail like receipts and password resets.
2. Find the source
Read AWS's notification for the category (bounces, complaints, spamtraps, and so on), then narrow it down with your own data:
- Which send, list segment or campaign started it? Compare dates against your bounce and complaint events.
- Was it an old list, an import, or a newly launched signup form?
- Did a form get hit by bots? A sudden rise in signups from odd domains is a sign.
- If you can't explain mail you see going out, assume compromised credentials: rotate SMTP passwords and access keys now.
This is where your event pipeline pays off. AWS only shows aggregate numbers; if you've published bounce and complaint events to SNS or another destination and stored them with the SES message ID, you can trace each one back to a send. AWS notes that some providers redact the recipient address in complaints, so keeping your own mapping from message ID to recipient is the only reliable way to find who complained.
3. Clean the list
Remove every address that hard bounced or complained, and don't send a "sorry to see you go" email to people who complained. Then deal with the rest of the risky data: imported or old addresses you haven't mailed recently. AWS's advice is that if you must mail addresses you haven't contacted lately, do so only as a small portion of your overall sending. If the list was bought, rented or shared, stop using it entirely; AWS prohibits sending to it.
4. Make sure suppression is on
Accounts created after 25 November 2019 use the SES account-level suppression list by default for hard bounces and complaints, per Region. Check it's enabled in every Region you send from, and also mark the addresses as unmailable in your own database, so a different system or a re-import doesn't bring them back.
5. Fix how addresses get in
Most bounce and complaint problems start at signup. AWS's recommendations:
- Double opt-in: send a confirmation email and only mail people who click it.
- Ask for the address twice on web forms and check they match.
- Protect forms with a CAPTCHA, and don't let "email a friend" features accept arbitrary content.
- Don't reward fake addresses: hold any signup benefit until the address is confirmed.
- Be clear about what people signed up for, and send only that.
- Make unsubscribing obvious and easy. For bulk marketing to Gmail and Yahoo, add one-click unsubscribe (RFC 8058).
6. Sunset unengaged recipients
Stop mailing people who haven't opened or clicked in a long time. AWS suggests considering removal if users haven't engaged in several months, unless you have evidence they still want your mail. Be careful with re-engagement campaigns: AWS calls them highly risky. And don't send a permission pass to the whole list if you think it contains many bad addresses, because it can push the bounce rate up further.
7. Reply to the support case
Sign in to the AWS Support Center and reply to the case AWS opened. Include:
- The root cause of the problem.
- The changes you've already implemented. AWS is explicit that planned changes don't count.
- How those changes stop it happening again.
- For bounces: how you track bounces and how you check new addresses are valid.
- For unsolicited mail: how you acquired the list, and how your subscribe and unsubscribe processes work, with the links.
If AWS accepts your changes, it adjusts its calculations to count only bounces or complaints received after them. For spamtrap issues, AWS says it can take three weeks or more to tell whether your changes worked. For direct or mailbox provider complaints, AWS says that if you don't request a review within three weeks and complaints continue, it may pause sending. If your request isn't accepted, AWS explains why, and in some cases you can submit another once you can show the issue is fixed.
8. Monitor from now on
Set CloudWatch alarms on the bounce and complaint rate metrics well below AWS's thresholds, for example at 2% and 0.05%. Poll EnforcementStatus. Make sure the email address on your AWS account is one someone reads. Our guide to why emails go to spam covers the other signals worth watching.
How to avoid an SES review in the first place
- Keep hard bounces under 2% and complaints under 0.1%, the levels AWS recommends.
- Send only to people who asked for your mail. AWS's production access process asks you to confirm this before you leave the sandbox.
- Process bounce and complaint events automatically from day one, not after the first warning.
- Ramp up new lists, domains and IPs gradually. Our IP warm-up guide explains why sudden volume looks suspicious.
- Treat any form that triggers an email as an attack surface.
When moving providers helps, and when it doesn't
It's tempting to respond to a review by moving to another provider. Be honest with yourself about the cause first.
It doesn't help if the problem is your list. Bounces and complaints come from who you send to, not from SES. Every reputable provider watches them and acts on them, and a list that bounces at 8% on SES will bounce at 8% anywhere. Some providers act sooner than SES does. Moving mid-review to escape it usually just moves the problem.
On our own platform, for example, the limits are tighter than SES's pause levels: sending pauses automatically if hard bounces pass 5% or complaints pass 0.3% over 24 hours (minimum 100 recipients), with warnings at 3% and 0.1%. During warm-up, the daily limit only rises after a clean day (hard bounces under 2%, complaints under 0.1%) and holds after a bad one. We also review every account's website, domain and list source before it can send, and we don't take bought lists or cold outreach. A list that triggered an SES review would most likely pause on ours too.
It can help if the problem is the tooling around SES. SES gives you the building blocks, including suppression by default, but you wire up event handling, searchable logs, alerts, your own pause logic, and blocklist and DNS monitoring. If your review happened because nobody noticed bounces climbing, a provider with those guardrails built in may suit you better. The trade-offs, including where SES is cheaper, are on our Amazon SES alternative page, and our Amazon SES pricing explainer has SES's costs as of October 2026.
If you've fixed the list and want sending with monitoring, auto-suppression and automatic pauses included, see pricing: pay as you go at $0.20 per 1,000 emails with a $10 monthly minimum that includes 50,000, in early access.