List-Unsubscribe / one-click unsubscribe (RFC 8058)
List-Unsubscribe is a header that puts an unsubscribe control in the mail client itself, beside the sender's name. RFC 8058 adds the one-click form: the client posts to the address in the header and the reader is out, with no page to load and no account to find. Large mailbox providers require it on bulk mail, and it is far better for you than a spam complaint.
At a glance
- Category
- Consent
- Headers
- List-Unsubscribe, and List-Unsubscribe-Post for one-click
- One-click is
- An HTTPS POST from the mail client, with no confirmation page
- Required on
- Bulk mail, by the large mailbox providers
- Must act within
- Two days, per Google's sender guidelines
- Specified in
- RFC 8058, building on RFC 2369
How it works
The message carries a List-Unsubscribe header naming a URL, and for one-click a second header declaring that a POST to it is the unsubscribe action. The mail client shows its own unsubscribe control near the sender's name. When the reader uses it, the client posts to the URL directly; no page is opened and no session is needed, so the request must be authenticated by whatever token is in the URL itself. Your endpoint records the unsubscribe and answers with a success status.
Why it matters
The alternative to an easy unsubscribe is the spam button, and the spam button costs you the inbox for everybody else on the list. Making the exit trivially easy is therefore a deliverability measure rather than a concession. It is also now a requirement: the large mailbox providers expect bulk senders to support one-click and to act on it quickly, and mail that does not is treated accordingly regardless of how well authenticated it is.
Example
A newsletter includes both headers, with a URL carrying a signed token identifying the subscription. A reader taps the unsubscribe control their client offers. The client posts to the URL, the endpoint verifies the token, marks the topic unsubscribed and answers with a success status. The reader sees their client confirm it, never leaves their inbox, and the next campaign already excludes them.
Common mistakes
- 01Answering the POST with a confirmation page rather than acting on it, which the one-click form exists precisely to avoid.
- 02Requiring a login at the unsubscribe URL, so a reader who cannot remember an account files a complaint instead.
- 03Publishing the header and processing it in a weekly batch, when providers expect the change to take effect within two days.
- 04Putting a token in the URL that never expires and identifies more than one subscription, which turns a leaked link into a wider problem.
In Rasket
Broadcasts carry both headers and a hosted preference page, and a footer with an unsubscribe link is added to any part that does not already have one. Broadcasts
Related terms
Frequently asked questions
Does one-click replace the unsubscribe link in the footer?
No, both should be present. The header serves the client's own control, and the footer link serves readers whose client does not show one.
Is the header needed on transactional mail?
No. A receipt or a password reset is not bulk mail and has no subscription to leave. Adding it there tends to confuse readers about what they are unsubscribing from.
How quickly must an unsubscribe take effect?
Google's sender guidelines ask bulk senders to process it within two days. Acting immediately is simpler to implement and removes any argument about when the clock started.
Sources
Last updated 16 September 2026.
Start sending this morning
Verify a domain and send your first email in minutes.