What belongs on a suppression list, and for how long

A suppression list is the set of addresses you will not send to regardless of what your application asks for. It is the single most effective reputation control you have, and it is usually implemented as an afterthought.

The checking rule

Check suppression at send time, not at list-build time. The gap between building a batch and sending it is where a complaint arrives, and a batch assembled an hour ago does not know about it.

This has to be fast, because it is on the path of every message. An in-memory structure backed by durable storage is the usual shape.

Permanent entries

Complaints. Someone pressed the spam button. Never send to them again, from any stream, for any reason. A complainant who receives more mail complains again, and that is how a sender ends up at a complaint rate that triggers rejection.

Hard bounces. No such mailbox, domain does not exist. The address is not going to start working. Repeatedly sending to a non-existent address is a signal that you do not clean your list, and providers read it that way.

Unsubscribes. Required to be honoured within two days by the major providers, and there is no reason to take the full two days. Immediate is better.

Spam traps, where identifiable. Usually you cannot see these directly, but an address that has not engaged in a very long time and still accepts mail is the profile.

Temporary entries

Soft bounces, after repetition. One mailbox-full is nothing. The same address returning over-quota for a fortnight is abandoned. Suppress after a threshold — five consecutive soft bounces is a common choice — and re-test occasionally rather than suppressing forever.

Rate-limit responses suppress the destination briefly, not the address. This is throttling, not suppression, and conflating the two will have you dropping valid recipients because a provider was busy.

What does not belong

Transactional mail to a complaining address. This one is genuinely contested. The argument for sending is that a password reset was explicitly requested. The argument against is that the recipient told a mailbox provider your mail is spam, and the provider is now watching.

The defensible position: honour complaints across all streams, and give the user a different route to the thing they needed — show the reset link in the browser session rather than mailing it. Sending to someone who complained because they asked you to is still sending to someone who complained.

Scope

Per account, not global, unless you are running a single-tenant system. One customer's suppression list is their data, and merging lists across customers leaks who is on whose.

Within an account, suppress across streams by default. Separating reputation by stream is good; letting a complaint on one stream authorise sending on another is not.

Make it visible

A suppression list nobody can see produces support tickets that read "our emails stopped arriving" and take an hour to diagnose. Show the list, show why each address is on it and when it was added, and allow removal with a clear warning. The customer who removes a hard bounce and sends again will learn something; the customer who cannot see why delivery stopped just files a ticket.