Unsubscribes, bounces and staying compliant

How suppression works, and what GDPR requires from you.

The suppression list is the real gate

Every project has one suppression list — a table of email addresses this workspace will never send to again. It's checked at the moment a message is queued, not when a subscriber's status changes, and it's checked by address, not by subscriber row. That distinction matters: a subscriber can show status subscribed in your list and still never receive anything, if their email address is separately sitting in suppression.

This is also why the Suppression page's own warning is literally true: addresses here are skipped on every send even if they're re-imported later. Re-importing a CSV with a previously-unsubscribed address will flip that row back to subscribed in the Subscribers view — CSV import never touches the suppression table — but the send will still silently skip them, because suppression, not status, decides who actually gets mail.

The unsubscribe link

Every message Sumezi queues gets its own signed token, and that token is what the unsubscribe link, the click-tracking links and the open-tracking pixel are all built from. Wherever your template has {{unsubscribe_url}}, Sumezi replaces it with a link signed specifically for that one message — nobody can construct a working unsubscribe link for someone else's email by guessing.

Confirm page vs. one-click

Clicking it doesn't unsubscribe anyone right away — it lands on a confirmation page first, since a plain GET request should never have a side effect. Only submitting that confirmation (or, for mailbox providers that support it, an automatic one-click POST under RFC 8058 — the mechanism behind the button next to a sender's name in Gmail and similar clients) actually applies the unsubscribe.

Once it goes through, the address is added to suppression with reason unsubscribed, the subscriber's status flips to unsubscribed, and an event is logged on their timeline (visible on the subscriber's detail page) so you can see exactly when and via what it happened.

Bounces are handled automatically

You don't need to watch a mailbox for bounce notifications yourself. When a send fails, Sumezi's delivery worker looks at the SMTP error message: anything that reads like a permanent rejection ("user unknown", "mailbox", or an SMTP code 550/551/553) is treated as a hard bounce — the address is suppressed immediately, with reason bounced, and the subscriber's status is set to bounced. There's no retry for these; the worker assumes, correctly, that trying again won't help.

Anything else — a timeout, a temporary server error — is treated as transient and retried with backoff (roughly 5 minutes, then 25, capped at once per day) up to six attempts before it's marked failed without touching suppression. This distinction is what keeps a single flaky delivery from permanently blacklisting a real, working address.

Restoring or blocking an address

The Suppression page lists every suppressed address with its reason, source and date. For unsubscribed and manual entries, a Restore button removes them from the list outright (re-adding them to your active sends the moment you click it — there's no re-confirmation step). Bounced and complaint entries show a lock icon instead: permanent, by design.

You can also add someone directly with Block address — useful for a role address, a competitor, or anyone who's asked to be removed outside of clicking a link. It's filed under reason manual, so it stays restorable if you ever need to undo it.

Consent, in practical terms

Sumezi doesn't police what counts as valid consent — that's a legal question for you, not something the app can verify. What it does give you: an unsubscribe link on every single send (there's no way to remove it, since it's injected into the queued message itself, not something you add to the template), and, for the public signup form, a real double opt-in with a timestamped confirmation and the confirming IP address recorded against the subscriber — genuinely the strongest consent evidence Sumezi can produce for you.

Manual add and CSV import don't create that same evidence — they mark someone subscribed on your word, via the import checkbox or simply by using the form. If your consent basis depends on being able to prove it later, keep your own record (where the list came from, when, and under what terms) outside Sumezi for anything added those two ways.

For a deletion request, a subscriber's detail page has a Forget action separate from the ordinary delete in the row menu — it's the same underlying operation (the row is actually removed from the database, not just flagged), offered specifically for right-to-erasure requests.

Troubleshooting

• I re-imported a list and they're still not getting mail: check Suppression, not just their status — CSV import never clears a suppression entry, so a previously-unsubscribed or bounced address stays blocked no matter how many times you re-import it.
• An address is stuck as "permanent" and I'm sure it's fine now: bounced and complaint reasons have no Restore button by design — the assumption is a hard bounce means a dead mailbox and a complaint means someone explicitly doesn't want your mail. Blocking and then restoring won't reset the reason either, since it was the worker's own bounce detection that set it, not something the UI lets you override directly.
• A recipient says they never got an unsubscribe link: the List-Unsubscribe header (what powers the one-click button next to a sender's name in Gmail and similar clients) is added to every regular send automatically, whether or not your template shows a visible link — but if {{unsubscribe_url}} isn't in the template body, there's simply nothing for a human reader to click inside the email itself.