Amazon SES Bounce Rate Too High: The Fast-Recovery Playbook

If your Amazon SES bounce rate just crossed 4%, stop sending now. AWS automatically places accounts under review at 5% hard bounce rate and may pause sending entirely at 10%, per the SES reputation dashboard documentation. The rate is calculated over a rolling representative volume, so the longer you wait, the deeper the hole gets. Here is the fastest path back.

First: stop the bleeding

The instinct to "send carefully" or "throttle down" is wrong. AWS calculates bounce rate as a percentage over a representative volume of recent email, so every additional send to a bad address makes the numerator worse before any throttled volume can help the denominator. Pause everything, then triage.

Concretely, within the next 15 minutes:

• Pause every active campaign and automation in your sending tool.
• Disable any sign-up or transactional sends that could touch unverified addresses (welcome emails, password resets to new users).
• If you use Configuration Sets, set the sending status to disabled on the affected one rather than tearing down the whole account.
• Do not send any "we are pausing for maintenance" announcement. Sending more email to the same list is what got you here.

You are not back online until you know the source. Sending while you investigate gambles your AWS account on guesses.

Identify the source: bounce report walkthrough

Before you fix anything, you need a list of what bounced and when. AWS does not store a downloadable bounce log in the console - you have to read it from SNS notifications, a Configuration Set event destination (CloudWatch, Kinesis Firehose, or SNS), or GetSendStatistics. Pull the last 30 days and slice by source, list, and segment.

The fastest triage path:

1. Open the SES reputation metrics page and read the current bounce rate and status (Healthy, Under review, Sending paused).
2. Open CloudWatch or your event destination for the last 72 hours and group bounce events by Source (the From address) and by configuration set.
3. For each high-bounce source, pull the recipient list and timestamp the spike. A spike that starts within minutes of a single API call points at one bad import or one bad automation.
4. Tag every bounce as a hard bounce (bounceType: Permanent) or soft bounce (bounceType: Transient). Only Permanent bounces count toward the AWS threshold - if your spike is all Transient, the threshold pressure is lower than it looks, but you still have a deliverability problem.

You are looking for one of three root causes. They each have different fixes.

Three categories of cause

Almost every SES bounce-rate emergency traces back to one of three root causes, in roughly this order of frequency. Identify yours before you start fixing, because the wrong fix wastes review-period time you do not have.

Root cause	Tell-tale signal	Where the fix lives
Bad list	Bounce spike correlates with a CSV import, scraped list, or a re-engagement send to a dormant segment	Subscriber list and import process
Authentication gap	Bounces are spread across multiple lists; many bounces carry SMTP 550 or 5.7.x DMARC/SPF rejection messages	DNS records: SPF, DKIM, DMARC
Sending pattern	Sudden volume ramp from a previously low-volume account, or transactional traffic mixed with marketing on the same identity	Sending architecture and warm-up

If you cannot tell which one applies, assume bad list - it is the most common, and the fix overlaps with the other two anyway.

List quality fixes (do these first)

A bad list is the most common trigger for SES bounce-rate incidents, and AWS will not credit any list change to your bounce calculation until you reply to the support case with what changed (AWS, Reputation metrics messages). Suppress before you re-send. Do not try to "clean" by re-sending to the suspect addresses with a validator in the loop - every send to a dead address still counts toward the 5% threshold.

Run these steps in order:

1. Export every recipient that produced a hard bounce in the last 30 days. Add all of them to your platform's suppression list immediately - SES will continue to attempt delivery if you re-add them via a different list.
2. If a specific CSV import correlates with the spike, suppress the entire import, not just the bounced rows. The bounced rows are the addresses that were syntactically valid but undeliverable; the rest of that file is still suspect.
3. Run the remaining list through an email validation service (NeverBounce, ZeroBounce, Kickbox). Remove anything flagged Invalid or Unknown. Risky and Catch-all are judgment calls - keep them out of your first post-recovery send.
4. If you cannot trace the spike to one import, do a permission pass: send a single confirmation email asking subscribers to re-opt in, and remove anyone who does not respond within 14 days.
5. Disable any single opt-in sign-up form and switch to double opt-in. AWS explicitly recommends this in the SES list-building best practices, and it is the single highest-leverage prevention control.

For the full incident-response checklist on bounce and complaint events, see our SES bounce and complaint handling guide.

Authentication fixes (do these in parallel)

Even if the root cause is a bad list, broken SPF, DKIM, or DMARC amplifies every bounce by pushing mailbox providers from soft-reject to hard-reject. Gmail and Yahoo's 2024 bulk-sender rules now require all three for any domain sending 5,000+ messages per day to their users (Google, Email sender guidelines; Yahoo, Sender best practices). Verify all three records before you resume sending.

Check, in this order:

• SPF: Your sending domain's TXT record must include include:amazonses.com. Verify with dig +short TXT yourdomain.com. Multiple SPF records on the same domain silently break SPF entirely - consolidate into one.
• DKIM: SES Easy DKIM publishes three CNAME records per identity. In the SES console under Verified Identities, every entry should show DKIM status Successful. Pending for more than 72 hours means the CNAMEs are wrong or your DNS provider is stripping them.
• DMARC: Publish at least v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com so you receive aggregate reports. Once you confirm SPF and DKIM align on your real traffic, move to p=quarantine. Sending without a DMARC record at all now causes Gmail and Yahoo to reject bulk mail outright.

A surprising number of SES bounce spikes are actually authentication-driven spam-folder placement cascading into 550 rejections. Fix DNS even if you are sure the list is the problem.

Recovery timeline (what to expect)

