Suppression segments and the platform suppression list

What it does

Two different things stop a message reaching someone, and consultants routinely confuse them. A suppression segment is your own audience of people you've decided not to contact, applied to a journey as an exclusion or an exit. The platform suppression list is Microsoft's deliverability safety net, applied automatically to every send at the email-address level, and you don't get a vote.

Key facts

Journey-level exclusion is set under Entry criteria > Exclude this segment. Anyone in that segment doesn't enter.
Mid-journey suppression is set under Exit criteria > Exit by segment. Members who fall into that segment leave the journey wherever they've got to.
The exclusion segments offered are filtered by the entry audience's table. A contact-based journey only sees contact-based segments, so a lead suppression list won't appear.
The platform suppression list covers hard-bounced addresses, spam-complaint addresses (feedback loop), soft bounces after five consecutive failed delivery attempts to the same address, and pattern-based suppression maintained by Microsoft's deliverability engineers for things like disposable domains and test mailboxes.
Suppression operates on the email address, not the contact or lead record. Two contacts sharing an address are both affected.
Hard bounces are retained for about 180 days, tracked per organisation.
Repeat suppressions escalate: the documented periods run 7 days for the first, 14 for the second, 30 for the third, and 180 days from the fourth onward.
Spam-complaint listings don't expire on their own.
The contact's Communication tab shows one of three states — not on the suppression list, on the suppression list (removable), or permanently blocked (not removable, e.g. spam complaints and invalid mailboxes) — with a Remove from suppression list action for the removable cases.
Addresses on the same domain as your sending domain are eligible for delisting, which is how you rescue your own test mailboxes.
For consent-driven suppression, build a consent-based segment rather than an attribute filter: consent segments evaluate contact point consent using the same logic as journey execution, and deliberately ignore the legacy DoNotBulkEmail attribute.

When to use / skip

Every production tenant needs at least one suppression segment. The usual set is a global do-not-contact list, a recent-contact fatigue list, and an internal/test exclusion. Build them once, apply them everywhere, and make it part of the journey checklist rather than something each marketer remembers.

Where I'd skip: don't build a suppression segment for anything consent already handles. Consent enforcement happens at send time regardless, and duplicating it in a segment gives you two sources of truth that will diverge. The same goes for hard bounces — the platform already blocks them and your segment will lag reality by up to an hour.

Exit-by-segment is worth using sparingly. It's the right tool for "stop the nurture the moment they become a customer", and the wrong tool for anything you could express as a normal journey branch.

Configuration decisions

Which suppression segments are mandatory on every journey, and how that's enforced — process, template journey, or review gate.
Whether suppression is applied at entry (exclude) or during the journey (exit by segment), or both. Entry-only leaves people already in flight.
Which audience table each suppression segment targets, remembering the picker filters by the journey's entry audience. If you run contact-based and lead-based journeys, you need a matching pair.
How the do-not-contact population is maintained — consent records, a flag on the contact, or a curated static list — and who owns it.
Whether marketers are allowed to remove addresses from the platform suppression list, and under what evidence.
Fatigue rules: what "recently contacted" means in days, and whether it's global or per channel.

Gotchas

Exclusion at entry doesn't retrospectively remove anyone already inside a running journey. Adding someone to the do-not-contact segment does nothing for the email they're due tomorrow unless you've also wired exit criteria.
Suppression segments refresh on the standard segment cadence, so there's a window of tens of minutes between adding someone and the exclusion taking effect. That window is not obvious to a client who has just promised a customer they'd stop.
Address-level suppression means a shared mailbox — info@, or a couple sharing an address — silently affects more than one record.
Permanently blocked addresses can't be recovered from the UI. If a stakeholder marked a campaign as spam, their mailbox is out of your test cycle for good.
Repeated sends to a suppressed address don't produce a visible error in the journey; the message is simply blocked. People read the missing delivery as a journey bug.
Building do-not-contact on DoNotBulkEmail looks reasonable and is not what consent-based segments evaluate. Two mechanisms, two answers, one very awkward audit.

Consultant notes

Add "which suppression segments are applied?" to the go-live checklist for every journey. It's the control that catches the largest class of embarrassing sends.
Walk the client through the Communication tab on a contact record during UAT so they can self-diagnose "why didn't they get it" without raising a ticket.
Push back on custom fatigue logic built from interaction queries. It's expensive to refresh and usually rebuilds something the client can express more simply.
Get internal test mailboxes onto the sending domain early, so a bounce during testing is recoverable rather than a 180-day problem.
Be explicit with the client that platform suppression is Microsoft's, not theirs. They can't override it, and asking for a way to is not a change request anyone can fulfil.

Worth another look if the suppression escalation periods change, or if exit-by-segment gains retrospective evaluation.