Skip to content
YourMail

Deliverability guide

AWS SES bounce rate: thresholds and recovery

Why use this

SES measures the proportion of your sends that bounce or generate complaints, and acts on it. Crossing a threshold puts the account under review; staying there pauses sending entirely. Recovery is a conversation with AWS, not a setting you can change.

For example

You test your integration by sending to twenty made-up addresses. Every one hard bounces, your account's bounce rate goes to 100%, and AWS places you under review before you have sent a single real email.

The thresholds

AWS publishes two rates and two levels for each. For bounces, 5% puts the account under review and 10% risks a pause. For complaints, the figures are 0.1% and 0.5%. Complaints are an order of magnitude less forgiving, because a complaint means the mail arrived and was unwanted.

Two properties of the measurement matter more than the numbers. It is a rolling rate over recent sending volume, so a small number of bounces on a low-volume account produces a much worse rate than the same bounces on a busy one. And it is measured at the account level, so every application sending from that AWS account shares one score.

Note also that the receiving providers keep their own thresholds independently — Gmail and Yahoo publish a 0.3% spam complaint rate for bulk senders, which bites well before SES notices. Meeting SES's bar is necessary, not sufficient; see the bulk sender requirements.

Under review, and paused

Under review means sending continues while AWS watches. It is a warning with a clock on it, and the right response is to fix the cause immediately rather than to wait and see.

Paused means sending stops. There is no self-serve recovery: you request a review, explain what caused it and what you changed, and wait. In the meantime none of your applications on that account can send — which for most products means password resets and verification codes stop, so an email problem becomes a login outage.

aws sesv2 get-account --region eu-west-2 \
  --query '{Enforcement:EnforcementStatus,Sending:SendingEnabled}'

EnforcementStatus of HEALTHY is the good case. Anything else, plus SendingEnabled: false, tells you which of the two situations you are in.

Test with the simulator, not with made-up addresses

This is the single most useful thing on this page. SES hosts addresses that produce a given outcome on demand, and mail to them does not count towards your bounce or complaint rate.

success@simulator.amazonses.com     // delivers
bounce@simulator.amazonses.com      // hard bounce, does NOT count against you
complaint@simulator.amazonses.com   // complaint, does NOT count against you

Use these to exercise your bounce handling, your webhook subscriber and your suppression logic as often as you like. Inventing addresses at a domain you do not own does the same thing to your code and quietly damages the account while it does it.

Fixing the underlying cause

A high bounce rate has a small number of causes and they are rarely mysterious. You are sending to addresses collected long ago and never re-validated. You have no suppression list, so every dead address is retried on every campaign. You have no double opt-in, so typos in signup forms become permanent bounces. Or you imported a list you did not collect yourself, which is the one case where the answer is to stop rather than to fix.

Complaints have a different shape: the mail is arriving and people do not want it. Sending too often, sending something other than what people signed up for, or making the unsubscribe hard enough that the spam button is easier. Adding one-click unsubscribe converts complaints into unsubscribes, which is the cheapest available improvement to a complaint rate.

If you send through YourMail

The SES account is ours, so the account-level enforcement above is our problem rather than yours — but that is exactly why sending here is graded per account before it can reach that point. Bounce and complaint rates are measured over a rolling window per sender; a degrading rate emails you on the transition, and a critical one refuses sends with a 403 rather than letting one sender damage an identity everyone shares.

Hard bounces and complaints also suppress automatically, so the most common cause of a bad rate — re-sending to known-dead addresses — cannot happen by default. The mechanics are in the bounce and suppression guide.

AWS updates its published thresholds and enforcement behaviour. Check the SES documentation before relying on a specific figure for a compliance or architecture decision.