Email Suppression Lists: What They Are and Why You Need One

An email suppression list is a do-not-send list that your sending platform checks before every single send, independent of your contact list. It is the layer that stops you from mailing addresses that have hard bounced, filed a spam complaint, or unsubscribed — even if those addresses still exist in your database, in a segment, or in an automation. If you are dealing with bounces and invalid addresses right now, the suppression list is the mechanism that keeps those problems from repeating on every campaign.

What an email suppression list actually is

A suppression list is not a folder of bad contacts you clean up once. It is a permanent filter that sits between your audience and the send pipeline. Contacts can live in your database and never receive mail, because suppression is evaluated at send time, not at import time.

It does three jobs:

• Protects sender reputation. Repeatedly mailing invalid addresses and complainers is one of the fastest ways to damage a sending domain. Receiving providers watch how you handle bounces and complaints, and suppression shows you are paying attention.
• Prevents wasted sends. Every message to a dead mailbox is a send that cannot generate a click, an order, or a reply.
• Keeps you compliant with consent rules. Once someone unsubscribes or complains, continuing to mail them is a consent problem, not just a deliverability one.

A status field is data about a contact; suppression is a hard block. Status fields get overwritten by a CSV import, a segment rebuild, or an API call that sets subscribed: true. A suppression entry survives all three.

One detail that surprises people: transactional and campaign sends usually share the same suppression logic. If a receipt hard bounces, that address is suppressed for the newsletter too. That is intentional — a dead mailbox is dead regardless of message type.

What gets suppressed (and what does not)

Hard bounces

Invalid domain, unknown user, address rejected permanently. These should be suppressed immediately and never retried. A hard bounce is the receiving server telling you the mailbox does not exist.

Soft bounces

Mailbox full, temporary server error, greylisting. These are temporary and should be retried. Suppress only after repeated consecutive failures — the threshold is your decision, covered below. If you are working through this specific case, the guidance on mailbox full bounces walks through when retrying stops being worth it.

Spam complaints

A complaint is a stronger signal than an unsubscribe: the recipient actively told their provider your mail is unwanted. Suppress immediately and permanently.

Unsubscribes

One-click unsubscribes and List-Unsubscribe requests. These should be recorded permanently, ideally as both a status and a suppression entry so a re-import cannot resurrect them.

Role and abuse addresses

Some senders suppress role accounts (info@, sales@, support@) and known spam traps. This is a policy choice, not a technical requirement — role accounts can be legitimate business contacts, but they rarely convert and they carry risk.

What does not belong on the list

An engaged contact who skipped one campaign. Someone who bounced once during a provider outage. A contact who clicked but did not buy. Suppression is for permanent or high-confidence signals, not for people who were briefly quiet.

Account-level vs global suppression

There are two layers, and confusing them causes real problems.

Account-level suppression lives inside your account and applies only to your sends. You control it. You can usually see the reason for each entry and, in narrow cases, remove one.

Global suppression may be maintained by the sending platform or ESP across accounts — this is worth confirming with your specific provider, since some operate shared IP pools or pool reputation data. A global suppression entry can block an address you have never mailed, and you typically cannot remove it.

The practical consequences matter more than the definitions:

• You cannot "clean" your way out of a global block. Re-importing the address will not resurrect it.
• If you migrate platforms, check whether global entries transfer — they are platform-owned and often do not.
• Own-domain sending changes which layer applies, because reputation is tied to your domain rather than a shared pool. Mailerflow uses own-domain sending with guided DKIM, SPF and DMARC setup and automatic verification, so your reputation is yours.

How suppression works in practice

The pipeline runs in a fixed order:

1. A contact enters a segment, campaign, or automation.
2. The platform checks the suppression list at send time.
3. Suppressed contacts are skipped and logged with a reason.
4. Everything else is sent.

The feedback loop closes automatically: bounce and complaint data arrives from the receiving mailbox provider, the platform classifies it, and the suppression entry is written. Mailerflow suppresses bounces and complaints automatically and monitors reputation, so this loop does not depend on someone reading a bounce report and updating a spreadsheet.

Note the distinction between suppressing and deleting. Suppression keeps the record — useful for audit trails, consent history, and answering "why did this person not get the campaign?" Deleting removes the evidence.

Decisions you need to make before you send

Soft-bounce threshold. How many consecutive soft bounces before suppression? Pick a number and write it down. Example: suppress after three consecutive soft bounces across at least seven days. A single mailbox-full bounce during a vacation should not remove a customer.

Where unsubscribes live. As a suppression entry, a status field, or both? Both is safest, because status fields are fragile under re-imports.

Role addresses and catch-alls. Decide whether info@ and catch-all domains are mailable. Catch-alls accept mail for any address, so they hide invalid recipients.

