SES Paused Account? 7-Day Recovery Playbook
Amazon SES paused your account? A 7-day recovery playbook: list hygiene, bounce-rate math, and how to stop tripping the enforcement tripwire.
Your Amazon SES account is paused. Sending is dead, your newsletter is stuck, and the email from AWS tells you almost nothing useful about why — or exactly what gets it back.
The documented sequence: after a weeks-long pause in sending, the first campaign back spikes bounces past the tripwire, and SES suspends a 5,000-subscriber list that took years to build. Appeal: rejected. No second chance, no negotiation.
Here's the playbook for getting unpaused — and the honest math on when recovery isn't the right move.
Why SES pauses accounts (the real mechanism)
SES doesn't care about your content. It enforces reputation metrics, computed per account over a rolling representative volume of your sending:
- Bounce rate: warnings around 5%, account pause above ~10%.
- Complaint rate: warnings around 0.1%, pause above ~0.5%.
When you exceed them, SES can put your account under review or pause sending outright. The notice gives you a remediation window — in practice, roughly a week to show the metrics back inside bounds.
The trap that catches most people: the metrics are rate-based, not volume-based. A small list makes it brutally easy to cross 10%. Fifty hard bounces on a 400-address send is 12.5%. You don't need to be a spammer. You need a stale list and one send after a pause.
This is exactly the sequence that kills lists: pause in sending → addresses decayed (~20–25% of a list goes bad per year) → first send back → hard bounces pile up → tripwire → pause → appeal denied.
The 7-day recovery playbook
Day 1–2: Stop the bleeding and identify the cause. 1. Pull your bounce and complaint data from the SES reputation dashboard and bounce notifications. Separate hard bounces from soft bounces. Hard bounces are your enemy. 2. Find the cohort that bounced: usually it's the addresses you haven't mailed in 3+ months, imported addresses, or a co-registration/ purchased segment. Name it. 3. Remove every hard-bounced address and every address in the suspect cohort that hasn't engaged in 6+ months. No nostalgia. Dead addresses are liabilities.
Day 3: Clean what's left. 4. Run the remaining list through validation (MX check + syntax + disposable-domain and role-account detection). This is the ListProof self-audit step — a 60-second hygiene pass catches the bounces that are preventable. 5. Implement hard-bounce suppression in your sending setup so bounced addresses are never retried. SES penalizes you for every hard bounce, even ones you didn't mean to send. SNS notifications → automatic suppression list is the standard SES-native wiring.
Day 4–5: Rebuild reputation with a warm segment. 6. Start sending again only to your most engaged slice — opened or clicked in the last 60 days. Low volume, high quality. The goal is a stretch of sends at near-zero bounce rate so the rolling metrics recover. 7. Graduate outward slowly: 90-day engaged, then the full clean list. One bad cohort can undo a week of work.
Day 6–7: Document and respond. 8. Reply to AWS with a concrete remediation statement: what caused the bounces, what you removed, what suppression you implemented, and your bounce/complaint metrics over the last sends. SES reviewers respond to specific process changes, not promises.
If the metrics come back inside bounds, sending resumes. If they don't — or if the appeal was denied — you face the second question honestly.
When to walk away
Recovery is the right move when the problem was hygiene: a stale cohort, a missing suppression list, an import you should have scrubbed first. One cleanup, and you're fine.
Walk away when: - Your appeal was denied and the remediation path is closed. - The problem is structural: your list regularly goes stale between sends, you run a self-hosted stack that keeps forgetting suppression wiring, or your sending pattern (bursty, long pauses) will always flirt with the 10% tripwire. - You're spending more mental energy on not being paused than on writing the newsletter.
A bounce tripwire you don't control is a single point of failure for your whole list business. The documented recovery: rebuilding on rails no one can take you off — self-hosted sending where the bounce handling, suppression, and full list export are yours. No black-box tripwire, no appeal queue, no waiting weeks for a support ticket to decide your income.
That's the same architecture we build for clients in the $2.5k SES rescue package — but the first move, regardless of which road you take, is the hygiene pass above.
The free checklist
Before you reply to AWS — or before you decide to leave — run the list through the ListProof self-audit: MX validation, disposable-domain detection, role-account flags, and the engagement cutoff rules from this playbook. It takes minutes and it's the single highest-leverage step in either outcome.
[Get the free ListProof self-audit checklist →]
Keep Exploring
Use the Workflow Library to browse more guides, comparisons, and integration examples to continue your evaluation.
See the solutions, comparisons, and integration guides collected in one place.
Review grounded audit, compare, fix-plan, and report excerpts before you wire the API into anything.
Jump from the workflow page into the quickstart, endpoint guides, and full OpenAPI reference.
Keep reading
If this one helped, the next two are the natural follow-ups.