How to build a suppression list
A suppression list is only doing its job if it is checked twice. Once when an audience is assembled, and again at the moment each message sends.
The short answer
- A suppression list should include explicit unsubscribes, hard bounces (the address does not exist), spam complaints, and any contact who opted out through another channel. Soft bounces are usually retried rather than suppressed on the first failure.
- Suppression needs to be checked at two separate points. When an audience or list is assembled, and again at the moment of send. Time passes between those two events, and a contact's status can change in that window.
- If a team sends from more than one tool, each with its own suppression list, an opt-out registered in one tool will not stop a send from a different tool unless the lists are shared or synced. To the recipient, that looks like an ignored opt-out.
- Suppression is a mechanism a product can enforce. The obligation to honor an opt-out request comes from CAN-SPAM, GDPR or similar law, and stays with the sender whichever tool is used.
Why a suppression list checked once is not actually working
The common failure with suppression lists is not that they do not exist. Most sending tools maintain one by default. The failure is timing. A list gets assembled and frozen for a cadence. Suppression is checked at that moment, correctly removing anyone who had already unsubscribed or bounced. But a multi-step cadence can run for two to four weeks. During that window a contact can unsubscribe from an earlier, unrelated message. Their address can start bouncing for an unrelated reason. If suppression is only checked once, at the start, that contact keeps receiving scheduled sends they should have stopped receiving.
The fix is checking suppression again at the actual moment of send, not only when the audience was built. It is a small technical difference with an outsized effect on whether a real opt-out request is honored in practice. The gap between list-freeze and send is exactly where most silent suppression failures happen.
A second common failure is fragmentation. A team uses two or three different sending tools, each with its own suppression list that does not talk to the others. A contact who unsubscribed from a cold-email tool can still receive a message from a separate sequencing tool the same week. From that second tool's point of view, nothing ever happened.
What belongs on a suppression list
| Category | Suppress immediately? | Notes |
|---|---|---|
| Explicit unsubscribe / opt-out | Yes | Legal obligation under CAN-SPAM, GDPR and similar laws |
| Hard bounce (address does not exist) | Yes | Repeated sends to a dead address damage sender reputation |
| Spam complaint | Yes | The strongest negative deliverability signal; suppress and investigate the source list |
| Soft bounce (temporary failure) | No, retry first | Suppress only after repeated soft bounces on the same address |
| Opted out through another channel (call, ticket) | Yes | Recipient intent is the same regardless of channel |
What to actually build
At minimum, a working suppression system needs three things. One authoritative list per sending domain or account. A process that adds an address the moment an unsubscribe, hard bounce, or complaint is recorded. A check against that list right before every send, not only at list assembly. If a team uses several sending tools, either route all sends through one system with a shared list, or build a sync between the tools' separate lists.
Disclosure: SalesCrew is our product. Suppression is enforced automatically both when an audience is frozen and again at the moment of send. Unsubscribes and bounces feed the list directly from the inbox and sender pool. It does not decide your legal obligations around consent or opt-out. It enforces the suppression rules the product is configured with.
Suppression is enforcement, not the legal obligation itself
Questions
- What should go on a suppression list besides explicit unsubscribes?
- Hard bounces (the address does not exist), spam complaints, and any contact who has explicitly asked not to be contacted through another channel, such as a phone call or a support ticket. Soft bounces (a temporary delivery failure) are usually retried rather than suppressed at once.
- Is checking suppression once, when a list is built, enough?
- No. A contact can unsubscribe or bounce between when a list is frozen and when a cadence sends, especially in a multi-week cadence. Checking suppression only at build time, not again at send time, is one of the most common ways a suppressed contact still gets an email.
- Does a suppression list need to be shared across every sending tool a team uses?
- Ideally yes. If a team sends from more than one tool and each keeps its own suppression list, a contact who unsubscribed through one tool can still be emailed by another. From the recipient's side, that looks identical to ignoring the opt-out.