What a marketing suppression list is (and what it isn’t) under UK GDPR
A marketing suppression list is a record of people you must not market to. In practice, it usually contains just enough information to recognise someone and stop future marketing—often an email address, phone number, postal address, or a hashed version of these—plus the reason (for example, “opted out” or “objected to marketing”) and a date. Under UK GDPR, it’s typically used to help you respect an individual’s preference and avoid re-adding them to campaigns by mistake.
It isn’t a “do not contact” list you can share around to help other organisations market more safely. A suppression list is generally specific to your organisation (or your group/processor acting on your behalf) and should be tightly controlled. It also isn’t a place to store extra marketing data “just in case”. If someone has opted out, keeping additional profiling, segmentation notes, or purchase history inside the suppression file is hard to justify and increases risk.
It also isn’t a workaround to keep sending messages. If a person has objected to direct marketing, that objection should be honoured across relevant channels. The suppression list supports that by preventing future sends, rather than enabling new ones.
Finally, a suppression list isn’t the same as a general “unsubscribe list” inside an email platform. It can include multiple channels and must work across systems (CRM, email tool, SMS provider) so that an opt-out captured in one place is respected everywhere.
When you should add someone to suppression (unsubscribe, objection, erasure, wrong person, risk flags)
Add a contact to your suppression list whenever you have a clear signal that they should not receive marketing from you again, or when continuing to market to them could create unnecessary risk. Suppression is about remembering “do not contact” without keeping full marketing records.
Unsubscribe (opt-out): If someone clicks an unsubscribe link, replies “stop”, changes preferences to “no marketing”, or asks verbally to stop, suppress them for the relevant channel (email, SMS, phone, post). Keep a minimal record so you don’t re-add them later.
Objection to marketing: If a person objects to direct marketing (even without using the word “object”), treat it as a stop request and suppress promptly. This includes objections to profiling for marketing purposes.
Erasure requests: If someone asks you to delete their data, you may still need to retain a limited suppression record (for example, email address and date) to ensure you respect the request and don’t market to them again. Don’t use the suppression record for any other purpose.
Wrong person / misdirected contact: If you learn an address or number belongs to someone else, is shared, or is being used incorrectly, suppress it to prevent repeated mistakes and complaints.
Risk flags: Suppress contacts linked to complaints, harassment concerns, vulnerable individuals, suspected fraud, or data accuracy issues (e.g., bounced emails indicating reassignment). Also suppress where consent can’t be evidenced or lawful basis is unclear, until resolved.
How to design a suppression list that works across CRM, email, enrichment, and ad platforms
Start by treating suppression as a single “source of truth” dataset, then syncing it outward. Create one master suppression table (in your CRM, CDP, or a lightweight database) with stable identifiers and clear reasons, and ensure every tool checks it before processing.
- Use multiple identifiers: store email (normalised to lowercase), phone (E.164 where possible), CRM contact ID, and hashed versions (SHA-256) for ad platforms that require hashing. Keep a “last seen” value to help match messy records.
- Capture the legal/operational reason: e.g. “opt-out,” “do not contact,” “complaint,” “hard bounce,” “unknown consent,” plus the timestamp and source (web form, call, import, ESP).
- Separate channel flags: email, SMS, phone, post, and ads. This prevents over-blocking (e.g. email opt-out shouldn’t automatically suppress postal marketing unless your policy says so).
- Define precedence rules: suppression should override enrichment, scoring, and campaign inclusion. If a record is suppressed, enrichment tools should be blocked from appending or re-activating it.
- Sync pattern: push daily (or near-real-time) to your ESP and CRM; export hashed identifiers to ad platforms as “do not target” audiences; feed enrichment vendors a suppression file/API so they can exclude matches.
- Governance: restrict edit permissions, log changes, and run weekly audits for duplicates, formatting drift, and mismatched IDs across systems.
How to implement suppression end-to-end: fields, identifiers, hashing, sync rules, and audit trail
Core fields: store only what you need to prevent re-contact. Typical suppression record: suppression_id, identifier_type (email/phone/postal), identifier_value (or hash), scope (channel/brand/region), reason (unsubscribe/objection/complaint), source_system, captured_at, effective_from, expires_at (if applicable), status (active/revoked), and last_checked_at.
Identifiers: use stable, contactable identifiers. For email, normalise before matching (trim, lowercase, remove surrounding whitespace). For phone, store in E.164 format. For postal, consider a structured key (postcode + house number/name) rather than full address where possible.
Hashing: to minimise exposure, store a keyed hash (HMAC-SHA-256) of the normalised identifier. Keep the secret key in a managed vault and rotate with a versioned hash_key_id. Avoid unsalted plain hashes (they’re easier to reverse via lookup tables). Keep the raw identifier only if you genuinely need it for operational handling, and lock it down.
Sync rules: treat suppression as the “highest priority” signal. Push suppression events near-real-time to CRM, ESP, SMS, ad audiences, and data warehouse. Use idempotent upserts keyed on identifier_hash + scope. On import, always check suppression before creating/updating marketing profiles; block re-subscription unless you have a clear, recorded change of preference.
Audit trail: log every create/update/revoke with who, when, what changed, request_source (web form/call centre/API), and proof reference (ticket ID). Keep immutable logs (append-only) and monitor for sync failures with alerts and retry queues.
Suppression list vs deletion vs “do not contact”: choosing the right approach for each request type
In UK GDPR marketing, these three actions solve different problems. Picking the right one depends on what the person asked for and what you need to prove compliance.
- Suppression list: Keep a minimal record (typically email/phone and a “do not market” flag) so you can stop future marketing and show you respected an objection/opt-out. This is usually the best fit for “unsubscribe”, “opt out”, “stop emailing me”, or “object to marketing”. It helps prevent re-adding the contact from another source or list refresh.
- Deletion: Remove personal data you no longer need. This fits “please delete my data” or “erase me”, but in marketing it’s rarely as simple as wiping everything—if you delete without any suppression marker, you may accidentally market to them again later. Many organisations delete most fields but retain a small suppression record to honour the request.
- “Do not contact” status: An internal label that can cover more than marketing, e.g., “do not call”, “do not post”, or “no contact at all”. Use this when someone requests channel-specific stops or broader contact restrictions. It should still be enforced via your suppression logic (so it’s actionable, not just a note).
Quick mapping: “Unsubscribe” → suppression; “Delete everything” → delete + retain minimal suppression; “Don’t call me” → do-not-contact for phone + suppression for telemarketing; “Stop all marketing” → suppression across all channels.
Suppression list FAQs (UK GDPR, PECR, retention, access controls, and common edge cases)
What is a suppression list?
A suppression list is a “do not contact” record used to ensure you don’t send marketing to people who have opted out, objected, or unsubscribed. It’s typically kept separate from active marketing lists.
Do UK GDPR and PECR allow keeping suppression data?
Yes, keeping minimal data to respect an opt-out is generally compatible with UK GDPR principles (especially purpose limitation and data minimisation) and supports PECR compliance by preventing further marketing.
What should be stored on a suppression list?
Usually a unique identifier (email address, phone number, or hashed version), the channel(s) suppressed (email/SMS/calls), date/time, source (unsubscribe link, support request), and any relevant preference (e.g., “no third-party marketing”). Avoid storing full profiles.
How long can we retain it?
There’s no single fixed period. Many organisations retain suppression entries for as long as they market via that channel, because deleting them can lead to re-contacting someone who opted out. Review periodically and document your rationale.
Who should have access?
Restrict access to staff and systems that need it (e.g., CRM admins, email platform). Use role-based permissions, audit logs, encryption at rest/in transit, and strong controls for exports.
What if someone asks for deletion?
You may still need to keep a minimal suppression record to ensure you don’t market to them again. Explain what you’ll retain (and why) in plain language.
Edge cases: multiple emails, shared inboxes, and re-subscribe?
Suppress each identifier provided (including aliases). For shared addresses (e.g., info@), treat requests carefully and record context. If someone re-subscribes, keep evidence of the new consent and update suppression status for that channel only.