One-Click Unsubscribe, Explained (Capability Is Not Honor)
One-click unsubscribe is a machine-readable exit route a sender publishes in the email's headers, which lets your mail app fire the opt-out directly — no website, no login, no preference maze (RFC 8058). Since February 1, 2024, Google and Yahoo require it of bulk senders (Google; Yahoo). And here is the part every explainer skips: that header proves a sender can accept your exit. It does not prove they will stop mailing you. Those are two different facts, and the entire industry quietly reports the first one as if it were the second.
That gap has a name in our codebase, because we had to name it to build honestly against it: capability versus honor. Capability is "this sender's mail carries a working exit route." Honor is "this sender's endpoint actually accepted the request — and then the mail actually stopped." A green checkmark in your mail client tells you the first. Nothing in the spec, and nothing in Google's rules, makes the second automatic.
This page explains the mechanism from the bottom up, then shows you exactly where the guarantee ends.
What is the List-Unsubscribe header?
It's a line of machine-readable text the sender puts in the invisible part of every email — the headers — that says here is where to send someone who wants out.
It's old. RFC 2369 defined List-Unsubscribe in July 1998, describing it as "the command (preferably using mail) to directly unsubscribe the user (removing them from the list)." For most of its life it held one of two things:
| Header value | What it means | What your mail app can do with it |
|---|---|---|
<mailto:unsub@sender.com> |
Send an unsubscribe email to this address | Fire off a message on your behalf; the sender has to process a mailbox |
<https://sender.com/unsub?id=…> |
Visit this web page to unsubscribe | Open a browser — and now you're on the sender's turf, with their login walls and their "are you sure?" |
Both work. Neither is one click. The https variant in particular is where the modern unsubscribe maze lives: the header points at a page, and the page can ask you to sign in, re-confirm, uncheck six pre-checked boxes, or explain yourself.
What does RFC 8058 actually add?
RFC 8058 — "Signaling One-Click Functionality for List Email Headers," published January 2017 — closes that hole. It adds a second header:
List-Unsubscribe: <https://sender.com/unsub?id=abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
The second line is the sender raising their hand and saying: you don't need to visit that URL as a human — just POST to it. Your mail provider then does exactly that. In the RFC's words: "A mail receiver can do a one-click unsubscription by performing an HTTPS POST to the HTTPS URI in the List-Unsubscribe header."
That's the whole trick, and it's a good one. No page load. No browser. No sender-controlled interface between you and the door. When Gmail or Apple Mail shows you a native Unsubscribe button, this is usually what's behind it — which is also why that button appears on some emails and not others. It's not your mail app being inconsistent. It's the sender either publishing the header or not.
Why did Gmail and Yahoo force this in 2024?
Because asking nicely for two decades didn't work.
Starting February 1, 2024, Google's sender guidelines require that bulk senders — those sending 5,000 or more messages a day to Gmail accounts — "support one-click unsubscribe, and include a clearly visible unsubscribe link in the message body," referencing both RFC 2369 and RFC 8058 (Google sender guidelines). Google's announcement adds the timing: senders must process unsubscription requests within two days (Google).
Yahoo's rules landed in lockstep and are blunter still (Yahoo Sender Hub):
- "Implement a functioning list-unsubscribe header, which supports one-click unsubscribe for marketing and subscribed messages"
- "The Post (RFC 8058) method is highly recommended"
- "Honor unsubscribes within 2 days"
- "Keep your spam rate below 0.3%"
That last line is the enforcement mechanism, and it's worth understanding, because it explains why senders comply. Google and Yahoo tie inbox access to complaint rates. A sender whose recipients keep hitting "spam" instead of "unsubscribe" watches their deliverability collapse. Making the exit easy is, for a bulk sender, self-defense: every unsubscribe is a spam complaint that didn't happen.
And it worked — at least on the friction. Average campaign unsubscribe rates rose from 0.08% in 2024 to 0.22% in 2025 across 3.6 million+ campaigns measured by MailerLite, which attributes the shift to Gmail making it possible to leave without opening the email. Nothing about the mail changed. Only the difficulty of leaving did — and roughly 2.75× as many people walked out the moment the door got easier to find. (That ratio is our arithmetic on MailerLite's two figures, not an independently measured number.)
The gap: capability is not honor
Here's where we get to the point of this page.
Everything above describes a capability. The header exists. The endpoint is reachable. Your mail app can fire an HTTPS POST at it. What happens next is entirely up to the sender — and RFC 8058 does not require the sender to stop sending you mail. Read the spec cover to cover: it specifies the headers, the POST, and the infrastructure the sender needs to receive the request. It contains no language obligating anyone to actually remove you from anything. It is a signaling standard, not a compliance standard.
So there are three separate claims hiding under the phrase "one-click unsubscribe," and conflating them is how people get lied to:
| Claim | What it actually means | How you'd know it's true |
|---|---|---|
| Capability | This sender's mail carries a machine-readable exit route (the header is there) | Read the raw email. It's a fact about a text string. Free, instant, certain. |
| Accepted | The sender's endpoint returned a success response to the one-click POST | Fire the request and watch the wire. A fact about one HTTP response, at one moment. |
| Honor | The mail actually stopped | Wait. Keep watching the inbox. This is the only claim you actually care about — and it's the only one nobody publishes. |
"Accepted" is the one that fools people. A 200 OK from a sender's unsubscribe endpoint means their server received your request and said "sure." It is a wire fact about past behavior, not a promise about future mail. A sender can return a clean 200 and keep mailing you forever. The spec doesn't stop them. Your mail client won't tell you. And the green checkmark you just saw will say the same thing either way.
This is written into Flick's source, in the shared module that governs every sender claim the product is allowed to make:
capability— mail from this domain CARRIES a List-Unsubscribe route (header exists).honor— the sender's endpoint ACCEPTED Flick's RFC 8058 POST at the wire (2xx). Accepted is NOT removed: it is a wire fact about past behavior, no more.
We made that a code comment rather than a marketing line because it's the thing we're most likely to be tempted to blur later.
What the law says (and where it runs out)
The legal floor is real, and it's the only thing that actually obliges a sender to stop:
- 10 business days. Under CAN-SPAM, it's unlawful for a sender to transmit a commercial email "more than 10 business days after the receipt of such request" (15 U.S.C. §7704(a)(4)(A)(i); FTC rule at 16 CFR 316).
- 30 days of a working door. The opt-out mechanism must remain "capable of receiving such messages or communications for no less than 30 days after the transmission of the original message" (15 U.S.C. §7704(a)(3)(A)(ii)).
- No tolls on the exit. A sender can't charge you a fee or demand information beyond your email address to let you leave (FTC CAN-SPAM compliance guide).
- Up to $53,088 per email for each message sent in violation (FTC).
Notice the shape of that. The law obliges senders to stop, but gives them 10 business days — roughly two calendar weeks — and enforcement is a complaint-driven process you're unlikely to personally trigger. The platforms oblige senders to offer the button and honor it in 2 days, and enforce that with the one thing senders truly fear: deliverability. Between those two regimes sits a large, quiet space where a sender publishes a perfect RFC 8058 header, returns a clean 200 to every request, and keeps mailing you anyway.
Nobody measures that space. That's the gap.
What "we're building the Exit Gap Index" means
So we're measuring it. Here is the method, in full, with the honest status attached — because the method is all that exists right now.
The Exit Gap Index compares the exit a sender gives a robot against the exit they give a human:
- The machine path. We parse the
List-Unsubscribeheader straight from the raw email. That's the exit Google forces them to give a machine: one request, sometimes zero clicks. - The human path. A headless crawler walks the sender's actual unsubscribe link the way a person would — counting clicks, catching login walls, guilt copy ("are you sure you want to miss out?"), and pre-checked preference mazes, screenshotting every step.
- The grade is the gap. Your clicks minus the robot's clicks. Zero gap is an A; every extra step drags it toward F. A login wall is an automatic F — you cannot leave an account you never made. Confirm-shaming and preference mazes each cost a letter.
And the guards, which matter more than the grades:
- Fail-closed. No sender is graded on fewer than 3 probes spread across ≥48 hours. Below that bar, the answer is ungraded — never a guess.
- Evidence or it didn't happen. Every published grade will carry the raw header, a step-by-step crawl log, and a screenshot per step.
- Deterministic verdicts. Grade copy is generated from a fixed template. No language model writes a verdict.
- A dispute link on every graded page. Think we got it wrong? One email and we re-probe.
Current status, stated plainly: zero senders carry a published grade. Not one. The crawl work-list exists, the rubric exists, the fail-closed gate exists, and the grade count is 0. When we say "we're building the Exit Gap Index," we mean the method is built and the measurements have not been taken yet. You can watch the counter yourself on the Exit Gap Index page — it reports what was on disk at build time, including the zero.
We could have shipped guessed grades. Every incentive pointed that way. An index with 150 letters in it is a press story; an index with a method and a zero is not. But a guessed grade is exactly the thing this whole page is against — a claim dressed up as a measurement — and we'd rather show you a blank we'll fill in honestly than a letter we made up.
So what should you actually do?
- Use the one-click button when you see it. It's the best mechanism available: your provider fires the sender's own registered endpoint, no browser, no sender-controlled page in between. It is safer than clicking a link in the body, and it's the path the platforms police hardest.
- Don't read the green checkmark as a promise. It means accepted, not removed. Give it the two-day platform window; give a non-bulk sender the ten-business-day legal window.
- Watch what actually arrives. The only ground truth for honor is your own inbox, two weeks later.
- If the mail keeps coming, stop unsubscribing and start reporting. Past the window, you're not dealing with a delay — you're dealing with a sender who ignored a legally binding request. Mark as spam and block (FTC). A spam complaint hits their deliverability, which is the only thing that has ever made this industry move.
- Never click unsubscribe in mail that's already in your junk folder — clicking any link in suspicious mail confirms your address is live (AARP). Capability language doesn't apply to bad actors; they publish whatever headers they like.
Where Flick fits
Flick's unsubscribe swipe reads the sender's own List-Unsubscribe header and fires the RFC 8058 one-click endpoint when the sender publishes one. When they only publish a body link, Flick hands you that link and says so. And when the endpoint comes back with a success, Flick tells you it was accepted — not that you were removed, because we don't know that and neither does anyone else.
What Flick will not do: claim to unsubscribe you from everything in one tap. There is no button — in any app, ours included — that removes you from every list in one tap. Every subscription is a record on the sender's side; leaving means one request per sender, forever. Any product promising otherwise is firing the same one-per-sender loop you could fire yourself, and hoping you don't check.
You can also check a single sender right now without installing anything: paste an unsubscribe link into the unsubscribe link checker and see whether it's really one-click — or a maze with a one-click sticker on it. The full step-by-step for every mail app is in how to unsubscribe from emails, and the safety rules are in does unsubscribing actually work?
Stop reading your inbox. Start flicking it.
Flick turns every inbox into a finite swipe deck — archive, "no reply needed," or AI-draft → approve, one card at a time. Inbox flicked.
Try the live demo — no signup →FAQ
What is one-click unsubscribe?
A machine-readable exit route defined by RFC 8058 (January 2017). The sender publishes a List-Unsubscribe URL plus a List-Unsubscribe-Post: List-Unsubscribe=One-Click header, and your mail provider fires the opt-out with a single HTTPS POST — no website visit, no login. Google and Yahoo have required it of bulk senders (5,000+ messages/day) since February 1, 2024.
What is the List-Unsubscribe header?
A header field defined in RFC 2369 back in July 1998, carrying the address or URL where a recipient can be removed from a list. On its own it may point at a mailto: address or a web page; only when it's paired with the RFC 8058 List-Unsubscribe-Post header does it become a true one-click exit.
Does one-click unsubscribe guarantee the emails stop?
No. RFC 8058 defines how the request is sent and received; it places no obligation on the sender to actually stop mailing you. What obliges them is the platforms' rules (Google and Yahoo require bulk senders to honor unsubscribes within 2 days) and the law (CAN-SPAM gives senders 10 business days). A success response from the sender's endpoint means "accepted," not "removed."
What's the difference between unsubscribe capability and unsubscribe honor?
Capability means the sender's mail carries a working machine-readable exit route — a fact about the email's headers. Honor means the mail actually stopped — a fact about the future. A sender can have perfect capability, return a clean success response to every request, and keep mailing you. Almost every public claim about unsubscribing measures capability and quietly implies honor.
Why does Gmail show an Unsubscribe button on some emails but not others?
Because the button is powered by the sender's own List-Unsubscribe headers. Senders who don't publish them — or whose mail Gmail doesn't classify as subscription mail — don't get the button, and you're left with whatever link is in the email body.
Has Flick graded any senders yet?
No. Zero senders carry a published grade. The Exit Gap Index method, rubric, and fail-closed gate are built — no sender is graded on fewer than 3 probes across at least 48 hours — but the measurements have not been taken. Ungraded, not guessed. The live count is on the Exit Gap Index page.
Flick reads the sender's own header, fires the real one-click endpoint, and tells you exactly what came back. Try the live demo — no signup — one email, one card, one decision.