| Audience | Marketers, lifecycle and CRM teams, marketing ops, compliance |
| Prerequisites | The Manage settings permission for Native Delivery |
A suppression list excludes a group of profiles from a subscription topic, whatever their subscription preferences say. Define who's on the list with the same audience conditions you use everywhere else, and Hightouch applies it every time a campaign builds its audience.
What you'll learn
When to use one
Use a suppression list when you want to hold back a group without touching their subscription preferences. Common cases:
| Case | Example |
|---|---|
| Regional exclusions | Anyone in France or Germany, while you sort out local requirements |
| Legal holds | Anyone flagged by legal or compliance |
| Migration overlap | Profiles still receiving mail from the platform you're migrating off |
| Holdouts | A percentage of profiles held back so you can measure lift |
A suppression list is the right tool when the exclusion is yours and temporary. It isn't the tool for recipients who unsubscribed or whose address bounced, both of which are already enforced on every send. See Subscriptions and consent.
Create a suppression list
- Go to Native Delivery → Settings → Suppression lists and select Create.
- Enter a Name, and a Description if it helps others understand the intent.
- Choose the Topics this list applies to. At least one is required.
- Open the Definition tab and build the conditions that decide who is on the list.
- Save.
A list has two tabs. Definition holds the conditions, and Subscription topics holds the topics it applies to. Both are editable, and changes take effect on the next send.
The list view shows each list's Size, the number of profiles currently matching it. The count is cached for a day, so it can lag a definition change until it recomputes.
A suppression list is a set of conditions, not an uploaded file. You build it with the same audience builder you use for audiences, and it re-evaluates against your warehouse on every send. There's no CSV import.
A list with no conditions suppresses nobody, so a half-built list can't accidentally block an entire send.
Choose which topics it applies to
Suppression lists attach to subscription topics, not to individual campaigns or messages. A campaign is suppressed by the lists attached to its topic.
One list can apply to several topics, and one topic can have several lists. Where a topic has more than one, a profile matching any of them is suppressed.
Because suppression is evaluated per topic, a list only affects campaigns sending on the topics you attach it to. A campaign on a topic with no lists attached is never suppressed. If an exclusion has to be absolute, attach the list to every topic.
How suppression is enforced
Suppression runs in the warehouse when a campaign builds its audience, alongside subscription and bounce checks. Recipients who match are dropped before anything is sent.
Two consequences worth knowing:
- The reachable count already accounts for suppression. The number you see when reviewing a campaign is the number after suppressed profiles are removed.
- Lists are re-evaluated as a send progresses. A recurring campaign picks up changes to the list, and to the underlying data, on each run. There's no snapshot to refresh. For a send that spans hours, such as one pacing to recipients' local time, a profile added partway through is suppressed for the rest of it.
Suppression is checked as recipients are gathered, not at the final moment of handoff. Adding someone to a list won't recall a message already on its way out.
Suppressed recipients appear as Suppressed in your campaign's drop reasons. See Reporting. Looking at one person, the profile shows On a suppression list against the message they didn't receive.
The drop reasons report one Suppressed total rather than a breakdown per list, so a profile on two lists counts once.
Matching is on the profile
A suppression list matches profiles from your parent model, not email addresses or phone numbers.
Suppressing a profile suppresses that person, not one address. If the same person appears in your warehouse as two profiles, suppressing one doesn't suppress the other. Conversely, a profile whose email address changes stays suppressed, because the match never depended on the address.
Because matching needs a profile, a suppression list can't exclude a bare email address that isn't in your parent model.
Which sends are suppressed
| Send | Suppressed |
|---|---|
| Campaign | Yes |
| Journey message step | Yes |
| API-triggered | No |
| Transactional message, on any of the above | No |
The two exemptions matter if you're using a list as a legal or compliance hold.
Transactional messages aren't suppressed. Suppression is evaluated per subscription topic, and a transactional message has no topic, so no list applies to it. A profile on every list you have still receives transactional mail.
API-triggered sends aren't suppressed. Lists are evaluated when a campaign builds its audience from your warehouse, and an API-triggered send supplies its recipients directly, so there's no audience to filter. Exclude those recipients in your own code before you call. See Send with the API.
Bounces and spam complaints are still enforced in both cases. Suppression lists and topic preferences are what get skipped.
If an exclusion has to hold across every kind of send, keep the profile out of the audiences your campaigns are built on, rather than relying on a suppression list alone.