Suppression Lists: Why One Check Is Not Enough

What is a suppression list, and what belongs on it?

A suppression list is the register of companies and people your outbound is not allowed to reach. Five categories belong on it: existing customers, open deals already in the pipeline, closed-lost accounts, anyone who explicitly asked not to be contacted, and competitors the client wants excluded. Anything missing from it becomes a message someone regrets.

The list arrives from the client, and asking for it is part of the engagement rather than an afterthought. In practice it is rarely one file. A CRM export covers customers and deals, a separate sheet covers do-not-contact requests, and the competitor exclusions often exist only in someone's head until you ask the question directly.

What matters more than completeness on day one is that the list has an owner and a place. A suppression list that lives in an email attachment is a suppression list that will be out of date the first time it matters.

Why does one suppression check miss contacts you meant to exclude?

Because a company and a contact can reach you through different domains. Screening only the company website domain lets through a contact whose email sits on a subsidiary or alternate domain. Screening only the email domain lets through a named account whose contact record carries no address yet. You need both, at different levels.

The two-level rule closes three gaps at once. It stops contact through an alternate domain, it stops a domain mismatch from bypassing an exclusion the client already granted, and it makes the exclusion auditable, because you can name which level caught which record.

It also has to run on the same list every time. A check applied to the first batch and skipped on the refresh is not a gate. It is a one-off.

When in the pipeline does the check have to run?

Before anything expensive or irreversible touches the record. That means earlier than most teams place it: not before the send, but before a buying signal is allowed to proceed, before a lead is scored, and before any paid enrichment runs. Suppression at the sending tool is already too late.

The ordering matters for money as well as for trust. Paid enrichment bills per record, so enriching a customer you were never allowed to contact is a charge with no possible return. Scoring a suppressed account pollutes the prioritisation everyone downstream trusts. Both are silent costs.

The rule we hold to is blunt: no qualified signal ever enters an outreach tool, a sequence, or a scoring model until both suppression checks have passed. It reads as bureaucracy right up to the first time it catches a live customer.

What happens to a record that fails the check?

It gets flagged with a reason and held. Never deleted, never silently dropped. The record keeps a suppression flag and a suppression reason, stays in the file, and moves out of the active send list into a hold pile that somebody owns. The count you can actually contact falls out of that flag.

Deleting looks tidier and costs you the audit trail. Six weeks later, when someone asks why a named account never appeared in a campaign, a flag with a reason answers the question in seconds and a deleted row cannot answer it at all. The client also changes their mind: a competitor exclusion gets lifted, an account moves from closed-lost back to open. Flagged records can be released. Deleted records have to be sourced again.

Which name and data defects should stop a record from shipping?

Anything a recipient would notice. A broken or abbreviated first name, a surname sitting in the first-name field, a title left inside the name, an unresolved salutation, or an enriched email that may belong to a different person entirely. Each of these is visible in the first line of the message.

The mechanics are unglamorous and they decide whether the list is send-ready. First and last name present and not swapped, which a forename check on both tokens catches. Titles and academic credentials stripped out. Casing normalised, so a fully upper-case surname is title-cased while particles like von or van keep their form. Gender resolved only at high confidence where the salutation needs it, left blank otherwise.

One flag deserves its own mention because it is easy to miss: where the enriched email's first name matches but the surname starts with a different letter than the source initial, the address may belong to someone else at the same company. That record gets held for a human, not sent on a guess.

What do the mailbox providers actually require?

Less tolerance than most outbound plans assume, and the numbers are published rather than folklore. Spam complaints and bounces both have hard ceilings, and crossing them costs the sending domain its reputation rather than a single campaign. The suppression gate exists to keep you inside those ceilings.

Google's own sender guidelines are unusually specific for a platform document. Bulk senders must keep spam rates reported in Postmaster Tools below 0.3%, with below 0.10% given as the level to aim for, and senders above 5,000 daily messages must have SPF, DKIM and DMARC in place, with marketing messages carrying one-click unsubscribe. Mailshake's benchmark work puts hard bounces below 0.5% and describes a total bounce rate under 1% as the minimum expectation rather than an aspiration. Read together, the two sources describe a narrow corridor. A single campaign to a list containing existing customers and stale addresses can push a domain out of it, and the domain does not recover on the timeline of the campaign that damaged it. A suppressed customer who reports the message costs more than the record was ever worth, and the complaint lands on the domain rather than on the campaign. That asymmetry is the whole argument for a gate: cheap to run, expensive to skip.

Where the discipline holds, the result shows up in the pipeline rather than in a cleaner file. From Manual Outreach to AI-Automated Sales Pipeline in less than 6 months is the worked example from SalesPlaybook's own client list.

How do you keep the suppression list current?

By treating it as a live feed from the CRM rather than a file someone sends once. Customers are won, deals open, requests to stop arrive. Every one of those events changes who you are allowed to contact, and a static export is already wrong by the time the second campaign launches.

Practically that means three habits. Re-pull the suppression source before every batch rather than per engagement. Keep the already-in-pipeline export in scope, not just closed customers, because contacting an account a colleague is actively working is the most embarrassing category of all. And log the count at every pull, so a sudden change is visible instead of silent.

Suppression also belongs in the same place as the rest of the list logic. If the sourcing lives in a HubSpot CRM setup, the check reads the same properties the workflows read, which is what makes it auditable. The steps on either side of the gate are covered separately: waterfall enrichment only runs on records that have passed it, a pipeline generation plan counts what is left, and the same two-level rule applies to LinkedIn GTM sequences rather than to email alone. Our approach to B2B pipeline generation puts this gate before the first sequence rather than after the first complaint, and the AI outbound work inherits it rather than working around it.