Transactional vs marketing. If someone unsubscribes from marketing, do they still receive receipts and password resets? Usually yes — decide explicitly rather than by accident.

Retention. How long do you keep suppressed records? This ties into data minimisation under GDPR. Keeping an email address on a suppression list is generally defensible as necessary to honour the opt-out; keeping a full profile is harder to justify.

Who can remove an entry. Ideally: almost no one, and never without a documented reason.

Migrating a suppression list to a new platform

This is where most damage happens. The order of operations is not optional.

1. Export the suppression list from the old platform — not just your contact list. These are different files.
2. Export unsubscribe and complaint records separately if they are stored as contact statuses rather than suppression entries.
3. Normalise the file: one email per row, plus a reason column (hard_bounce, complaint, unsubscribe).
4. Import the suppression list into the new platform before importing contacts.
5. Verify by sending a test to a known suppressed address and confirming it is skipped.

Step 4 is the one people get wrong. Import contacts first and suppression second, and you create a window where previously unsubscribed addresses are mailable — and any automation triggered by the import will mail them immediately.

Mailerflow offers free migration help with contacts, suppression lists, templates and core automations on eligible paid plans, and its CSV import includes duplicate and validity checks. Be aware that global suppression entries from your old platform may not transfer, since those are platform-owned.

Worked examples

These are illustrative scenarios, not customer stories.

A domain migration with a hard-bounce spike. A sender moves to a new sending domain and sees hard bounces climb. Suppression catches them going forward, but the root cause is authentication: the new domain has no DKIM, SPF, or DMARC records. Suppression is the safety net; authentication is the fix. Check both.

A complainer still in three segments. Someone files a complaint but remains in "Newsletter," "Product updates," and "Trial users." Without suppression, all three segments would mail them next week. With suppression, the send-time check overrides segment membership entirely. This is the clearest argument for suppression living outside your segment logic.

The re-import that reactivated unsubscribes. Someone uploads last year's CSV. If unsubscribes were stored only as a status field, the import overwrites them and everyone who opted out becomes mailable again. If they were also on the suppression list, the send is blocked regardless. Check which one your setup relies on.

Common mistakes

• Treating suppression as a one-time cleanup instead of a permanent layer.
• Deleting suppressed contacts and losing the audit trail.
• Suppressing on a single soft bounce.
• Assuming a global suppression entry can be appealed.
• Forgetting that API and transactional sends bypass manual review but not suppression.
• Not exporting suppression data before leaving a platform.
• Letting a re-import silently reactivate unsubscribes.
• Watching bounce rates while ignoring complaint rates.

Checklist

• [ ] Suppression list exists and is checked at send time
• [ ] Hard bounces auto-suppressed
• [ ] Complaints auto-suppressed
• [ ] Unsubscribes recorded permanently (status and suppression)
• [ ] Soft-bounce threshold documented
• [ ] Suppression exported before any migration
• [ ] Suppression imported before contacts
• [ ] Test send to a suppressed address confirms the skip
• [ ] DKIM, SPF and DMARC verified on the sending domain
• [ ] Bounce and complaint rates reviewed on a schedule
• [ ] Retention policy for suppressed records defined

FAQ

Can I remove an address from a suppression list? Account-level entries can sometimes be removed if the underlying cause is fixed — for example, a mailbox that was full and now accepts mail. Global entries maintained by a platform generally cannot be removed by you. In both cases, removal should require a documented reason.

What is the difference between unsubscribing and being suppressed? Unsubscribing is an action the recipient takes; suppression is the technical state that results from it, and from bounces and complaints too. A contact can be suppressed without ever unsubscribing.

Do transactional emails respect the suppression list? Usually yes, because suppression is evaluated at send time for all mail. That means a hard-bounced address will not receive receipts either. Decide deliberately whether marketing unsubscribes should block transactional mail — a common approach is to keep transactional mail flowing.

Will a suppressed contact be deleted from my database? No. Suppression and deletion are separate. Keeping the record preserves your consent and audit history, which is usually what you want.

How do I check whether an address is suppressed? Check your provider's documentation for how to search the suppression list, and look at send logs, which typically show skipped recipients with a reason. If you cannot find it, send a test to that address and confirm it is skipped.

What happens if I re-import a suppressed address? Nothing, if suppression is checked at send time — the contact may reappear in your database but will not receive mail. If your setup relies only on a status field, the import can overwrite it and the address becomes mailable again.

If your bounce and complaint handling is currently manual, the highest-leverage first step is getting authentication right on your sending domain, because suppression cleans up the symptom while authentication addresses the cause. Set up your sending domain in Mailerflow with guided DKIM, SPF and DMARC and automatic verification, and suppression of bounces and complaints runs alongside it.