Bounce handling series. This is the tactical guide to designing and operating suppression lists. For related guides on DSN parsing, bounce categorization, and feedback loops, see the bounce handling hub →
Quick suppression list reference
A suppression list is the do-not-send list that every legitimate sender maintains. Feeding it are three signals (bounces, complaints, unsubscribes); consuming it is every sending pipeline. Getting the schema, scope, retention, and audit right is the difference between a system that quietly protects reputation and one that leaks addresses back into campaigns and drives complaint rates up.
| Signal sources | DSN bounces, FBL complaints, List-Unsubscribe events, manual removals |
| Scope options | Global (all sending), per-brand, per-list, per-stream (marketing vs transactional) |
| Retention | Permanent for complaints and hard bounces; contextual for soft bounces |
| Consumption point | Every send, pre-flight check before any recipient enters the queue |
| Audit requirement | Verify quarterly that suppressed addresses never receive mail |
| Common risk | New import bypasses suppression, complaint rate spikes days later |
Every article in this sprint has been about how to detect problems. This one is about how to remember them. A suppression list is the persistent memory of your sending system: every address that ever hard-bounced, every recipient who ever complained, every unsubscribe click. Get the design right and it protects your reputation silently for years. Get it wrong and addresses leak back in at every import, complaint rates rise invisibly, and reputation drops without an obvious cause. This guide covers the schema, scope, retention, migration, and audit practices that make suppression lists work at scale.
What a suppression list actually is
A suppression list is a persistent record of addresses that must never receive mail from you. Not a marketing choice; a compliance and reputation obligation. Three functional properties:
- Additive. Once an address is on the list, it stays. Addresses are added, rarely removed. Removal requires explicit human decision, never automation.
- Pre-flight-checked. Every send, without exception, checks the suppression list before adding a recipient to the sending queue. No import, no manual add, no automation bypasses this check.
- Cross-source. Feeds come from multiple signals (bounces, complaints, unsubscribes). The list itself does not care about the source; the record includes it for audit but the effect is the same: do not send.
Distinct from “unsubscribed”: unsubscribed is a marketing state (opted out of a specific list or brand). Suppressed is an infrastructural state (do not send to this address ever, from any list). Every unsubscribe adds to the suppression list; not every suppression is an unsubscribe.
The three signal sources
Bounces (from DSN parsing)
Address failures (RFC 3463 code 5.1.x) are the primary bounce source for suppression. See our DSN parsing guide for extraction and our bounce categorization guide for the category rules. Suppress on:
- Any
5.1.xcode (bad address, bad domain). - Persistent
5.2.x(mailbox failure) after 5+ occurrences. - Not on
5.7.x(policy) or5.6.x(content), which are sender-side issues.
Complaints (from FBL)
Every ARF report generated by a feedback loop should add the recipient to the suppression list immediately. See our FBL guide for signup and parsing. Complaints signal the recipient does not want your mail, and Google or Yahoo may retaliate against the domain if you continue sending. Suppression on FBL is not optional.
Unsubscribes (from List-Unsubscribe or preference pages)
Every unsubscribe event (via the List-Unsubscribe header, click on an in-message unsubscribe link, or preference center opt-out) adds the recipient to the suppression list. Unsubscribes may be per-list (unsubscribed from newsletter A but still receiving newsletter B) or global (unsubscribed from all mail). Design your suppression list to support both.
Manual removals
Human interventions: a customer service ticket asking for removal, a legal request, a rate-limited add from a “block sender” tool. These should also flow into the suppression list, tagged with source and reason.
Suppression list schema design
Minimum viable schema:
Table: suppression_list
address VARCHAR(320) NOT NULL -- max email length per RFC 5321
address_normalized VARCHAR(320) NOT NULL -- lowercase, trimmed, for matching
added_at TIMESTAMP NOT NULL
source VARCHAR(32) NOT NULL -- 'bounce', 'complaint', 'unsubscribe', 'manual'
source_detail VARCHAR(255) -- e.g. 'FBL:Yahoo', 'DSN:5.1.1', 'ListUnsub:newsletter_a'
scope VARCHAR(32) NOT NULL -- 'global', 'list:newsletter_a', 'stream:marketing'
original_message_id VARCHAR(255) -- for correlation to send log
reason_code VARCHAR(16) -- e.g. RFC 3463 code
UNIQUE INDEX (address_normalized, scope)
INDEX ON added_at
INDEX ON sourceKey design decisions:
Normalize the address for matching
Email addresses are case-insensitive in the local-part per RFC 5321 (in practice; some receivers preserve case). Lowercase the address for matching, but preserve the original casing in a separate column for logging and outbound formatting. Also strip Gmail-style plus-tags (user+tag@gmail.com and user@gmail.com are the same mailbox) if your business logic treats them the same.
Scope: global vs per-list vs per-stream
The scope column decides how the suppression applies:
- Global: Suppress from all mail, all lists, all streams. Use for complaints, hard bounces, and full-account unsubscribes.
- Per-list: Suppress from one specific list only. Use for granular unsubscribes (“unsubscribe from newsletter A but keep receiving order updates”).
- Per-stream: Suppress from marketing but allow transactional. Use for full marketing opt-outs where transactional (receipts, security) must still send. Legal risk here; consult privacy team.
Support all three. Every send pre-flight checks all applicable scopes (a marketing send from list A checks global + list:A + stream:marketing suppressions).
Preserve the source
Track why each address was suppressed. Auditability is required for compliance and for debugging patterns (“why did we suppress this address in bulk last Tuesday?”). The source column plus source_detail plus reason_code together give you the full story.
Preserve the correlation ID
original_message_id ties the suppression back to the send event that triggered it. Useful for post-hoc analysis and for reversing bulk suppressions if a bug caused false positives.
Storage patterns
Database (self-hosted)
For self-hosted senders or those needing full control: keep the suppression list in your primary database (Postgres, MySQL). Index on address_normalized for fast lookup at send time. At scale (10M+ suppressed addresses), consider a partitioned table or a separate suppression database.
ESP-hosted (delegated)
Every major ESP maintains its own suppression list on your account. When you use SendGrid, Postmark, Mailgun, or SES, the ESP’s suppression is authoritative for their sends. Add addresses via API; check via API. Trade-off: portability. If you migrate ESPs, export before switching.
Hybrid (both)
Common at scale: maintain your own master suppression list, sync it to every ESP you use. The master is portable and single-source-of-truth; the ESP-hosted copies enforce at their level. Sync direction is one-way (master to ESP); do not let ESP-side deletions propagate back.
The pre-flight check
Every send should query the suppression list before any recipient enters the sending queue. The check is fast (single index lookup) and non-negotiable. Pseudo-code:
def is_suppressed(address, list_id, stream):
normalized = normalize(address)
query = """
SELECT 1 FROM suppression_list
WHERE address_normalized = %s
AND (scope = 'global'
OR scope = 'list:' || %s
OR scope = 'stream:' || %s)
LIMIT 1
"""
return db.exists(query, [normalized, list_id, stream])
def enqueue_recipient(recipient, campaign):
if is_suppressed(recipient.email, campaign.list_id, campaign.stream):
log('suppressed_at_preflight', recipient=recipient, campaign=campaign)
return
queue.push(recipient, campaign)Any code path that adds recipients to a queue without this check is a leak. Common leak points to audit:
- CSV imports that push directly to the queue.
- API endpoints that accept recipient lists.
- Backfill jobs that re-queue old campaigns.
- Copy operations from one list to another.
- External integrations (CRM sync, webhook-triggered sends).
Retention policies
Different signal sources warrant different retention:
Permanent (never expire)
- Hard bounces (5.1.x address failures)
- FBL complaints
- Explicit unsubscribes (both global and per-list)
- Legal or compliance removals
Time-bounded (expire and re-evaluate)
- Persistent soft bounces (added after 5+ occurrences of same 5.2.x code) may be re-tested after 12 months. Some recipients cycle in and out of “mailbox full” status.
- Rate-limited manual removals (“block sender for 30 days”) should have explicit expiry.
Never expire, ever
Do not automate the removal of hard bounces or complaints, even after years. Google and Yahoo cross-reference complaint history when evaluating sender reputation, and a re-added complainer who complains again counts extra heavily.
Cross-ESP portability
If you migrate ESPs or use multiple simultaneously, your master suppression list needs to sync across all sending platforms.
Export format
Every ESP exports its suppression list in a standard-ish CSV format. Common columns: email address, bounce type or complaint type, timestamp. Some ESPs enrich with SMTP diagnostic codes or original Message-ID.
Import format
Same as export, into the new ESP. Watch for:
- Duplicate detection. The new ESP may already have some overlap; import de-duplicates on address.
- Format differences. One ESP’s “hard bounce” may map to another’s “invalid”.
- Rate limits. Large imports (100k+ addresses) may take days to process. Plan the migration timeline accordingly.
Ongoing sync
If you use multiple ESPs simultaneously, sync any new suppression from one to all others. Delay tolerance: minutes, not hours. A suppressed address that continues to receive from a different ESP still hurts your domain reputation, since Google and Yahoo look at the domain, not the specific ESP.
Testing compliance
Automated tests
Include suppression checks in your continuous integration suite. Sample test:
def test_suppressed_address_not_queued():
suppress('test@example.com', source='manual', scope='global')
result = enqueue_recipient(Recipient('test@example.com'), Campaign('test'))
assert result is None
assert 'test@example.com' not in queue.dump()
def test_per_list_suppression_scoped():
suppress('test@example.com', source='unsubscribe', scope='list:newsletter_a')
campaign_a = Campaign('campaign_a', list_id='newsletter_a')
campaign_b = Campaign('campaign_b', list_id='newsletter_b')
enqueue_recipient(Recipient('test@example.com'), campaign_a)
assert 'test@example.com' not in queue.dump()
enqueue_recipient(Recipient('test@example.com'), campaign_b)
assert 'test@example.com' in queue.dump()Manual audit
Quarterly: pick 100 random suppressed addresses. Verify none received mail in the past quarter. If any did, find and fix the leak point immediately. This is the single most important audit for suppression list correctness.
10 common suppression list mistakes
- Skipping the pre-flight check on imports. The most common source of leaks. Every CSV import must query the suppression list per address before adding to any queue.
- Suppressing on the wrong DSN category. Suppressing on
5.7.x(policy) or5.6.x(content) removes legitimate recipients because your own auth or content triggered the reject. - Not normalizing addresses. Case-mixed variants (
User@example.comvsuser@example.com) look different to a naive matcher. Normalize both stored addresses and query addresses to lowercase. - Removing suppressions after “cleanup”. The temptation to “clean” the suppression list to re-attempt old addresses is strong and always wrong. Suppression is one-way except for very specific business reversals with human decision.
- Storing suppression only in the ESP. If you migrate ESPs, the suppression list stays behind. Keep a master copy in your own database.
- Not distinguishing global vs per-list. Users who unsubscribe from newsletter A should still receive order confirmations. Users who complained should receive nothing. The scope column encodes this; use it.
- Not tracking the source. When you need to unsuppress a specific address (rare, but happens), knowing whether it came from a bounce, complaint, or manual removal decides whether it is safe.
- Not auditing quarterly. Silent leaks are the worst kind. Verify quarterly that suppressed addresses have not received mail.
- Not preserving correlation IDs. Without the original Message-ID, you cannot trace suppression back to the campaign or send event that triggered it. Analysis becomes impossible.
- Suppressing based on ESP category alone. ESP “hard_bounce” or “blocked” categories can conflate address failures with policy failures. Always check the underlying SMTP or DSN code before adding to suppression.
Suppression list FAQ
Can I ever remove an address from the suppression list?
Very rarely, and only with a specific business reason: a customer explicitly requests to receive mail again (a manual re-opt-in, well-documented), or you can prove the original suppression was a false positive (a bug added the address by mistake). Never automate removal, never “clean” the list to re-attempt old addresses. Google and Yahoo cross-reference complaint history, and re-adding a complainer who complains again counts against you extra heavily.
Should transactional email respect marketing suppression?
Depends on the suppression reason. Address failures (bounces) apply to all mail streams; if the mailbox does not exist, transactional cannot deliver either. Complaints and marketing unsubscribes are usually scoped to marketing; a user who complains about your newsletter still expects order confirmations and password resets. Design the scope column to differentiate: global suppression stops all sends, stream:marketing stops only marketing. Legal review recommended for the split policy.
How large can a suppression list grow?
Unlimited in principle. For a sender doing 10M messages per month with typical bounce and complaint rates, expect 100k to 500k new suppressions per year, accumulating over time. A 10-year-old suppression list can contain 5M+ addresses. Indexed properly, lookup remains sub-millisecond regardless of size. Storage cost is minimal (a few gigabytes for millions of records). Never purge old suppressions to save space; the storage is trivial compared to the reputation risk.
Do I need to maintain my own suppression list if my ESP has one?
Yes. The ESP suppression is scoped to that ESP; if you migrate or add a second ESP, you need a portable master list. Also, the ESP may include false positives (like conflating 5.7.x with 5.1.x) that your master can be more careful about. Third, your master lets you correlate suppressions across the full email operation, not per-ESP. Standard practice: maintain a master, sync one-way to every ESP.
What if a customer wants to receive mail after unsubscribing?
Handle it as a manual, deliberate re-opt-in. Require the customer to actively re-subscribe (through a preference center, a signup form, or an explicit customer service request logged as manual override). Document the request. Then create a new “manual_reopt_in” suppression source entry that supersedes previous suppressions. Do not simply delete the old suppression records; keep them for audit history.
How do I audit that suppression works?
Quarterly: pick a random sample of 100 to 200 suppressed addresses. Query your send log for any messages sent to them in the past quarter. Result should be zero. If any messages were sent, treat as an incident: find the leak point (imports, external integrations, backfills), fix it, and audit the last 6 months for pattern. Automate the audit if possible; a nightly job that samples the suppression list and cross-references send logs is easy to set up and catches issues fast.
Final words
A well-designed suppression list is the boring backbone of every reliable sender. It does not generate campaigns, does not drive revenue directly, does not have a dashboard executives care about. It quietly prevents your reputation from bleeding to death from a thousand small leaks. The three engineering choices that matter most: normalize addresses consistently, enforce pre-flight checks at every send path, and never automate removal.
The mental model to keep: suppression is the persistent memory of every “do not send” decision your system ever made. Bounces contribute (via DSN), complaints contribute (via FBL), unsubscribes contribute (via List-Unsubscribe), humans contribute (manual removals). The list itself is source-agnostic: an entry means do not send, regardless of how it got there.
This closes the bounce handling series. For the full picture, see the earlier articles: DSN parsing, bounce categorization, feedback loops. For related content, see hard vs soft bounces, the List-Unsubscribe header, Google Postmaster Tools, and the Deliverability hub.
The best suppression is the one you never need to add.
SMTPing catches disposables, role-based, catch-all, syntax errors, dead mailboxes and traps before you send. Fewer bad addresses at collection means a smaller, faster suppression list and less reputation risk. 13 validation types, 25 free daily.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
