What is a suppression list?

A suppression list is the set of addresses a sender has decided not to mail again, checked before every send. If an address is on it, the message is never transmitted.

It exists because the alternative — re-sending to addresses that have already rejected you — is the fastest way to destroy a sending reputation, and it almost never happens on purpose. It happens because a retry loop had no memory.

What belongs on one

Hard bounces. A permanent rejection means the address does not exist or will not accept your mail. See hard bounce. Added on the first occurrence, not after three.

Spam complaints. Someone pressed “report spam” and their provider told you through a feedback loop. This is the single strongest negative signal a receiver has, and mailing that person again is worse than the original complaint.

Unsubscribes. For anything with an unsubscribe, honouring it is not optional, and honouring it means enforcing it at send time rather than filtering a list before an export.

Manual additions. Someone emailed asking to be removed. A domain asked to be excluded. A support case where the right answer is “stop”.

What does not belong on one

Soft bounces, until they have failed repeatedly over a sustained period. A full mailbox is not a decision.

Addresses that never opened anything. That is an engagement judgement for marketing mail, and for transactional mail it is meaningless — nobody opens every receipt, and the next password reset still has to arrive.

A whole domain, because one address at it bounced. Common accident when suppression is keyed loosely.

Why it has to be enforced at send time

A list that is consulted when someone remembers is not a suppression list. The value is entirely in it being a gate every message passes through, in the sending path, with no way around it:

send request
  → is the recipient suppressed?  ── yes ──→ never transmitted, recorded as suppressed
  → no
  → authentication checks
  → transmitted

Put anywhere else, it fails in exactly the situation it exists for — an automated retry, a re-import of an old list, a job that runs twice.

Suppression and transactional mail

Suppression is usually described as a marketing concern, which leaves a real question unanswered for transactional email: if someone marked your last receipt as spam, should the next password reset be suppressed?

Mechanically, yes — the complaint applies to you as a sender, and sending again compounds it. Practically, this is the moment your product needs to know. An address that can no longer be mailed is an account that can no longer reset its password or receive a receipt, and that fact belongs in the product, not only in a log. The failure to avoid is the silent one, where the system reports success because it suppressed the message rather than because anyone received it.

This is also the strongest argument for keeping transactional and marketing streams separate: a complaint about a newsletter should not be what stops a security alert from arriving.

What a usable suppression list looks like

• Per account, never shared between customers of a provider.
• Visible and exportable, so you can answer “why did this person not get their email”.
• Attributed — each entry records why it was added and when. “Suppressed” with no reason is unactionable.
• Reversible by you, for the cases where you know the address is fixed.
• Not counted against your volume. A message that was never transmitted did not use anything.

Pharos suppresses on hard bounce and complaint automatically, per account, and suppressed sends do not count against a monthly allowance. The features page covers what is visible in the log.