# Suppression list: Definition and How It Works

Source: https://wraps.dev/glossary/suppression-list

InfrastructureSES suppression listaccount-level suppression

The suppression list is SES's account-level record of addresses it will refuse to send to, populated automatically on a hard bounce or a complaint, unless a send explicitly overrides it.

## What actually adds an address to it

SES adds an address automatically for two reasons: a permanent (hard) bounce, or a complaint. It does not add an address for a soft bounce, and it has no visibility into a recipient clicking an unsubscribe link in a message body or a List-Unsubscribe header — those are opt-outs a sender's own list-management system has to track and honor separately, entirely outside SES's suppression mechanism.

## It's account-wide, not per-configuration-set or per-campaign

Once an address is suppressed, it's suppressed for every send from that account, regardless of which configuration set, template, or campaign the next attempt comes from. There's no per-list or per-segment suppression scoping inside SES itself — that granularity, if you need it, is something a sender builds in their own application layer on top of SES's account-wide list.

## It can be overridden, deliberately and per-send

SES allows overriding suppression on a specific send when there's a genuine reason to believe the original suppression no longer applies — a customer confirms their address was fixed after a typo caused the original bounce, for example. This is meant to be a deliberate, occasional override, not a default setting, since routinely overriding suppression defeats the entire protection it provides against bounce and complaint rate.

## This is the part self-hosted mail servers have to build themselves

Running your own SMTP infrastructure means building bounce and complaint parsing, a suppression data store, and enforcement logic that checks it before every send — all from scratch. SES's suppression list is exactly that stack, built in, which is a meaningful part of why bounce and complaint-rate management is materially less work on SES than on self-hosted infrastructure.

## Why it matters

The suppression list is the single mechanism doing the most quiet, ongoing work to keep an SES account's bounce and complaint rates under AWS's review and pause thresholds — every hard bounce and complaint it catches is one less repeat offense against those same accounts, automatically, without a sender having to remember to act on it.

## How to check it

```
aws sesv2 list-suppressed-destinations
```

## Common questions

### Does a soft bounce add an address to the suppression list?

No, only a hard (permanent) bounce or a complaint does. A soft bounce is treated as temporary and retryable, which is exactly the distinction that keeps it out of a mechanism meant for permanent failures.

### Does List-Unsubscribe or an in-message unsubscribe link feed into SES's suppression list?

No. SES's suppression list only reflects bounces and complaints. An unsubscribe click, whichever mechanism triggers it, has to be tracked and honored by the sender's own list-management system — SES has no visibility into it at all.

### Can I send to a suppressed address anyway?

Yes, SES allows an explicit override on a specific send when there's a real reason to believe the original suppression no longer applies, but it's meant as a deliberate, occasional action, not a routine default.