Suppression list

The list of addresses you must not mail. It protects your recipients, your reputation, and you.

A suppression list is a sender's do-not-send ledger: the addresses that must not be mailed again, and why. Entries come from hard bounces, spam complaints, unsubscribes, and manual additions, and every outgoing message is checked against the ledger before it is allowed to send.

Why it matters

Suppression is where law and self-interest agree. Honoring opt-outs is a legal requirement (CAN-SPAM in the US, GDPR and the ePrivacy rules in Europe). Continuing to hit dead addresses and complainers is, separately, how senders end up on blocklists: abandoned mailboxes get recycled into spamtraps, and complainers escalate. A leak, meaning any code path that sends without checking the list, turns one bug into a legal problem and a reputation problem at the same time.

In practice

Suppression should be scoped. An unsubscribe from marketing must stop newsletters but not password resets (see transactional email), while a hard bounce stops everything, because the mailbox does not exist for any stream. The classic failure is architectural rather than intentional: a platform grows multiple ingress paths over time, API, SMTP relay, batch imports, automations, and each one implements its own suppression check, until one of them forgets. The fix is structural: one checkpoint, on the only road in.

How Email Fast handles it

That failure mode is designed out here: every send — REST, SMTP, browser SDK, compatibility endpoints, broadcasts, automations — passes through one admission gate: idempotency, suppression, quota, and content policy in a single checkpoint no ingress can skip. Suppression entries record their source and scope, and the ledger is queryable over the API, so you can always answer why a given address is not receiving mail.