Suppression list

Hard bounces — permanent SMTP 5xx failures. The address does not work and never will. Re-sending only wastes reputation budget.

Complaints — recipients who clicked "Report spam" in their mail client. Continuing to send to complainers harms your reputation for every recipient at that ISP.

Unsubscribes — recipients who clicked the List-Unsubscribe link or hit the one-click POST endpoint. Sending again is both an RFC 8058 violation and a fast track to landing on a blocklist.

Manual suppressions — addresses your team has decided not to mail (legal request, customer-success escalation, fraud signal).

Receiver-side — every send call to SNDR checks the suppression layer before the MTA reaches out. A suppressed address returns a 422 with a recipient_suppressed error code.

Application-side — your own DB should also check before queueing a send. Saves on API calls and surfaces suppression in your own admin tooling.

MTA-side — the very last line of defence. SNDR's outbound MTAs re-check suppression at the moment of send, so a race condition that slipped through the upper layers cannot cause a re-send.

Suppression is binary: "do not send any mail to this address". It is the absolute floor.

Unsubscribe is a user-driven kind of suppression specifically for marketing communication. Some products distinguish "unsubscribed from marketing but still receive transactional" — the marketing flag is on the user record, the suppression flag is on the address.

Preferences are per-event-type opt-outs ("do not email me when someone comments on my work"). Lighter than unsubscribe; the user is still engaged, just selective about which channels.

A suppressed address can be un-suppressed in some narrow cases — typically when the user explicitly re-confirms via a separate channel (sign-in, support request). Don't un-suppress automatically.

For complainers specifically, re-engagement is rarely worth it. The cost in reputation if they complain again far exceeds the value of one more recipient.