The **Undeliverable** page lists every recipient address that has produced an undeliverable signal in roughly the last year — permanent bounces, complaints, rejects, plus the configurable rules you have enabled (repeated transient bounces, undetermined bounces, and soft-bounce accumulation) — along with any addresses you have explicitly cleared. It complements the [Deliverability Reports](/reports/deliverability-reports) by giving you a per-address operational view rather than aggregate rates.



## What gets listed

An address appears on the Undeliverable list when SendOps has ingested events that match an enabled classification rule. Three rules are always-on; three are configurable.

### Always-on rules

| Event | Condition | Reason |
|-------|-----------|--------|
| Bounce | `bounceType = Permanent` (any sub-type — `NoEmail`, `General`, `Suppressed`, `OnAccountSuppressionList`, etc.) | `permanent_bounce` |
| Complaint | Any complaint | `complaint` |
| Reject | Any reject (content refused before sending) | `rejected` |

These three rules cannot be disabled. Complaints are locked on for compliance reasons (CAN-SPAM, CASL, GDPR); permanent bounces and rejects are the AWS-confirmed signals at the core of any suppression discipline.

### Configurable rules

| Rule | What it catches | Default |
|------|-----------------|---------|
| `repeated_transient` | Receivers that accept the message then asynchronously reject it (Mimecast / Office 365 / Proofpoint accept-then-NDR), surfaced as `Transient/General` bounces in SES | On — 3 events in 30 days |
| `undetermined` | SES couldn't classify the bounce (rare, ~1% of events) | Off — 2 events in 14 days |
| `soft_bounce_accumulation` | Transient bounces with sub-type `MailboxFull`, `MessageTooLarge`, `ContentRejected`, or `AttachmentRejected` | Off — 5 events in 14 days |

Each configurable rule has two knobs: **events** (how many qualifying events must occur) and **window** (how many days back to look). When ≥ N qualifying events have happened for an address in a rolling M-day window ending now, the rule fires. Tune both from the [Classification Rules](/reports/classification-rules) page.


Successful events (`Send`, `Delivery`, `Open`, `Click`) never put an address on this list. `DeliveryDelay` never qualifies on its own either — only bounces, complaints, and rejects do.



This list is different from the AWS SES suppression list. AWS only auto-suppresses permanent/General bounces and complaints, and entries there expire after 14 days by default. SendOps's Undeliverable list includes a wider set of signals (and your configurable rules), with no automatic expiry — so it tends to be broader and longer-lived.


## Reading a row

Each row shows the address along with:

| Column | What it tells you |
|--------|-------------------|
| **Email** | The recipient address. |
| **Status** | `Listed` — currently failing delivery. `Excluded` — you've cleared this address and SendOps will allow delivery to it again. |
| **Reason** | The rule that matched this address. When multiple rules match, the highest-priority one wins: `permanent_bounce` > `complaint` > `rejected` > `repeated_transient` > `undetermined` > `soft_bounce_accumulation`. For permanent bounces and complaints, a sub-type is appended (e.g. `permanent bounce · NoEmail`, `complaint · abuse`). |
| **Events** | How many qualifying events SendOps has seen for this address in the account's ~365-day event window. Useful for triage — an address with 1,698 hits jumps out instantly. |
| **Last change** | When the row last changed state. For listed rows this is the most recent failure event; for excluded rows it's when you cleared the address. |
| **Last diagnostic** | The SMTP response from the most recent event (e.g. `550 5.1.1 <user@example.com>: Recipient address rejected: User unknown`). Distinguishes "user unknown" from "domain offline" from "policy refused", which matters when you go talk to a customer. For excluded rows this column shows the operator note instead, if one was recorded. |

## Filtering and search

Three controls narrow what you see:

- **Search email** — case-insensitive substring match against the recipient address.
- **Status** — `Listed` (default), `Excluded` (just your cleared addresses), or `All` (both).
- **Reason** — restrict listed rows to any of the six reason values.

Filters compose. Searching `acme` with `Status: All` will show every `@acme.com` address regardless of whether you have cleared it.

## Allowing delivery to an address

If you're confident an address is fine — a customer typo you've corrected on their end, a fixed inbox after IT work, or a false positive — you can clear the address from the list. SendOps will allow delivery to it again from that point onward.

1. Find the address in the list (use search if needed).
2. Click **Allow** on the row.
3. Optionally add a short note (e.g. "Customer fixed mailbox after IT migration"). Notes are recorded in the audit log alongside the operator who took the action.
4. Confirm.

The row immediately moves to `Excluded` and disappears from the default view. You can see it again by switching the status filter to `Excluded` or `All`.


Allowing delivery to an address that is genuinely undeliverable will likely cause it to bounce again. If that happens, SendOps will automatically put the address back on the list with `Listed` status — your clearing decision is overridden by the new failure. There is no penalty for the round-trip, but for high-volume addresses you may want to verify the underlying issue is fixed before allowing.


## Re-listing a cleared address

If you change your mind, switch the status filter to `Excluded`, find the address, and click **Re-list**. The exclusion record is removed; the address returns to the undeliverable view if any qualifying events still exist within the account's ~365-day event window.

## Configuring which rules apply

Click **Configure rules** in the top-right of the page (or visit `/undeliverable/rules`) to choose between the **Strict** / **Standard** / **Aggressive** preset profiles or to set individual rule thresholds. See [Classification Rules](/reports/classification-rules) for the full configuration guide.

A live preview on that page shows how the list size and breakdown would change before you save — useful when you're considering turning on a new rule.

## Permissions

| Action | Required permission |
|--------|---------------------|
| View the Undeliverable page | `undeliverable.view` |
| Allow delivery to an address (clear it) | `undeliverable.manage` |
| Re-list a cleared address | `undeliverable.manage` |
| Change classification rules | `undeliverable.configure` |

By default, **Owner** and **Org Admin** roles have all three permissions. **Member** and **Support** roles can view but not modify. Operators without a permission will see the action buttons disabled with an explanatory tooltip.

Every clear / re-list / rules-change action is recorded in the [Audit Log](/team/audit-log) with the operator's identity, before/after snapshots where relevant, and any note they added.

## How far back the list looks

The listed portion of the page is bounded by a fixed window of roughly the **last 365 days** — an address whose most recent failure was over a year ago falls off the list. This window is the same for every account; it is not tied to your plan's retention setting. (Plan retention *does* apply to the programmatic `GET /v1/undeliverable` API, but not to this dashboard.) Cleared addresses (excluded rows) live in durable storage and survive regardless of age; they remain visible under `Status: Excluded` no matter how long ago you cleared them.

For the windowed rules (`repeated_transient`, `undetermined`, `soft_bounce_accumulation`), the lookback is instead the rule's own **window** knob — for example, with `repeated_transient` set to 3 events in 30 days, only events within the last 30 days count toward the threshold. Older events don't keep an address on the list past the window; the row falls off automatically once recent events no longer satisfy the rule. Cleared exclusions are unaffected.

## What's next?

- Tune which signals make an address undeliverable on the [Classification Rules](/reports/classification-rules) page.
- Use [Deliverability Reports](/reports/deliverability-reports) to see aggregate bounce and complaint rates over time.
- Configure [Notifications](/notifications/configuring-notifications) to be alerted when your bounce or complaint rates cross a threshold.
- If you're seeing many undeliverable addresses from a single provider, the [Deliverability by Provider](/reports/deliverability-reports#deliverability-by-provider) table can help identify the source.