Amazon SES Account Suspended: How to Fix It Fast

Amazon SES pauses sending when your hard-bounce rate hits 10% or your complaint rate hits 0.5%, and places the account under review at 5% bounce or 0.1% complaint (AWS, 2026). Reinstatement is a single channel: sign into the AWS Management Console, open Support Center, and reply to the case AWS opened on your behalf with the root cause, the fixes you put in place, and a list-hygiene plan.

Most SES enforcement actions are mechanical. AWS measures hard-bounce rate and complaint rate against a rolling representative volume and crosses two well-published thresholds. Knowing which threshold tripped tells you which playbook to run.

What status is your account in?

AWS publishes five account statuses in the SES reputation metrics console: Healthy, Under review, Pending end of review decision, Sending paused, and Pending sending pause. Only two require emergency action. Under review means sending continues but AWS is watching a metric. Sending paused means SES will reject every SendEmail call until reinstatement.

Confirm the status in the SES console under Reputation metrics. The page shows an account-level status banner plus separate status badges for Bounce Rate and Complaint Rate. AWS opens a case in Support Center automatically when either status changes - that case is the only channel for reinstatement.

Trigger metric	Under review at	Sending paused at	What counts
Hard bounce rate	5%	10%	Hard bounces only. Soft bounces, verified addresses, verified domains, and inbox simulator are excluded.
Complaint rate	0.1%	0.5%	Spam-button complaints from feedback loops. Inbox simulator complaints excluded.
Anti-spam / blocklist / spamtrap	Discretionary	Discretionary	External reports. AWS does not name the source.
Compromised credentials	Discretionary	Often immediate	Unauthorised sending from leaked IAM or SMTP credentials.

The Under Review playbook

Under review is the warning shot. AWS opens a case in Support Center but sending continues, and the linked metric stays Under review until it drops below the threshold for the full review window. Roughly 60-80% of the work is list hygiene; the rest is documenting what changed so AWS can re-evaluate from a clean baseline.

Run this sequence today:

1. Read the case in Support Center. The case body names the trigger metric (bounce, complaint, anti-spam, spamtrap, blocklist, internal review). Different triggers need different remediation - do not assume bounce until you have read it.
2. Stop the bleed. Pause the campaign or workflow that caused the spike. If you do not know which campaign caused it, pause everything non-transactional for 24 hours while you investigate.
3. Pull bounce and complaint events from your event destination (SNS topic, Kinesis Firehose, or CloudWatch). Filter the last 7-14 days. Group by sending identity, list source, and campaign. The pattern usually points to one bad list, one form without CAPTCHA, or one re-engagement send to dormant addresses.
4. Suppress every hard-bounced address in your account-level suppression list. Suppress every complainer. Never re-mail either group.
5. Reply to the case with the specifics from step 6 below. Once AWS sees credible changes, they often restart the measurement window so old bounces no longer count against you.

If you ignore the case, the review period ends with the metric still above threshold, and AWS escalates to sending paused.

The Sending Paused playbook

Sending paused is harder but not fatal. SES rejects all SendEmail and SendRawEmail calls until reinstatement, so every queued campaign needs to be held by your sender (Mailblast pauses sending automatically when SES returns the paused error). AWS does not publish a guaranteed reinstatement SLA, but most well-documented requests are reviewed within a few business days.

Treat the reply as a single-shot ticket: half-baked answers slow the queue and lower your odds.

1. Do not open a new case. Reply to the existing one. New cases routinely get closed with a pointer back to the original.
2. State the root cause first. One sentence. "Our complaint rate exceeded 0.5% after a re-engagement send to dormant 2024 sign-ups."
3. List the immediate actions taken. Address-level suppressions, paused campaigns, removed list sources, rotated credentials if compromise is in scope.
4. List the durable changes. Double opt-in on the public form, sunsetting after 90 days of no opens, CAPTCHA on the comment form, removed the third-party list.
5. Attach metrics if you have them. "Over the last 72 hours, hard bounce rate on new sends is 0.4%."
6. Commit to monitoring. Name the bounce/complaint event destination and how you will alert on regressions.

If the first reply is denied, AWS will explain what was missing. Re-implement, wait 5-7 days to gather fresh metrics, and reply with the new numbers. In rare cases of repeated infractions, AWS may permanently suspend the account - the Reputation metrics docs state this explicitly for internal review and vulnerable site notifications.

Root cause: what triggered the action

AWS lists more than a dozen distinct trigger categories in the reputation metrics documentation, and your case will name one. The two most common - bounce rate and complaint rate - are mechanical thresholds; the rest are discretionary and depend on external signals like anti-spam organisations, mailbox providers, and spamtrap hits.

• Hard bounce rate at 5% (under review) or 10% (sending paused). Calculated on a representative volume of email - AWS's wording for a rolling per-account baseline. Soft bounces, verified domains, verified addresses, and inbox simulator hits are excluded.
• Complaint rate at 0.1% or 0.5%. Includes spam-button reports from feedback loops at major mailbox providers. Inbox simulator excluded.
• Anti-spam organisation, mailbox provider, recipient feedback, listbombing, spamtrap, domain blocklist notifications. AWS does not name the reporting organisation. The fix is structural: double opt-in, list cleanup, CAPTCHA, dormant-recipient sunsetting.
• Internal review or vulnerable site. A human or automated AWS review flagged content or a third-party abuse pattern (contact-us form, email-a-friend). Patch the form, then reply.
• Compromised credentials. Rotate IAM access keys and SMTP passwords immediately, audit users and resources, and migrate to short-lived credentials via IAM Identity Center.

