Suppression lists: how not to email someone who opted out

A recipient clicks “unsubscribe”, gets a confirmation, and a week later another campaign from the same company lands in their inbox. You know this from the other side of the mailbox. From our perspective, as a team running its own fleet of sending servers, it looks simpler and worse at the same time: someone removed the address from a list instead of writing it into the suppression list. A suppression list is a list of addresses the system is forbidden to send to – it overrides every list, every segment and every import. It is not part of a list. It is a layer above all of them.

What a suppression list is and why it decides your deliverability

Removing an address from a list versus adding it to a blocklist. Sounds cosmetic, right? It is not. Removal leaves a gap that the first CSV export from six months ago will fill. A block stays on the account no matter how many times the same address comes back in later imports. One protects your database for a week. The other protects it for years.

And a repeat send to someone who said no rarely ends with another unsubscribe. It usually ends with a click on “this is spam”. Complaints hit sender reputation faster than hard bounces do. Filters treat a bounce as a hygiene error – unpleasant, but mechanical. A complaint is a signal from a human being that the content is unwanted, and mailbox providers weigh it far more heavily.

That is why a suppression list is part of your deliverability infrastructure, not a compliance box ticked once a year. It decides whether your campaigns reach the inbox at all with the large providers. It is worth checking how the email platform features handle blocks at account level, before your database grows to a size where manual patching stops making sense.

What the law says: GDPR, PKE article 398 and consent in B2B

The GDPR rule is short: consent must be as easy to withdraw as it was to give. If signing up for the newsletter took one field and one click, unsubscribing cannot require a login, a survey and a call to customer service. This is part of the minimum you have to implement in email marketing before the first campaign goes out.

The Polish Electronic Communications Law adds article 398 on consent for commercial information: sending commercial information by electronic means requires the recipient’s prior consent. A company address changes nothing here. contact@ or office@ are not a magic loophole, and B2B is not an exception to the consent requirement. This is the most common misunderstanding we hear during implementations.

Withdrawal of consent has to be documented. Record the date, the channel and the source of the request. An objection to direct marketing takes effect immediately and is not subject to any assessment of merit – you have no right to weigh it or postpone it to the next billing cycle.

So the suppression list plays two roles at once. Technically it blocks the send. Formally it is proof that the request was accepted and carried out, with a date. Without the second one, at the first audit or complaint you are left with one word against another.

Where unsubscribes actually come from

The unsubscribe form is only one channel. And not the busiest one. Opt-outs reach you along several roads at once:

• the List-Unsubscribe link in the message header, handled by the mail client,
• the unsubscribe page in the campaign footer,
• the “this is spam” button at the mailbox provider,
• the feedback loop from the provider, passing on reported complaints,
• a plain email reply, often a single sentence,
• a phone call or a conversation with a sales rep,
• a form or a toggle in the customer panel.

The List-Unsubscribe and List-Unsubscribe-Post headers give a one-click unsubscribe executed directly by the mail program. The recipient never visits your site, so your form will never learn about it unless you handle the request on the server side.

It is the same with a complaint filed at the provider: it does not reach you on its own. You either pick it up from the feedback loop or you do not pick it up at all, and the address stays in the campaign.

But most repeat sends come from opt-outs reported outside the system: in the CRM, at the service desk, at a sales meeting. Someone noted them down and nobody moved them into the platform. Hard bounces are a separate category. The address does not exist, so it is not a refusal, but it cannot go back into a send either.

How to build a suppression list nobody can work around

Keep the list at account level, never at the level of a single list. A block pinned to a list disappears together with that list and does not protect the next one.

Check at send time, not only at import. Because several days can pass between uploading a file and starting the campaign, and in that time someone unsubscribes. Filtering at import is an optimisation. Filtering at send is a safeguard.

Normalise addresses before comparing them: lower case, whitespace trimmed on both sides. On dots and plus signs in the local part, make a deliberate decision and write it down, because different providers treat them differently, and silent inconsistency creates holes. Store a hash alongside the address – that way, after a data deletion request, you still block the send without keeping the address in the clear.

For clients who ask to have an entire company excluded, plan for a block at domain level. Design the list itself as an append-only structure: deleting an entry has to require a justification and leave a trace in the log.