AWS does not publish a numeric recovery SLA, but the shape of recovery is predictable. The rate moves down as a function of clean sending volume - because the metric is a percentage over a representative volume, your bounce rate falls as your clean send count grows relative to the now-frozen bounce count. Expect two to four weeks of disciplined sending to clear an Under review status.

Two structural rules during recovery:

• Resume at 30-50% of pre-incident volume for the first week, then ramp back to normal across weeks two and three. A sudden volume snap will be read by AWS as a fresh sending pattern and reset the representative-volume window.
• Send only to engaged segments (opened or clicked in the last 90 days). The point is to push the bounce rate down by inflating the clean-send denominator with mail that has near-zero hard-bounce risk.

When to ask AWS for review removal

If your account is Under review, you do not have to wait passively. AWS explicitly states they will adjust the calculation to only consider bounces received after your documented fix - but only if you tell them. The trigger is replying to the support case AWS opened on your behalf, not opening a new one.

Wait until you can show:

1. A specific root cause identified, with a one-paragraph timeline of what happened.
2. A specific change made (suppression list grew by N addresses, double opt-in enabled on form X, SPF consolidated on date Y).
3. A specific monitoring control added so the same incident cannot repeat silently.

Post that summary as a reply on the support case. AWS reviewers respond faster to incident-response writing than to apologies. If the bounce rate has already dropped below 5% on its own, ask explicitly for the Under review status to be cleared.

If your account is already in Sending paused, the same reply pattern applies, but include details of your plans to ensure that this issue does not occur again - that wording matches AWS's own enforcement FAQ language and signals you read the doc.

Severity-based fix matrix

AWS publishes two hard thresholds and you should treat anything above 2% as a leading indicator (AWS, Reputation metrics messages). The actions below map current bounce rate to the AWS status you will likely see and the move that buys the most recovery time. Pick the row that matches your current rate and start there, not at the top.

Current bounce rate	AWS likely action	Your move
Under 2%	Healthy	Investigate the source anyway. A 1.8% rate trending up is the cheapest fix you will ever make.
2% to 4%	Warning zone	Pause new acquisitions and re-engagement sends. Run validation on the last 30 days of imports.
4% to 5%	Pre-review	Stop all marketing sends. Suppress recent hard-bouncers. Open a proactive case with AWS describing your fix.
5% to 10%	Under review	Full sending pause from your side. Document root cause and reply to the AWS case.
Over 10%	Sending paused	Sending is already off. Reply to the AWS case with the full incident write-up. Do not open a new account.

Preventing the next event

The same incident repeats unless you put controls in place that make the failure mode structurally impossible. The cheap ones, in order of leverage:

• Double opt-in on every sign-up form. This kills typo addresses and listbombing in one move.
• SNS bounce and complaint topics on every Configuration Set. You cannot suppress what you cannot see. Wire bounces to an automation that auto-adds them to your suppression list within minutes.
• A bounce-rate alarm in CloudWatch at 2%, not 5%. Pre-warning matters more than the threshold itself, because AWS's rolling window moves faster than your ops team does.
• A separate SES identity for transactional vs marketing mail. Transactional bounces should never threaten your marketing reputation, and vice versa.
• A pre-send validation step on any import over 500 rows. No exceptions, even for "trusted" lists from sales or partners.
• A monthly hygiene job that suppresses any subscriber with zero opens or clicks in 180 days. Dormant addresses become spamtraps over time.

How Mailblast helps you stay under 2%

If you have hit the bounce-rate threshold more than once, the underlying problem is usually that nobody owns deliverability hygiene as a job. A managed layer on top of SES enforces double opt-in, auto-suppresses bounces via SNS, separates transactional from marketing, and surfaces the bounce rate before AWS does. You still own the SES account and pay AWS directly for sending, so the cost model does not change - you stop running incident response by hand.

Mailblast is a hosted management layer for your own Amazon SES account (BYO-SES). It wires the controls above out of the box and gives you the bounce dashboard AWS does not. For a deeper look at the event plumbing, see the SES bounce and complaint handling guide.

FAQ

What bounce rate gets an Amazon SES account paused? AWS places accounts under review at 5% hard bounce rate and may pause sending at 10%. Only hard bounces - sends to addresses that don't exist - count toward the threshold. Soft bounces, bounces to verified addresses, and inbox simulator sends are excluded from the calculation.

How fast does AWS act when my SES bounce rate spikes? AWS calculates bounce rate over a rolling representative volume, not a fixed window, so action can be hours rather than days for high-volume senders. The reputation dashboard updates the metric throughout the day. A single bad import can push you under review before your next campaign goes out.

How long does it take to recover SES sender reputation after a bounce spike? Most accounts that stop the source and resume clean sending see the metric trend toward healthy within two to four weeks. AWS will only count bounces received after your documented fix if you reply to the support case explaining the change, which can shorten the review period meaningfully.

Will AWS tell me which addresses bounced? AWS does not give you a bounce list in the console. You get bounce events through SNS notifications, the Configuration Set event destination, or the GetSendStatistics API. If you have not wired up an SNS topic for bounces, do that first - you cannot suppress what you cannot see.

Can I just open a new AWS account to escape a sending pause? No. AWS detects related accounts through billing, IAM, and infrastructure signals, and applies a Related Account Notification that paused the original account. Fix the underlying list and authentication issues on the original account and reply to the support case instead.

---

Disclosure: Mailblast is a hosted management layer for your own Amazon SES account. The SES reputation and quota belong to your AWS account; Mailblast wires up the bounce, complaint, and suppression controls that keep accounts off the 5% review threshold.