Pull your own data before replying. AWS shows aggregate rates in the console but not the underlying events - those live in the event destination you configured. If you did not configure one, set up an SNS event destination before your next send.

How to write the Support Center reply

Reinstatement turns on a single document: your reply to the case. Vague answers get denied; specific ones get a human re-review. Use a fixed five-part structure so the reviewer can verify each claim quickly.

1. Root cause (one sentence, names the metric and the source).
2. What we stopped (campaigns paused, lists removed, credentials rotated).
3. What we changed (double opt-in on /signup, sunset at 90 days, suppression
   list synced from event destination, CAPTCHA added to /contact).
4. Current numbers (hard bounce rate or complaint rate over the last
   72-168 hours, with exact percentages from the SES console).
5. Monitoring (event destination, who is paged, threshold for re-pause).

Three rules:

• Be specific about acquisition. AWS rejects replies that handwave around how addresses are collected. "We collect via a double opt-in form at example.com/signup with confirmation email" is acceptable; "we have a sign-up form" is not.
• Do not blame recipients. Statements like "our users mark legitimate mail as spam" tell the reviewer you do not understand the problem. Even when partially true, frame it as a content or expectation gap you are fixing.
• Do not promise the metric will be zero. AWS's published guidance is to maintain bounce rate below 5% and complaint rate below 0.1%. Aiming below those is the right target.

If you went from sandbox to production recently, AWS may still be calibrating your representative volume - one bad send during low volume disproportionately moves the rate. The SES sandbox-to-production guide covers how AWS evaluates production access requests; the same volume-awareness applies to enforcement.

After reinstatement: preventing the next event

Reinstatement is provisional. AWS notes in the reputation metrics docs that if the same issue recurs after a sending pause is lifted, the account can be paused again - and repeated infractions can result in a permanent suspension. Treat the first 30 days post-reinstatement as a probation period and instrument accordingly.

Five durable controls that close most enforcement loops:

1. Suppression on every event. Hard bounce, complaint, and spamtrap events should write to your account-level suppression list within seconds. If you are running raw SES, wire SNS to a Lambda that calls PutSuppressedDestination.
2. Double opt-in with confirmation. Every public sign-up form sends a confirmation email; the address is only marked active after the click. This single change kills listbombing, spamtraps, and most complaint spikes.
3. Engagement sunset. Drop addresses that have not opened in 90-180 days from broadcast lists. Keep them for transactional sends if relevant. AWS calls this out by name in the bounce, complaint, recipient feedback, and spamtrap remediation sections.
4. Per-campaign reputation review. Before any broadcast over 10k recipients, check the previous campaign's bounce and complaint rates. If either is climbing, pause and clean.
5. CAPTCHA and rate-limiting on every public form. Sign-up, contact, email-a-friend, comment - anything that triggers an SES send. AWS lists vulnerable site as its own enforcement category.

The deeper how-to for bounce and complaint handling lives in our bounce and complaint handling guide - including SNS topic configuration, suppression list syncing, and the deliverability KPIs we recommend tracking.

When to consider moving off raw SES management

Raw SES gives you the lowest-cost sending pipe in the market, but it pushes every reputation control onto you - event destinations, suppression lists, hygiene workflows, and the AWS reply itself. Most account-paused incidents trace back to one missing piece in that stack rather than the SES infrastructure.

A managed layer on top of your own SES account closes those gaps without changing the underlying pricing. Mailblast is a hosted management layer that sends through your AWS SES credentials, so you keep SES's per-message economics and own the AWS account, while suppression, bounce and complaint handling, double opt-in, and per-link engagement metrics are wired in by default. If your reinstatement reply is going to commit to all of those controls anyway, running them through a hosted platform is faster than building each one.

FAQ

How long does an SES account stay under review?

AWS does not publish a fixed duration. Review periods typically run for a few weeks, and AWS may extend the window if you submit changes mid-review so the new data is evaluated cleanly. The status ends when your metric drops below the threshold for the full review window.

Will Amazon SES tell me which addresses caused the bounces or complaints?

AWS publishes hard bounces and complaints to your configured SNS topic or event destination, but it will not name spamtrap addresses, blocklisted domains, or the mailbox providers that reported you. Pull bounce and complaint events from your own logs and reconcile them against recent campaigns.

Can I keep sending while my SES account is under review?

Yes. Under review means AWS is watching the metric, not that sending is blocked. Use the time to clean lists, fix list-hygiene gaps, and reply to the support case. Sending only stops at the sending paused state, which kicks in at 10% hard bounce or 0.5% complaint.

Does Amazon SES count soft bounces toward the bounce rate?

No. AWS only counts hard bounces toward the bounce-rate threshold. Soft bounces (full mailbox, temporary deferrals) are excluded, as are bounces from emails sent to verified addresses, verified domains, and the SES inbox simulator. Track hard-bounce rate as a separate metric from your delivery dashboards.

What if AWS denies my reinstatement request?

AWS will explain what is still missing in the case reply. Common reasons are vague answers, no list-hygiene plan, or the metric still trending above threshold. Re-implement, gather fresh proof (lower bounce rate over the last 7 days), and reply again with specifics. There is no separate appeal queue.

---

Disclosure: Mailblast is a hosted management layer for your own Amazon SES account. The AWS reputation thresholds and the support case workflow described above belong to AWS; Mailblast handles the operational controls (suppression, bounce and complaint handling, double opt-in) that AWS reviewers want to see in your reinstatement reply.