RFC 8058: The One-Click Unsubscribe Standard, Defined
RFC 8058 — "Signaling One-Click Functionality for List Email Headers," published January 2017 — defines one-click email unsubscribe. A compliant sender adds List-Unsubscribe-Post: List-Unsubscribe=One-Click alongside an HTTPS List-Unsubscribe URI, and a mail receiver requests the unsubscribe by sending one POST to that URI. The endpoint must complete the request without requiring a login, confirmation page, exit survey, or other manual step.
Verification note: This is a documentary source review checked against current sources on August 3, 2026. We did not hands-on test the named product or workflow during this review, so claims are limited to the cited documentation. Interfaces can vary by account, region, rollout, and app version.
The quotable version: RFC 8058 lets a mail receiver request removal from a list with one HTTPS POST; the endpoint must complete it without further user interaction.
What does RFC 8058 actually require?
Four normative things, per RFC 8058:
- The
List-Unsubscribeheader must contain at least one HTTPS URI. - The
List-Unsubscribe-Postheader must contain the single key/value pairList-Unsubscribe=One-Click— nothing else. - The POST must complete the unsubscribe without manual intervention. The spec is explicit: it must work "without requiring that software attempt to interpret the contents of a confirmation page." A login wall breaks compliance.
- At least one valid DKIM signature must cover both headers. This authenticates the signed message domain and protects those header fields in transit; it does not certify the declared endpoint as harmless.
For the POST itself, the receiver sends List-Unsubscribe=One-Click as form data and must not include cookies, HTTP authorization, or other context. That does not make the request anonymous: the HTTPS URI is expected to contain enough information to identify the recipient and the list.
One deliberate wrinkle: the mail client must get the reader's consent before firing the POST. That is why one-click unsubscribe is a button you press, not something that happens to you.
What do the two headers and POST look like?
This fictional example shows the complete shape without exposing a real recipient token:
List-Unsubscribe: <https://news.example.com/unsubscribe/opaque-token>,
<mailto:list-request@news.example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
After the user consents, a receiver selecting the HTTPS route sends the equivalent of:
POST /unsubscribe/opaque-token HTTP/1.1
Host: news.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
List-Unsubscribe=One-Click
The request must not include cookies or HTTP authorization. A compliant message also needs a valid DKIM signature covering both header fields; that signature is not visible in this shortened example. A 2xx response can establish endpoint acceptance, not that later mail stopped. See the List-Unsubscribe glossary for RFC 2369 route choices and the research methodology for the evidence needed to claim honor.
How is RFC 8058 different from the List-Unsubscribe header?
RFC 8058 builds on the original List-Unsubscribe header, defined in RFC 2369 back in July 1998.
| List-Unsubscribe (RFC 2369) | One-Click (RFC 8058) | |
|---|---|---|
| Published | 1998 | 2017 |
| Defines | Header listing mailto: and/or http unsubscribe URIs |
A signal that the HTTPS URI accepts an automated POST |
| What the standard provides | Opens a link or drafts an email — anything can be on the other side | Sends an automated POST that the endpoint is required to treat as the unsubscribe |
| Login or confirmation page | Allowed | Not allowed |
| DKIM signature | Not required | Required, covering both headers |
The practical difference: RFC 2369 can lead to an interactive page or email, while RFC 8058 specifies a POST that must complete without further user interaction. Header conformance still describes capability; only later mailbox evidence shows whether the sender kept the promise.
Why did RFC 8058 suddenly matter in 2024?
Because mailbox providers made machine-readable exits a delivery requirement for defined traffic. Google's sender guidelines require senders of more than 5,000 messages a day to personal Gmail accounts to support RFC 8058 in covered marketing and subscribed mail, effective February 1, 2024; senders that already had an unsubscribe link got until June 1, 2024 to add one-click. Google also tells covered senders to keep spam rates below 0.3% and process covered subscription opt-outs within 48 hours.
Yahoo's sender requirements landed in the same window: covered bulk senders must provide a functioning List-Unsubscribe route for marketing mail, honor requests within two days, and keep complaint rates below 0.3%. Yahoo highly recommends the RFC 8058 POST method but also accepts mailto:, so its rule should not be described as an RFC 8058 mandate.
For the full history and mechanics, see our long report: one-click unsubscribe, explained.
Does every sender support RFC 8058?
No. Gmail requires RFC 8058 for its defined covered traffic; Yahoo requires a functioning List-Unsubscribe route and highly recommends POST while accepting mailto:. Smaller or out-of-scope senders may publish only a mailto: route or hosted preference page. A compliant header establishes request capability, not endpoint safety or later honor. See our unsubscribe statistics for attributed external evidence rather than a Flick sender-honor result.
How does Flick handle RFC 8058?
We build List-Unsubscribe parsing for a living, so this part is short. Flick parses advertised headers while normalizing a supported card, but a separate Unsubscribe control asks for confirmation before it acts on the route or sends a request. If an HTTPS route and the RFC 8058 signal are present, Flick can send the POST after route checks; with HTTPS but no POST signal, it opens the sender's page for the user to finish. Mailto-only headers are parsed but are not surfaced in the current v1 flow. Flick does not independently validate DKIM coverage, so header presence is not presented as sender authentication or endpoint safety. The action records a protocol request, not a kept promise. As of August 3, 2026, the Exit Gap Index is a 150-sender work-list with four capability-only observations and no A–F honor grades. Its noindex protocol requires at least three post-request probes over at least 48 hours with preserved evidence, and the founder burner-mailbox observations have not occurred.
Turn the next inbox decision into a finite deck.
Open Flick with an account you control, or practice first with fabricated sample mail. Provider results remain limited to the accounts, messages, and actions Flick actually confirms.
Open Flick with your inbox →FAQ
Is RFC 8058 legally required?
No — RFC 8058 is an internet standard, not legislation. Gmail made RFC 8058 one-click a condition for defined covered traffic. Yahoo requires a functioning List-Unsubscribe route for its covered bulk traffic but calls the POST method "highly recommended" and accepts mailto:. Provider requirements are not laws and differ in scope.
What is the List-Unsubscribe-Post header?
The List-Unsubscribe-Post header is the signal defined by RFC 8058 that a sender supports one-click unsubscribe. It must contain exactly List-Unsubscribe=One-Click, and it tells the mail client that the HTTPS URI in the List-Unsubscribe header will accept an automated unsubscribe POST.
Why does RFC 8058 require a POST instead of a GET?
Because security software opens links in email, and a GET that unsubscribes would unsubscribe people who never asked. RFC 8058 is designed so automated URL-fetching cannot trigger an accidental unsubscribe; only a deliberate POST does.
Does one-click unsubscribe work with mailto: links?
No. mailto: unsubscribe comes from RFC 2369 and requires sending an email; RFC 8058 is specifically an HTTPS POST. The current Flick v1 flow requires an HTTPS route: it can use POST when the one-click signal is present or hand an HTTPS sender page to the user, but it does not surface a mailto-only header.
How fast must senders honor an unsubscribe?
Yahoo requires covered bulk senders to honor unsubscribes within two days, and Google requires covered subscription opt-outs within 48 hours. The current Exit Gap Index documents those provider windows and a planned verification method; it does not yet measure sender outcomes or publish honor grades.