Amazon SES paused your sendingStop the bleed first, then answer the review with specifics.

AWS sends account health and review notifications to the account's root email address by default, which on most teams is an inbox nobody checks between quarterly billing reviews. The first sign of trouble is often a support ticket asking why campaigns silently stopped sending, not an alert anyone saw in advance. If you have not already, set up an alternate contact and a CloudWatch alarm on your reputation metrics so the next spike reaches a channel someone actually watches.

The underlying cause is almost always a complaint rate crossing AWS's review threshold, sometimes alongside a bounce spike from the same source. AWS documents review territory around 0.1% complaints and 0.5% bounces, with a matching bounce review line around 5% and enforcement risk around 10% (Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026). Staying comfortably under those numbers, not just under the enforcement line, is the safer target.

Do this before you reply to AWS, and before you send anything else from the affected identity. Sending more mail while the cause is still active only adds to the number the reviewer is looking at.

1. Pull complaint and bounce counts per recent campaign, not per account total. The spike almost always traces to one send: a stale segment, a re-engagement blast, or a list import that skipped cleaning.
2. Identify the addresses that generated the complaints or hard bounces specifically, not the whole list they came from.
3. Confirm those addresses are suppressed and cannot be mailed again through any send path, including the transactional API and manual test sends, not just the campaign tool.
4. Prune or pause the segment that produced them until you understand why it was mailed in the first place.

A common failure mode is fixing suppression on the campaign tool that caused the spike while the transactional API or a separate script can still mail the same addresses. AWS's own account-level suppression list catches some of this, but it acts invisibly, after the fact, and does not tell your application anything happened. A suppression list your own systems check before every send, campaigns and API and test sends alike, is what actually stops the number climbing again while the review is open.

Open a reply to the AWS notice, or a new support case referencing it, and state three things plainly: what caused the spike, what you removed or fixed, and what mechanism now prevents a repeat. A remediation reply that names automatic suppression on every send path, one-click unsubscribe on campaigns, and ongoing rate monitoring reads as a real fix. A reply that only apologizes and promises to be more careful does not give the reviewer anything to verify.

AWS decides these case by case, and there is no published fixed timeline. A specific, checkable remediation plan tends to resolve faster than a generic one, in the same way a specific production access request tends to move faster than a vague one.

• Watch bounce and complaint rate against the AWS thresholds continuously, in the SES reputation dashboard or an in-product health view, not only after a notice arrives.
• Suppress hard bounces and complaints automatically the moment SES reports them, enforced on every send path at once.
• Add RFC 8058 one-click unsubscribe to marketing mail so an unhappy recipient has a fast exit that is not a spam-button click.
• Set an alternate AWS account contact so review notices reach an inbox your team actually reads.

None of this promises a pause can never happen again. It removes the mechanical causes that produce most of them: a stale list re-mailed, a complainer contacted twice, and nobody watching the dashboard until AWS writes to the root email.

SendBunny runs in your own AWS account and suppresses hard bounces and complaints automatically on every send path, campaigns, the transactional API, and test sends alike, so a complainer stays suppressed no matter which route someone tries. A health strip shows bounce and complaint rate against SES's limits on every screen, not just in a console page you have to remember to open. It is $199 once. It does not stop AWS from opening a review; it gives you the mechanism to answer one truthfully.