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. If you want the narrower standards glossary first, see List-Unsubscribe header.

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 protocol path: no page load and no sender-controlled interface. A visible Gmail or Apple Mail Unsubscribe surface does not, by itself, prove which transport ran. Provider help can document a native action while leaving the underlying route or eligibility decision unspecified; the message headers are the evidence for an advertised RFC 2369 or RFC 8058 path.

What did Google and Yahoo require in 2024?

Because asking nicely for two decades didn't work.

Starting February 1, 2024, Google's sender guidelines require senders of more than 5,000 messages a day to personal Gmail accounts to support one-click unsubscribe on covered marketing and subscribed mail and include a clearly visible body link (Google sender guidelines). Google's guidance sets a two-day processing window for covered requests.

Yahoo publishes a separate rule without Google's numeric threshold (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-Unsubscribe header 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?

1. 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.
2. 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.
3. Watch what actually arrives. The only ground truth for honor is your own inbox, two weeks later.
4. 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.
5. 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

On a supported Flick card, a separate Unsubscribe control asks for confirmation, then reads the sender's advertised HTTPS List-Unsubscribe route and can use the RFC 8058 POST signal when present. With HTTPS but no POST signal, Flick opens the sender's page for the user to finish; mailto-only headers are not surfaced in the current v1 flow. Flick does not independently verify DKIM coverage. When an endpoint returns success, Flick reports the request as accepted—not that you were removed, because only later mailbox evidence can support that conclusion.

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?

FAQ

What is one-click unsubscribe?

A machine-readable exit route defined by RFC 8058 (January 2017). The sender publishes an HTTPS List-Unsubscribe URL plus List-Unsubscribe-Post: List-Unsubscribe=One-Click, and a receiver can submit the opt-out with one HTTPS POST. Google requires this for covered mail from senders of more than 5,000 messages a day to personal Gmail accounts. Yahoo requires a functioning List-Unsubscribe route, highly recommends POST, and accepts mailto:.

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?

Gmail surfaces the action for messages it recognizes as eligible subscription mail. A missing button does not reveal which header, authentication, reputation, classification, or rollout condition caused the difference; Google's user help does not expose every eligibility decision.

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.

---

On supported cards, Flick asks for confirmation, parses the advertised route, and can use the POST signal when present; it does not independently verify DKIM coverage or sender honor. Try the live demo—no signup.