Tip: before a campaign starts, compare the recipient count after blocks are subtracted with the count before. A sudden jump upwards in available addresses usually means one thing – someone uploaded an old database.

Importing a database: the moment a struck-off address comes back

The scenario repeats down to the comma. A CRM export from six months ago, a new list, one click, and the addresses that unsubscribed in the meantime are back in the queue.

An import should reject blocked addresses silently and report how many it rejected. Without asking the operator whether to “really skip them”. A question asked at the end of a long import has one typical answer, and the suppression list is not a place for negotiation.

Do not buy databases and do not swap them. Consent cannot be transferred along with a file, and the other party’s suppression list stays with them – you get addresses with no information about who has already said no.

1. Check the source of the consent and exactly what it was given for.
2. Check the date of the consent; the older it is, the more careful you should be.
3. Weed out role and technical addresses: info@, noreply@, admin@.
4. Run the whole set through the suppression list.
5. Send to the freshest segment first and watch the reaction before you move on with the rest.

Tip: keep a column in the database with the source and date of consent. Without it, at the first complaint you have nothing to defend yourself with.

Many systems, one list: syncing with the CRM and the shop

The drift looks like this: the email platform knows about the unsubscribe, the CRM does not, and the sales rep adds the contact back into a campaign. Nobody is acting in bad faith, and the recipient gets an email they clearly refused.

The direction of the sync is set once and never changed. The suppression list is the source of truth. Other systems may add to it and may read from it, but none of them has the right to overwrite it with its own state.

Information about an unsubscribe should go to the CRM by webhook immediately, not in a nightly export. A dozen or so hours of delay is, in practice, one campaign too many. Before you design the flow, check the list of available integrations to see whether your CRM and shop connect directly, or whether you need to plan for data exchange over the API.

Transactional email is a different category. An order confirmation, an invoice or a password reset go out despite a marketing opt-out, because they fulfil a contract, not a promotion. A newsletter does not. For that separation to work and to be provable, split consents into types: newsletter, partner offers, product notifications. Unsubscribing from one type must not wipe out the others.

And when the platform has no ready integration with your CRM? The standard way out is exporting the suppression list over the API and comparing it periodically on the CRM side – simpler to maintain than manual copy-pasting and easier to audit.

Signs that your suppression list is leaking

A suppression list rarely breaks with a bang. It leaks quietly, and the symptoms show up in the statistics before they show up in complaints.

• A rising share of complaints at an unchanged send volume.
• Complaints concentrated in time and at a single mailbox provider, usually right after an import.
• Replies along the lines of “I asked to be unsubscribed a month ago” in the reply inbox.
• A drop in deliverability to one specific domain with correct SPF, DKIM, DMARC, a matching Return-Path and a PTR record in place.

That last point is the most confusing. Technical configuration does not fix a consent problem. You can have authentication set up perfectly and still land in spam, because the people on the other side are reporting your messages.

First hand: with our own fleet of sending servers, a block at a large filter almost always starts with a rise in complaints, not with a DNS error. Getting out of it means warming up from zero and weeks of careful, small sends to the most engaged segment. It is cheaper not to send one campaign than to rebuild the reputation of an IP address.

A caveat we repeat to clients: no suppression list and no configuration guarantees getting past the filters. What they do is reduce the reasons for a filter to kick in.

Summary: the suppression list as part of the product, not an add-on

An unsubscribe is a decision by the recipient, not a fault to be fixed with another campaign. The sooner the team accepts that, the less time goes into looking for workarounds.

Three things to do right away: one suppression list for the whole account instead of blocks scattered across lists, a block check at send time, and a procedure for adding opt-outs reported outside the system – by phone, by email, through a sales rep.

Honestly about our limitations: some integrations with external systems and automatic feedback loop handling are on our roadmap, not in the panel. We say so plainly, because we would rather you planned a workaround than discovered the gap mid-migration. If you want to see what works today, take a look at the MailCraft email marketing platform and compare it with the list above.

One last thing, which comes up in every deliverability audit: a smaller database of people who want your messages delivers more than a large one full of people who have already said no.