Unsubscribe links
How one-click unsubscribe works in wemail: RFC 8058 List-Unsubscribe headers, the hosted confirmation page, automatic suppression and the unsubscribed event.
Every message wemail delivers to a single recipient can carry a standards-compliant unsubscribe mechanism that mailbox providers render as their own Unsubscribe button — the RFC 8058 one-click flow that Gmail and Yahoo have required from bulk senders since February 2024. Recipients who use it are added to your suppression list automatically, and you are told about it through an event.
What wemail adds to the message
Two headers: List-Unsubscribe with an HTTPS URL that is unique to the recipient and the message, and List-Unsubscribe-Post: List-Unsubscribe=One-Click. The URL points at wemail's public unsubscribe endpoint, because wemail owns the suppression list that the send-gate enforces. The link is a compact HMAC-signed token that encodes the account, the recipient and the message id — it needs no database lookup, cannot be forged, and never expires, so a recipient can unsubscribe from a six-month-old email and still be honoured.
List-Unsubscribe: <https://wemail.io/api/public/unsubscribe/eyJhY2N…>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickWhat happens when someone unsubscribes
When Gmail, Apple Mail or Yahoo show the button and the recipient taps it, the client sends a POST to the URL with no further interaction; a recipient who follows the link in a client without one-click support gets a GET that shows a hosted confirmation page. Both paths do the same three things: verify the signature, insert an unsubscribes entry into your suppression list for that address, and emit an unsubscribed event on the message. The event reaches your webhooks like any other and appears in the Console Activity timeline.
What it means for future sends
The suppression list is checked on every send. A message addressed to an unsubscribed recipient is rejected before it reaches a provider, and the attempt is visible in Activity with the reason. Because complaints are so costly to reputation, a working unsubscribe path is the single most effective way to keep complaint rates low: a recipient who can leave in one tap rarely presses Report spam. If you have strictly transactional mail that must still reach an unsubscribed address — a password reset, a legally required notice — add the address to the allowlist with the *override unsubscribes* option set; without that flag an allowlist entry only bypasses bounce and complaint suppressions.
Enabling and disabling
One-click unsubscribe is on by default for the account. It is a tri-state setting on each sending domain — inherit, on or off — under the domain's tracking settings in the Console, with the account default under Settings. A domain left at *inherit* follows the account. Headers are added only when the message has exactly one active recipient, since each recipient needs their own link; use batch send or a mailing list to fan out and each member gets an individual header.
Managing the list
Suppressions are yours to read and edit: list them with GET /v3/suppressions?type=unsubscribes, remove an entry the recipient asked to re-enable with DELETE /v3/suppressions/{email}, add entries you import from another provider with the bulk endpoints, and export the whole list as CSV with POST /v3/suppressions/export. The Console Suppressions screen shows the same data with search and the source of each entry.