What is the Amazon SES account-level suppression list, and what happens when you send to an address that is on it?
answer
- automatic brake on bad addresses
- hard bounces and complaints add entries
- the send succeeds, delivery does not
- one API call ends the investigation
- account list versus AWS-managed global list
basics
~20 sIt is a per-account list of addresses SES refuses to deliver to, populated automatically after a hard bounce or a complaint. A send to a suppressed address is still accepted and returns a message ID, but SES never delivers it and reports a bounce event instead.
solid answer
~40 sThe account-level suppression list is SES's own record of addresses that have hard-bounced or filed a complaint against your account. SES adds them automatically — you choose whether that covers bounces, complaints or both — and then silently declines to deliver to them. The behaviour that trips people up is that the send **succeeds**: `SendEmail` returns a message ID as usual, so your application sees nothing wrong, and the failure surfaces only as a bounce event whose subtype tells you it was suppressed. You manage the list through the SESv2 API — `ListSuppressedDestinations`, `GetSuppressedDestination`, `PutSuppressedDestination` to add an address yourself, `DeleteSuppressedDestination` to remove one when a customer re-signs up with a now-valid mailbox. There is also a separate global suppression list that AWS maintains across all accounts, which you do not administer.
code
bash · 12 lines# Is this address suppressed, and why?
aws sesv2 get-suppressed-destination --email-address [email protected]
# Seed the list when migrating from another provider
aws sesv2 put-suppressed-destination \
--email-address [email protected] --reason BOUNCE
# Remove one address after the customer fixed a typo
aws sesv2 delete-suppressed-destination --email-address [email protected]
# Which reasons add addresses automatically?
aws sesv2 get-account --query 'SuppressionAttributes'go deeper
Recall that SES keeps a per-account list of addresses that hard-bounced or complained, and say plainly that a send to one of them still returns a message ID but is never delivered.
Explain the mechanics: which reasons populate the list automatically, the SESv2 operations that read and edit it, and how the suppression shows up as a bounce event rather than an API error.
Show the operational instinct: check suppression first when a customer reports missing mail, seed the list during a provider migration, and refuse bulk deletions that would replay known bad addresses.
Own the policy. Decide which streams may override suppression at the configuration-set level, how suppression state reconciles with your own user records, and where list hygiene sits in the sending programme.
## Why the list exists Repeatedly mailing addresses that do not exist is the single clearest signal to a receiving provider that a sender is working from a bad list. AWS shares sending infrastructure across customers, so your bad list threatens everyone's delivery, not just yours. The suppression list is SES's automatic brake: once an address has hard-bounced or complained, SES stops attempting delivery on your behalf, whether or not your application has learned its lesson. ## Two lists, one of which is yours - **The account-level suppression list** is yours. You can read it, add to it, and remove from it. - **The global suppression list** is maintained by AWS across all customers for addresses that have bounced repeatedly account-wide. You do not administer it; sends to those addresses also come back as suppression bounces. When an interviewer asks "why did this one address never receive anything, in any environment," the global list is the answer worth knowing exists. ## How addresses get on your list Automatically, by reason. You configure which reasons are active at the account level — `BOUNCE`, `COMPLAINT`, or both — through the account suppression attributes. Leaving both on is the sensible default. You can also add addresses yourself with `PutSuppressedDestination`, and that is more useful than it sounds. If you are migrating from another email provider, seeding SES's list with the addresses your old platform had already suppressed stops you from re-learning the whole bad list at the cost of your fresh reputation. ## The silent-success behaviour This is the part that produces support tickets. Sending to a suppressed address is not an API error: 1. `SendEmail` returns HTTP 200 and a `MessageId`. 2. SES does not attempt delivery. 3. A bounce event is emitted, whose subtype identifies the send as suppressed rather than as a fresh delivery failure. So an application that only checks the API response concludes the mail was sent. The user says they never got it. Your logs agree with you. The truth is only in the event stream — which is precisely why bounce and complaint events must be routed somewhere your systems read, not into a mailbox. A useful debugging habit: before escalating "our email is broken for this customer," run `GetSuppressedDestination` for the address. It returns the reason and the timestamp, which usually ends the investigation in one call. ``` aws sesv2 get-suppressed-destination --email-address [email protected] ``` ## Removing an address `DeleteSuppressedDestination` removes it. The legitimate reason is that the situation genuinely changed — a customer fixed a typo in their address, a corporate mailbox that was decommissioned has been recreated, a shared address bounced during a provider outage. The illegitimate reason is a growth push that wants the list cleared because suppressed addresses are hurting a delivered-count metric. Re-mailing addresses that hard-bounced re-runs the same bounce, and doing it in bulk is how an account ends up under review. If you are considering a bulk delete, that is the moment to ask where the list came from in the first place. Note too that removing an address from SES's list does nothing to your own database. If your application still has the user marked as unreachable — or, worse, still has them marked reachable and has been silently failing — those are separate records to reconcile. ## Per-configuration-set overrides Suppression can also be set at the configuration-set level, overriding the account setting for sends that use it. The realistic use is stream separation: a marketing stream where complaint-based suppression should absolutely apply, versus a critical transactional stream — password resets, security alerts, legally required notices — where you may want different behaviour because not delivering has its own consequences. Treat that as a deliberate, documented decision rather than a knob to turn when something is inconvenient, because the reputation cost lands on the whole account either way. ## What a good answer sounds like Name the list, say it is populated automatically from hard bounces and complaints, and lead with the behaviour: the send succeeds, the delivery does not, and the only place the truth appears is the event stream. That last point is what separates someone who has operated SES from someone who has read its feature list.
- A customer swears they never receive your SES mail, but your logs show successful sends. What is your first check?Call `GetSuppressedDestination` for that address. If it comes back with a reason and a timestamp, the send was accepted and never delivered — which matches your logs exactly. That one call usually ends the investigation, and it is faster than reading through event history. If the address is not suppressed, move on to the bounce and complaint events for those message IDs.
- Marketing asks you to clear the whole suppression list because it is shrinking their audience. What do you say?No, and explain why: those addresses hard-bounced or complained, so re-mailing them reproduces the same bounces at scale and puts the account's sending reputation — every stream, including password resets — at risk. The right conversation is about where the list came from. A suppression list that large is a list-acquisition problem, not a suppression problem.
- How does an address end up unreachable in every one of your AWS accounts?The AWS-managed global suppression list. It spans all customers and catches addresses that have bounced repeatedly across the platform, and you do not administer it. Sends to such an address are accepted and then bounce as suppressed, exactly like account-level suppression, which is why the two look identical from the application's point of view.
saying these in an interview costs you the question
- Expecting SendEmail to fail when the address is suppressed
- Thinking the suppression list is shared with your own database
- Clearing suppressed addresses in bulk to grow the audience
- Confusing sandbox recipient verification with suppression
- Believing only complaints, never bounces, add addresses