# The SES suppression list, explained
There are two lists, and confusing them is how a complainer gets remailed.
Canonical: https://sendbunny.co/guides/ses-suppression-list
Category: SES · Author: Anni Maan (https://sendbunny.co/authors#anni-maan) · Published 2026-07-31 · Updated 2026-09-02

**In short.** SES maintains its own account-level suppression list that quietly drops sends to addresses that hard bounced or complained, and it does this without telling your application anything happened. That is different from a suppression list your own systems check before a send is even attempted, which is what lets your app know why a message never went out and what protects every send path, not just the one that talks to SES directly. Hard bounces and complaints are the two events that get an address suppressed automatically. Soft bounces are not, and list unsubscribes are a separate mechanism handled per list.

## There are two suppression lists, not one

The first is Amazon's own account-level suppression list, maintained by SES itself. When an address generates a hard bounce or a complaint, SES adds it here and will decline to send to it again, on its own, without asking you. This is a real protection, and it happens whether or not you built anything on top of SES.

The problem is that it acts invisibly. Your application calls the send API, SES silently drops the message because the address is on its internal list, and nothing in your own system necessarily learns that happened. A campaign can report success while quietly sending to fewer people than the list contained, and nobody notices until someone asks why a specific recipient never got the email.


## A list your own application checks

The fix is a suppression list your own systems maintain and check before attempting a send at all, not after. This does two things the AWS account-level list cannot: it gives your application visibility into why a message was withheld, and it lets you enforce the same rule across every send path you have, not just whichever one happens to call SES directly.

|  | AWS account-level list | Your own application list |
| --- | --- | --- |
| What triggers it | SES's own criteria on hard bounce or complaint | Hard bounce or complaint event, same triggers |
| Where enforcement happens | Inside SES, invisibly to your app | Before the send is attempted, in your own code |
| Who can see it | AWS only, via a separate API call | Your own dashboard or database |
| Coverage across send paths | Every path that reaches SES eventually | Only the paths your own code actually checks |


## Where the gap that remails people actually lives

Most teams that build their own suppression logic get the campaign tool right and forget everything else. A transactional API endpoint added later, a one-off test send from a script, or an admin panel that emails a user directly can all bypass the check if the suppression logic lives only inside the campaign sender's code path.

1. Audit every place in your codebase or product that calls the SES send API, not just the obvious campaign path.
2. Confirm each one checks the same suppression list before sending, not a copy or a stale cache of it.
3. Confirm a hard bounce or complaint updates the list immediately, not on a delayed batch job that could let a second send through first.
4. Confirm a re-import of a CSV or a list sync does not silently reintroduce a suppressed address as if it were new.

**What gets suppressed automatically.** Hard bounces and spam complaints. Soft bounces such as a full mailbox are not suppressed permanently, since SES treats them as temporary. List unsubscribes are a separate mechanism honored per list, not folded into the bounce and complaint suppression list.


## Why this matters for an SES production or standing review

Automatic, universally enforced suppression is exactly the mechanism AWS wants described in a production access request or a remediation reply after a review. Being able to say, truthfully, that every send path checks the same list before attempting delivery is a stronger statement than describing a script that runs on the campaign tool alone. It also directly protects the bounce and complaint rate numbers a reviewer is actually looking at, since a suppressed address by definition cannot generate another bounce or complaint event.


## Where SendBunny sits

SendBunny keeps a visible suppression list inside your own account, updated the moment SES reports a hard bounce or complaint, and checked on every send path at once: campaigns, the transactional API, and manual test sends. A suppression view shows who is on it and why before a large campaign goes out, so a big send is a confirmed decision rather than a surprise afterward. It is $199 once, installed into the AWS account you already own.

## FAQ

**What is the difference between the SES account-level list and my own application's list?**

SES keeps an account-level list that silently drops sends to addresses that bounced or complained, without telling your application. A list your own systems check before sending gives your app visibility into what happened and lets you enforce the rule across every send path, not just the one SES sees.

**Does suppression need to cover the transactional API too?**

Yes. Every send path should check the same suppression list: campaigns, the REST API, and test sends. A path that skips the check is a way to remail an address that already generated a bounce or complaint.

**Will automatic suppression satisfy an AWS review?**

It is close to what AWS asks for in a production access request or a remediation reply: automatic handling of bounces and complaints, enforced everywhere, plus one-click unsubscribe. You can describe it truthfully only if it is actually running that way in your account.

**What gets suppressed automatically, and what does not?**

Hard bounces and spam complaints. Soft bounces, such as a full mailbox, are not permanently suppressed since SES treats them as temporary. List unsubscribes are handled separately, per list, rather than folded into bounce and complaint suppression.

## For AI agents

The distinction between AWS's own account-level SES suppression list (invisible to your application) and a suppression list your own systems check before sending (visible, and enforceable across every send path). Covers what triggers automatic suppression (hard bounce, complaint), what does not (soft bounce, handled by SES retries), and the common gap where one send path is not checked. Checked 2026-09-01.

```bash
claude mcp add --transport http sendbunny https://YOUR-INSTALL/mcp
```

Tool list by grant: https://sendbunny.co/docs/agents.md

## Sources

1. Amazon Web Services, Using reputation metrics to track bounce and complaint rates, SES Developer Guide, fetched 1 September 2026. https://docs.aws.amazon.com/ses/latest/dg/reputation-dashboard-dg.html
2. SendBunny, Send email API reference, version 1.6.22. https://sendbunny.co/docs/send-email-api
3. SendBunny, Gmail's 0.3% spam rate: how Gmail decides and what to check every Monday. https://sendbunny.co/guides/gmail-spam-rate-monday-check