Suppression list
Unsubscribes, hard bounces and complaints in one file that must be imported before the first campaign on any new platform.
A suppression list holds unsubscribes, hard bounces and complaints. Import it before the first campaign on a new platform; it is the most common migration failure.
A suppression list holds unsubscribes, hard bounces and complaints. Import it before the first campaign on a new platform; it is the most common migration failure.
All glossary terms
The short version
- A suppression list is a durable record of people or addresses that must never be contacted again, with the reason and the date attached.
- It is not an opt-in list, not a segment and not a bounce log. Opt-in records permission; suppression records a prohibition that overrides permission.
- A suppression must propagate to every channel and every system that can send: email, WhatsApp, SMS, voice, the CRM, ad audiences and each sub-processor.
- Under the DPDP Act a withdrawal of consent must be honoured, and the suppression marker is the evidence that you did. Keep the minimum needed to avoid contacting the person again.
- The most common failure is migration: a new platform is loaded with contacts before the suppression list is imported, and the first campaign mails the people who asked never to be contacted.
- Measure leakage and time-to-propagate, not the size of the list. A large list is normal; a leak is an incident.
Suppression list, defined as a prohibition
A suppression list is a record of contact identities that must be excluded from sending. Each entry carries an identifier, a scope, a reason and a timestamp. The identifier might be an email address, an E.164 phone number, a WhatsApp number or an internal contact id. The scope says which channels and which purposes the prohibition covers. The reason distinguishes an unsubscribe from a complaint, a hard bounce, a legal request or an internal do-not-contact instruction. The timestamp matters when someone asks how quickly the request was honoured.
The defining property is that suppression wins. It overrides an opt-in, a segment rule, an imported list, a sales instruction and a clever campaign idea. If a contact is suppressed for email marketing, no workflow should be able to mail them by selecting a different segment. That sounds obvious and is exactly where systems fail, because suppression is often implemented as a filter on one campaign builder rather than as a constraint on the sending path.
What a suppression list is not: it is not a preference centre, although the two are related. It is not a segment of low-engagement contacts, which is a marketing choice and reversible. It is not the bounce log, which contains failures that may be temporary. And it is not the consent ledger, which records what a person agreed to. The suppression list is the narrow, durable record of what must not happen.
What belongs on the list, and with what scope
The core entries are unambiguous: an unsubscribe request, a spam complaint, a hard bounce, a regulatory do-not-contact instruction and a legal or internal request to stop contact. Add a withdrawal of consent under DPDP, which may be broader than a marketing unsubscribe. Add deletion requests, where the personal data is erased but a minimal suppression marker remains so the person is not re-added by a later import.
Scope is the hard part. A person who unsubscribes from a newsletter has not necessarily withdrawn consent for a transactional receipt or a service call about an open ticket. A person who asks a sales representative never to call again may still expect order updates. A person who opts out of WhatsApp marketing may still want a delivery notification. The suppression record should therefore carry a channel and a purpose, not just a global flag, unless the request was explicitly global.
The safest default is to record the broadest interpretation the person actually expressed, and no broader. If the wording was stop all marketing, suppress marketing across channels. If it was stop these emails, suppress email marketing and keep service messages. Write the rule in the preference centre so the person can see what they chose. Then make the technical scope match the words, because a mismatch is what turns a routine request into a complaint.
Suppression is not opt-in, and not a consent ledger
Three records are often collapsed into one table and should not be. Opt-in records permission: this person agreed to receive this kind of message on this channel, under this notice. A consent ledger records the events that created, changed or withdrew that permission, with the notice version, the collection point and the timestamp. A suppression list records a prohibition that overrides permission. They are related, but they answer different questions and have different retention.
The distinction matters in an audit. If a customer says they never opted in, you need the consent ledger. If a customer says they asked you to stop and you kept mailing, you need the suppression record and the send log. If a regulator asks how you honour withdrawals, you need the propagation evidence. A single boolean called subscribed cannot answer any of the three well, because it loses the reason and the time.
The practical design is a contact identity with three related stores: consent events, suppression records and the sending log. The sending path checks suppression first, then consent, then the campaign audience. That order matters because a suppressed contact must not be re-permissioned by an import, and a consent record must not silently override a complaint. Suppression is the veto.
Propagation: every channel, every sender
A suppression that lives in one tool is not a suppression. The average Indian company sends through an email service provider, a WhatsApp BSP, an SMS aggregator, a voice dialler, a CRM and a support desk, and may also push audiences to advertising platforms. Each of those systems can contact a person. Each one needs to receive the suppression, and each one needs to acknowledge it.
The architecture is a central identity store with a suppression table and a fan-out job. When a suppression is written, the job pushes it to every connected sender with an idempotent identifier and a version. The sender acknowledges, and the job records the acknowledgement. If a sender is down, the job retries and the send path for that channel should fail closed, meaning it refuses to send until the suppression state is known. Failing open is how a complaint becomes a regulatory complaint.
Advertising audiences are the channel teams forget. Uploading a customer list to a ad platform to build a lookalike audience can re-contact someone who unsubscribed, even though the ad is not an email. If the platform supports exclusion lists, push the suppression there too. If it does not, do not upload the list. The same logic applies to data clean rooms and partner integrations.
Identity resolution across channels
The same person can appear as two email addresses, a phone number, a WhatsApp number and a CRM record with a different spelling of their name. A suppression keyed only to the email address will not stop a WhatsApp message to the phone number on the same record. Identity resolution is therefore part of suppression design, not an optimisation for later.
The practical approach is a canonical contact id with channel identifiers attached. Suppress the canonical id when the request is global, and suppress the specific identifier when the request is channel-specific. Normalise phone numbers to E.164 with the country code, lower-case email addresses, and keep aliases linked. If a person has two emails and unsubscribes from one, decide whether the other should be suppressed based on the wording of the request; the safer default for a marketing unsubscribe is to suppress the person, not just the address.
Hashed audiences complicate the picture because you cannot push a plain identifier to the ad platform. You push a hash, and the platform matches it. That works only if the hash is computed from the same normalised value the platform expects. A suppression list that hashes a phone number with a different country-code format will silently fail to match, and the person will see the ad. Test the match rate before trusting the exclusion.
The Indian legal and platform layer
Under the DPDP Act, a data principal can withdraw consent, and the data fiduciary must honour the withdrawal. The Act also gives rights to erasure and grievance redressal. A suppression list is the operational mechanism that makes withdrawal real, and the send log is the evidence that the withdrawal was applied. Keep the marker minimal: an identifier, the scope, the date and the source. You do not need the original marketing profile to prove that someone asked not to be contacted.
SMS in India adds the DLT and Do Not Disturb layer. Commercial SMS is filtered against the preferences subscribers set with their operators, and the principal entity is accountable for the traffic. A suppression list should incorporate DND status for SMS and should be checked before every send, not only at import. The DLT consent record and the DPDP consent record can share evidence, but they are not the same legal test, and one does not replace the other.
WhatsApp has its own rules: opt-in is required for marketing templates, the twenty-four hour service window governs free-form replies, and recipients can block or report. Email adds one-click unsubscribe expectations from large mailbox providers, implemented through the List-Unsubscribe and List-Unsubscribe-Post headers. Each platform has its own vocabulary, and the central suppression store has to translate all of them into one durable record.
Migration is where suppression goes missing
The classic failure is a platform migration. A team exports contacts from the old system, imports them into the new one, and starts a welcome campaign before importing the suppression list. The people who unsubscribed, complained or asked for deletion receive mail from a brand they had already asked to leave alone. The damage is disproportionate because it lands on the most sensitive segment of the list.
The safe sequence is suppression first, contacts second, campaigns third, with a verification gate between each step. Export the old suppression list with reasons and timestamps. Normalise identifiers. Import into the new store and reconcile the count against the source. Import contacts and immediately run a dry-run audience query to confirm that suppressed contacts are excluded. Only then enable sending. If the old platform cannot export suppression reasons, treat the whole old list as unverified and do not send until it is reconstructed.
Run the same discipline for a new channel. Adding WhatsApp does not inherit email suppression automatically, and adding a voice dialler does not inherit either. Each new sender is a new propagation target and a new opportunity for a leak. Add it to the fan-out list, test with a known suppressed contact, and record the test.
Operating the list without breaking sends
The write path should be fast, idempotent and auditable. A duplicate unsubscribe is not an error. A suppression written twice with the same reason should not create two rows. Every write should record the source, the channel, the scope and the time, and every propagation should record an acknowledgement. The send path should query the store with a short cache, and the cache should be invalidated on write or kept short enough that a new suppression applies within minutes.
Access control matters because suppression data is sensitive. Support agents need to add a suppression and see whether one exists. Marketing needs to see aggregate counts, not the whole list. Engineers need the sync health, not the identities. A single admin screen with full export is a data protection problem and an operational risk, because an export can be re-imported into the wrong system.
Review the list periodically for scope errors, not for re-permission. A suppression is not a lead to be re-qualified. The review should catch entries that were written with the wrong scope, duplicates from a migration, and channels that were never propagated. The output is a correction and a better test, never a campaign to win the person back.
Worked example: a migration that almost leaked
A sample run: a Mumbai D2C brand moves from one marketing platform to another with 42,000 contacts. The old system holds 3,400 suppression records: 2,100 unsubscribes, 600 hard bounces, 500 complaints and 200 internal do-not-contact entries. The team exports the list, normalises emails and phone numbers, and imports it before the contacts. The reconciliation shows 3,380 rows in the new store, twenty short.
The twenty are phone-only suppressions with no email address, and the new store’s import expected an email as the primary key. They are added with a phone identity. A dry-run audience for the first campaign returns 38,600 contacts, which matches the expected 42,000 minus the 3,400 distinct suppressed identities after deduplication. The send proceeds. The WhatsApp broadcast is held for a day because the BSP acknowledgement has not arrived, which is the fail-closed path working as intended.
Two weeks later a customer writes to say they had unsubscribed a year ago and received the campaign anyway. The investigation finds that their email had been re-added by a trade-show import with a different spelling and no suppression check. The fix is not an apology template; it is a check at import time that matches on the canonical identity and refuses to add a suppressed person. The suppression list was correct. The import path was not.
Measuring suppression health
Four numbers matter. Leakage is the count of sends to a suppressed identity in a period; the target is zero, and any non-zero value is an incident with a root cause. Time-to-propagate is the interval between the write and the last sender acknowledgement; it should be minutes for email and same-day for slower partners. Coverage is the share of active sending systems that have a confirmed sync. Staleness is the share of suppression entries with no source or date, which usually comes from a bulk import.
Add a periodic canary test. Pick a test identity, suppress it, and try to send through every channel. The test should fail at every sender. Run it after any integration change, any new channel and any migration. It is the cheapest way to catch a sender that was added to the campaign tool but not to the suppression fan-out.
The size of the list is not a health metric. A growing list can mean better hygiene or a tired audience. What matters is that every entry is respected, every channel is covered and every withdrawal is evidenced. A team that can show those three things has something an auditor will accept and a customer will believe.
Frequently asked questions
Is a suppression list the same as an unsubscribe list?
An unsubscribe list is one source of suppression. A suppression list also includes complaints, hard bounces, regulatory do-not-contact instructions, deletion requests and internal blocks. Unsubscribes are usually channel-specific; some of the other reasons are global. Treating the two as synonyms leads to a list that misses the entries that matter most.
Should a suppression apply to transactional email?
Usually not automatically. A marketing unsubscribe should stop marketing, while a receipt or a password reset may still be expected. A complaint or a global do-not-contact request is broader. Record the scope the person expressed and let the send path check the purpose as well as the channel. Blanket suppression of transactional mail can break a customer’s account recovery.
How long should we keep suppression records?
Keep the minimal marker for as long as you need it to avoid contacting the person again, and document the basis. Under DPDP, erasure requests can remove the marketing profile while a suppression marker remains for the purpose of honouring the objection. Do not keep the full profile just because the marker needs to exist.
Does a WhatsApp opt-out suppress email too?
Only if the person asked for a broader stop or your policy says so. A WhatsApp marketing opt-out is channel-specific by default. The central record should capture the channel and the purpose, then propagate to WhatsApp immediately and to email only if the scope justifies it. Guessing in either direction creates a bad experience.
Why do suppressed contacts reappear after an import?
Because the import path does not check the suppression store, or it matches on a different identifier. A trade-show list, a CRM sync or a manual CSV can re-add a person under a new spelling or a second email. Enforce the check at ingest, match on the canonical identity and reject rows that resolve to a suppressed contact.
How fast must a suppression propagate?
Fast enough that the next send does not include the person. For email that usually means minutes; for a WhatsApp BSP or a partner integration it may mean a few hours. If a sender cannot confirm within the window, the send path should fail closed for that channel. Document the target and measure the actual.
Should we tell people they are on a suppression list?
You should confirm that their request was received and will be honoured, which is different from exposing an internal list. A short confirmation with the scope and the channel is good practice and creates a record. Do not send a marketing message to confirm an unsubscribe, and do not require a login to complete a request.
Do ad platforms need the suppression list?
If you upload customer lists to build audiences or lookalikes, yes. The ad may not be an email, but it is still contact with a person who asked you to stop. Push the suppression to exclusion lists where the platform supports it, and do not upload a list you cannot exclude against. Test the match rate on hashed identifiers.
What is a canary test for suppression?
A controlled check where you suppress a test identity and then attempt a send through every channel. Every attempt should be blocked. Run it after adding a channel, changing a BSP, migrating platforms or altering the import path. It is the only reliable way to catch a sender that was connected to the campaign tool but not to the suppression fan-out.