---
title: "Why an address was suppressed"
description: "Trace a suppression entry back to the bounce, complaint, or manual add that created it, and decide whether removing it is safe."
---

> **For AI agents:** the complete documentation index is at [llms.txt](/docs/llms.txt). Append `.md` to any page URL for its markdown version.

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](/guides/suppressions#what-gets-suppressed-automatically).

## 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](/guides/suppressions#sending-to-a-suppressed-address).

## 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](/guides/test-mode#suppressions-from-test-bounces).

## Removing an entry

[Delete suppression](/api-reference/suppressions/delete) 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](/guides/suppressions#remove-a-suppression).