Why an address was suppressed
Trace a suppression entry back to the bounce, complaint, or manual add that created it, and decide whether removing it is safe.
An entry exists on your suppression list because of a hard bounce, a spam complaint, or a manual add, and the reason field on that entry says which.
Read the reason
| Reason | What created it | What it means |
|---|---|---|
hard_bounce | A permanent bounce recorded by SES | The mailbox doesn't exist, or the domain won't accept mail |
complaint | The recipient marked the message as spam | The recipient doesn't want mail from you, whatever reason they clicked the button for |
manual | POST /v1/suppressions from the dashboard | Someone chose to block this address by hand |
Only permanent bounces and complaints suppress automatically; a soft (transient) bounce adds no entry. See Suppressions.
What a suppressed address does to a send
A send to a suppressed address is never rejected, which surprises people expecting an error. What actually happens depends on exactly when the suppression is caught.
If only some of the recipients are suppressed, the message still goes to the rest, silently and with no error. If every to recipient is suppressed by the time the request is accepted, you get 202 and a message id anyway, but the message is persisted with status canceled: nothing was enqueued and nothing was metered.
The third possibility is a race. An address can be suppressed in the moments between your request being accepted and the message being handed off for delivery, and a message caught there flips to status failed with last_event: "suppressed", with a synthetic suppressed event written to the timeline. That last case is easy to miss, because the event timeline rather than the initial 202 is what tells you what happened. See Suppressions.
Should you remove it
| Reason | Remove it? |
|---|---|
complaint | No. The recipient told a receiving network they don't want your mail, and removing the entry doesn't change that. |
hard_bounce | Only once you've fixed the underlying problem, such as a typo correction or a re-created mailbox. Otherwise the same address hard-bounces again and re-suppresses itself. |
manual | Once the reason it was added by hand no longer holds. |
Simulator addresses in the list
Test-mode bounce and complaint drills create entries too, keyed on a @simulator.amazonses.com address rather than the address you actually sent to, so they never block a live send. The suppression list is org-global, so these entries show up even when you list suppressions with a live key. See Test mode.
Removing an entry
Delete suppression requires the manage:suppressions scope, and that scope is session-only: it can never be minted onto an API key, so a script authenticated with an mf_ key gets 403 insufficient_scope here. Removing an entry is a dashboard action. See Suppressions.