How do unsubscribes and suppression work?

NevarMail gives every recipient a working, one-click unsubscribe link and a preference center, automatically suppresses anyone who unsubscribes, bounces hard, or reports spam (the moment your provider reports it, for every production send, when your provider account's event webhook points at NevarMail; the 6-hour provider sync catches the rest — see Bounces and suppressions), and never lets you send to a suppressed address again — but you're the sender of record on your own account, so decisions like what you send and to whom remain yours to make responsibly.

What is suppression?

A suppression is a permanent "do not send" record for one email address in one project (or, more narrowly, for one of that project's lists). NevarMail tracks four reasons an address can be suppressed: unsubscribe, hard_bounce, spam_complaint, and manual (added by you). Once an address is suppressed for a reason other than a plain unsubscribe, it's blocked from every list in the project — bounces and spam complaints aren't a preference to be scoped, they're a signal that the address shouldn't be mailed at all.

An unsubscribe can be scoped: if a recipient leaves one list (say, the weekly newsletter) but stays on another (like product announcements), NevarMail respects that distinction. Projects are separate: leaving a list in one project never touches another project's lists.

What does the unsubscribe link actually do?

Every message a recipient can opt out of includes a link to the project's public preference page (/unsubscribe/[token]) that needs no login. The signed token in the URL is the recipient's only credential. It names one address and the list the email came from; the organization and project are the list's own. So nothing on that page can read or change anyone else's preferences, or show another project's lists. A changed or shortened link is refused, and so are links in the format NevarMail used before October 2026: the recipient sees an "invalid link" page and nothing is changed.

• A one-click unsubscribe (the kind a mail client can fire automatically, per RFC 8058) takes the recipient off the list that email came from. The link came from one specific email, so its list is the closest reading of what the person asked for.
• Opening the link does the same, with no extra step, and the page says which list they left. The page then shows the project's lists that the recipient is on or has left, by each list's public name, and never lists they were never on. They can turn lists back on, leave others, or choose "Stop all email from" the project.
• If you've deleted the list since the email went out, opening the link (or a one-click unsubscribe) tells the recipient they won't receive this mail any more and changes nothing else. A deleted list sends no more mail, so there's nothing to opt out of, and their place on your other lists is left alone.
• Turning a list back on lifts the opt-out, but it doesn't put the address back on the list. Adding people to lists stays your call.
• Every suppressable email therefore needs a list to leave. A marketing send with none (no suppressable use case and no list) is refused.

Does NevarMail import my existing unsubscribe list?

Yes. A background sync runs every 6 hours and pulls your provider's suppression lists — bounces, spam reports, and unsubscribes — into NevarMail, so a recipient who opted out on your provider's side (or before you connected NevarMail) is honored here too. It does not import provider-side blocks, since a block is a transient delivery issue, not a permanent signal that the address shouldn't be mailed.

An unsubscribe made at your provider on mail NevarMail sent (your provider's own unsubscribe link, or a List-Unsubscribe it handles) doesn't wait for the sync: when the event webhook points at NevarMail, it is suppressed as soon as the provider reports it. A group unsubscribe opts the recipient out of the list that email's unsubscribe link named, the same list your one-click link removes them from; a global one, or a group unsubscribe on a campaign, blocks the whole project. Either way, it never stops a non-suppressable (transactional) use case's mail, such as password resets and receipts.

Does NevarMail push my unsubscribes back to my provider?

Yes, for unsubscribes specifically. When someone unsubscribes through NevarMail, that opt-out is mirrored to your provider account so your provider's own sending also respects it, if you send through it directly for anything outside NevarMail. This sync is asynchronous — it's queued in the background and picked up by the same 6-hour cycle if the immediate attempt doesn't land — so treat NevarMail's suppression list as the source of truth for "did this take effect" rather than checking your provider account immediately after.

Can I check or manage suppressions myself?

Yes, in two ways:

• From your own systems: GET /api/v1/suppressions/check lets your integration ask "may I mail this address from this project?" before sending. Name a use case to check a send to its list, or to let a non-suppressable (transactional) use case ignore an opt-out. Bounces and spam complaints still block regardless of use case.
• In bulk: POST /api/v1/suppressions lets you add suppressions in bulk (for example, importing a list from a system NevarMail doesn't sync automatically), and GET /api/v1/suppressions lists and filters your account's suppressions.
• On behalf of a recipient: if you capture an opt-out somewhere other than NevarMail's own preference page (a support ticket, a reply-to-unsubscribe email you handle yourself), GET/PUT /api/v1/preferences let you read and record that recipient's list choices in a project programmatically (subscribed_list_ids and unsubscribe_all, with project_id required when your organization has more than one project).

What should I not rely on yet?

NevarMail's outbound event webhooks exist as a feature, but they don't dispatch real bounce, complaint, or unsubscribe events yet. Don't build a workflow that waits on a webhook to learn about a suppression — poll GET /api/v1/suppressions or use the pre-send check instead.

What does NevarMail handle for me, and what's still on me?

NevarMail handles automatically:

• Putting the unsubscribe footer and List-Unsubscribe headers on every email a recipient can opt out of — every marketing send, and every send under a suppressable use case, which includes each project's default use case. A send that names no use case therefore always carries the footer.
• Using the right postal address in that footer. Each project has its own CAN-SPAM address, copied from your organization's address (Settings → Marketing) when the project is created and editable in the project's Project Settings or through the API (PUT /api/v1/projects/{id}/address, SDK setProjectAddress, scope org:write); the footer uses the address of the project the email is sent from.
• Serving a working, tokenized unsubscribe and preference page for every recipient.
• Honoring one-click and preference-center opt-outs immediately, and never sending to a suppressed address again.
• Importing your provider's own bounce/complaint/unsubscribe history so NevarMail's list matches reality.
• Mirroring NevarMail-side unsubscribes back to your provider account.

Still your responsibility as the sender of record:

• Making sure the content you send is accurate, wanted, and not misleading — CAN-SPAM and GDPR are about what you send and why, not just whether an unsubscribe link exists.
• Honoring opt-outs you learn about outside NevarMail (a reply, a support request) — use the preferences API to record those so NevarMail's suppression list stays accurate.
• Legal compliance more broadly: this page describes what the product does, not legal advice. Consult your own counsel for what CAN-SPAM, GDPR, or other regimes require for your specific sends and audiences.

Related pages

• Test mode and safe send — why your first sends are restricted before any of this applies.
• Tracking — subscription tracking and the other tracking settings NevarMail can read from your provider.
• Your data and recipient data — what NevarMail stores about recipients overall.