Suppression lists: why "just retry the bounce" is wrong

A suppression list tracks addresses that should never receive another email: hard bounces (the address doesn't exist), spam complaints, and manual entries (someone who explicitly asked not to be contacted). It exists specifically to prevent the instinct a lot of retry logic has by default: treating every failed send as something to try again.

Why retrying a hard bounce is actively harmful

A hard bounce means the address doesn't exist, full stop, not "the mailbox was temporarily full" (that's a soft bounce, which is a different, legitimately retryable case). Retrying a hard bounce doesn't just waste a send, it's exactly the pattern mailbox providers watch for to identify senders with poor list hygiene. Repeated sends to dead addresses is one of the clearest signals that a sender isn't validating its list, and it directly damages sending reputation.

Checked twice, not once

Envello checks the suppression list at two points: before a message is even enqueued, and again immediately before it's actually sent. The double-check matters because time passes between those two points, an address suppressed moments ago (a complaint that just came in) shouldn't slip through a request that was already in flight when the suppression was added.

What goes on the list and how it gets there

• Hard bounces, added automatically the moment a send fails with a permanent failure
• Spam complaints, added automatically from provider feedback loops
• Manual entries, for anyone who's explicitly asked not to be contacted through a channel outside the automatic bounce/complaint pipeline

Soft bounces: retryable, but not indefinitely

A soft bounce (mailbox full, temporary server error) is worth retrying, typically with exponential backoff over a day or two. But a soft bounce that keeps recurring for the same address across multiple send attempts should eventually convert to a suppression, since a mailbox that's been full or unreachable for days is functionally indistinguishable from a dead one, even if the SMTP response code technically classified it as temporary.

What suppression looks like from the API side

A send attempt to a suppressed address returns a clear error rather than a silent no-op, so your application knows immediately why a message wasn't delivered instead of just noticing an expected email never arrived. Query the suppression list via API to check an address before attempting a send, or to surface suppression status to your own support team when a user asks why they're not receiving notifications.

The honest limit

A suppression list prevents you from sending to an address that's already demonstrated it shouldn't receive mail. It doesn't prevent the underlying problem, a genuinely stale or low-quality list still generates a wave of hard bounces the first time you send to it, which is where the warmup ladder and pre-send address validation (covered elsewhere on this blog) do the actual preventive work.