When someone unsubscribes, complains, or hard-bounces, the instinct is to delete their record. That instinct is wrong twice over.
You lose the proof. If a complaint escalates and you are asked to show that you honoured an opt-out, a deleted record proves nothing.
You lose the block itself. Delete the address and the next import from a partner, a CRM sync, or an old CSV silently re-subscribes them — which is exactly the sequence that turns one annoyed recipient into a regulator’s letter.
What a suppression record should hold
- The address, hashed — the block survives without keeping the address in the clear, which matters for minimisation.
- A scope: is this suppression for the whole tenant, one brand, or one topic?
- A reason: unsubscribe, complaint, bounce, or policy.
- A source: which system or event produced it.
- An active flag, so a mistaken block can be lifted with an audit trail rather than erased.
Scope is the multi-brand question
This is where most platforms fall down, because they only offer one answer.
If suppressions are global to your account, someone unsubscribing from a side project also stops hearing from your main brand — which they did not ask for and would probably object to. If suppressions are per brand with no tenant-level option, a genuine “remove me from everything you run” request becomes a manual job across every brand.
You need both, chosen deliberately. A complaint should usually suppress broadly; a topic opt-out should suppress narrowly.
The rule that should not be configurable
Bounce, complaint and unsubscribe processing should not be something an administrator can switch off — not on a free tier, not temporarily for a big send, not at all. A setting is something that eventually gets toggled by someone under deadline pressure, and this is the one place where that is unrecoverable.