Visual RFC.
ALL RFCs / RFC 8058
Read the RFC ↗

RFC 8058 / START HERE

One-click unsubscribe, before the details

One-click unsubscribe is a mail-header mechanism, not an acronym. It lets mail software submit a defined list-removal action.

The sender advertises an HTTPS URI and a fixed action in signed email headers. With user consent, the receiver can send a POST that the sender handles without another manual confirmation.

The idea in one picture

  1. Read signed headers

  2. Obtain consent

  3. POST the defined action

A simplified picture of the idea; the chapters explain the actual mechanisms.

Why it exists

Mail scanners sometimes fetch links automatically. RFC8058 distinguishes that inspection from a one-click request and supplies the required signal and DKIM coverage. It does not change other uses of List-Unsubscribe.

A familiar example

A newsletter reader chooses to unsubscribe through their mail service. The service checks the signed headers and sends the fixed action to the advertised endpoint. A copied valid message can still enable someone else to unsubscribe that recipient; this is not proof of subscriber identity.

Helpful background

You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.

What you’ll learn next

Begin with chapter one, or choose a topic.

  1. Separate a link fetch from consent to unsubscribeMail scanners fetch links without user action. One-click uses a consented HTTPS POST rather than treating that fetch as the unsubscribe command.
  2. Read the two fields and the self-contained HTTPS URIThe email contains one List-Unsubscribe field and one List-Unsubscribe-Post field. The HTTPS URI must carry enough information to select the recipient and list.
  3. Check DKIM coverage before offering one-clickDomainKeys Identified Mail (DKIM) authenticates signed message content. At least one valid signature must cover both unsubscribe fields and list them in its h= tag.
  4. Encode the fixed POST body without changing the targetThe same key/value pair can be sent as an allowed URL-encoded form or as recommended multipart form data. Body encoding does not change the HTTPS URI.
  5. Keep web context out and recognize security limitsThe operation uses the message URI, not a logged-in browser session. The endpoint must handle the POST directly, and message possession still carries risk.
Start with chapter one →

This introduction explains RFC 8058 (2017). Read the original RFC ↗