What is a suppression list? The practical difference from Suppressed contact

What is a suppression list? The send-safety layer between a contact and a message

The important distinction is that suppression is a send-eligibility state, not necessarily a consent state and not the same as deleting a contact. A person can remain in your database, retain order history, and even have historical marketing consent while a particular email address is suppressed because it is not safely deliverable.

Suppression answers "may we send this message now?"

A contact record answers questions such as who the person is, what they bought, and what permissions they granted. A suppression layer answers a narrower operational question: > Should this sending system attempt this channel and message class to this destination? That makes suppression a derived decision surface. It can combine several independent facts:

When all of those facts are flattened into a single boolean, teams lose the reason and cannot make safe exceptions later.

Consent and suppression can disagree without contradiction

Consider 4 contacts:

Contact B shows why a suppression list is not just an unsubscribe list. The person may still have an affirmative consent record, but the endpoint has failed permanently. Contact C shows the reverse. The mailbox works technically, but marketing should stop because the person opted out.

The contact record preserves both dimensions instead of overwriting consent when a bounce arrives or clearing a bounce because somebody later checks a marketing-consent box.

Suppression has scope

Suppression is not always global. Amazon SES currently supports suppression at account and tenant scopes, with configuration-set behavior that can override broader settings. Its automatic reasons include hard bounce and complaint. That is an infrastructure example of a broader design principle: the same address can be allowed in one sending context and blocked in another, depending on policy.

Other sending systems can expose a different scope, such as global or list-specific preference behavior, while keeping deliverability suppression separate from ordinary list preference. The schemas differ, but the design lesson is the same: a useful record needs a scope field rather than only email_address. The schemas differ, but both illustrate why a useful suppression record needs a scope field rather than only email_address.

Some suppressions should outrank consent changes

Suppose an address hard bounces today. Tomorrow, a webhook from an ecommerce platform says the customer is subscribed to email marketing. If the integration simply sets suppressed=false whenever consent becomes true, the platform will resume sending to an address it already knows is undeliverable. A safer eligibility model is conceptually:

can_send_marketing =    marketing_consent_is_valid    AND not_unsubscribed    AND not_complaint_suppressed    AND not_delivery_suppressed    AND destination_is_present

A new affirmative consent event can change the consent dimension. It should not silently erase an independent hard-bounce fact unless the system has reliable evidence that the destination was corrected or the prior failure was wrong.

Transactional messages expose the need for reason-aware suppression

Some systems allow transactional messages to recipients who opted out of marketing because the user still needs receipts, password resets, or account notices, while hard-bounce, repeated-soft-bounce, or spam-complaint suppressions can prevent delivery. That is a provider policy distinction, not a universal exception. That behavior should not be copied as a universal rule, but it illustrates the architecture well:

• marketing unsubscribe: may block promotional mail while still allowing necessary service messages under applicable rules
• invalid destination: should block attempts regardless of whether the content is promotional or transactional
• spam complaint: deserves stronger caution than an ordinary topic preference

The correct decision depends on reason, message purpose, provider behavior, and applicable law.

Provider suppression lists can change metrics

Infrastructure-level suppression can affect what your dashboard counts. Amazon SES says messages sent to addresses on the account-level suppression list do not count toward its Reputation.BounceRate or Reputation.ComplaintRate metrics, though they can still count toward sending quota and other event metrics. SES also keeps account-level suppressed addresses until they are removed, subject to documented account-state behavior.

This means suppression is not only a delivery control. It can also change the population that reaches reputation calculations. When comparing metrics before and after enabling suppression, document the measurement change.

How suppression should work in a multi-system stack

A merchant may have:

• ecommerce platform consent
• marketing platform campaigns
• transactional provider
• support desk
• CRM imports
• warehouse or loyalty systems

If one system receives a hard bounce or unsubscribe but another system can still send the same marketing traffic, the suppression is incomplete. A reliable architecture should:

1. capture the event at the source
2. normalize reason and scope
3. make suppression idempotent
4. propagate to every system that can originate the affected messages
5. prevent later imports from accidentally clearing the state
6. preserve the original reason for audit and support
7. define an explicit reactivation path by reason

Suppression list versus unsubscribe list

An unsubscribe list is usually preference-driven. A suppression list is broader. An unsubscribe can be one suppression reason, but suppression may also come from:

• bounces
• complaints
• invalid-address intelligence
• manual safety blocks
• provider policies

This is why "download unsubscribes" and "download suppressions" are not automatically interchangeable operations.

Worked example

A customer, Priya, buys from a store and checks the marketing opt-in box.

• State on Monday:

marketing consent: yesemail deliverability: healthymarketing suppression: no

• On Tuesday, the address hard bounces:

marketing consent: yesemail deliverability: hard bouncemarketing suppression: yes, reason=hard_bounce

• On Friday, a stale CRM import re-imports Priya as subscribed=true

A bad system clears suppression because the imported consent field is true. A good system sees no new evidence that the endpoint is deliverable and keeps the hard-bounce suppression.

If Priya later provides a corrected email address, the new destination gets its own delivery state. You do not need to erase the historical failure to resume communication safely.

What Suppression list requires

Common mistakes

1. Treating suppression as deletion
2. Storing no reason or timestamp
3. Letting a fresh list import clear a deliverability suppression
4. Using one global boolean when the system needs channel or list scope
5. Allowing marketing opt-in to override a spam complaint automatically
6. Sending transactional mail to an address known to be invalid simply because the message is transactional
7. Failing to propagate suppression across multiple senders
8. Comparing bounce/complaint metrics without accounting for suppression behavior

Questions we get asked