AWS SES publishes two thresholds. Above a 5% bounce rate your account is placed under review. Above 10% sending can be paused entirely. Complaint rate has its own pair, 0.1% and 0.5%. These are measured as a rolling average across the whole account, not per domain, and that last detail is the one that catches people.

Account-wide means account-wide

If you have seven verified domains on one SES account, they share a single reputation. One domain sending to a stale list drags the other six down with it. There is no per-domain quarantine and no way to ringfence a bad sender after the fact. The blast radius of a reputation problem is every address you have ever verified on that account.

This is the single most important thing to understand before you let anyone else send under your infrastructure. If you run a shared sending domain for customers, or a free tier, or a demo, you have pooled every one of those senders' reputations into one number.

A high bounce rate is usually not a list hygiene problem

The instinct when the review email lands is to go clean your list. Sometimes that is right. Often it is not, and the distinction matters because cleaning a list you already own does nothing about traffic that has not been sent yet.

Bounce rate is a ratio. It goes up when bad sends increase, and it also goes up when good sends stop. The three causes worth checking, in order:

  • Someone is sending to scraped addresses. Purchased and scraped lists bounce at rates well north of 20%. If a portion of your traffic is coming from a free tier or a shared domain, check who is sending before you check what.
  • You are not honouring your own bounce feedback. If a hard-bounced address can be mailed again next week, every send after the first one is a guaranteed bounce that you generated yourself.
  • Your good traffic dropped. A seasonal lull in legitimate volume raises the ratio without a single new bad address.

What to do in the first hour

Stop the bleeding before you write the appeal. In order:

  1. Find the sending addresses, not the subjects. Subject-line heuristics fall apart the moment the content is not in English. The from address is the reliable signal and it is the one an abuser has to reuse.
  2. Enforce suppression at send time. Not in a dashboard, in the code path every send funnels through. See recording a bounce is not the same as honouring it.
  3. Turn on per-domain attribution. SES Virtual Deliverability Manager and configuration set event destinations are things you have to enable before you need them. If they are off during the incident, AWS holds no per-domain breakdown for that period and you cannot tell from their side which domain caused it.
  4. Pause the traffic you cannot explain rather than the traffic you can.

The appeal

AWS wants three things: what happened, what you changed, and why it will not recur. Specific beats apologetic. "We identified 307 accounts sending to scraped lists, suspended them, and now enforce bounce suppression in the send path with a per-account age-based ramp" is an appeal. "We take deliverability seriously and have cleaned our list" is not.

Getting the ratio back down

The rate is a rolling average, so it recovers in two ways: bad sends stop, and good sends accumulate. You cannot delete history. Send your most reliable traffic, the transactional mail going to addresses that have engaged recently, and let volume do the rest. Do not try to outrun it with more volume, because if any of that new volume bounces you have made it worse.

Expect days, not hours. Plan the appeal around that.