RFC 8058 defines the one-click unsubscribe: a List-Unsubscribe: header carrying an https URL, plus a List-Unsubscribe-Post: List-Unsubscribe=One-Click header telling the mailbox provider it may POST to that URL without asking the reader to confirm. Gmail and Yahoo made one-click a requirement for bulk senders in February 2024 — any sender pushing more than 5,000 messages a day to Gmail or Yahoo addresses needs the headers on every message, alongside authenticated mail (SPF pass, DKIM pass aligned with the From: domain, DMARC pass). Miss any of the four and the receiver either buckets the message into spam or, past a threshold, rejects it at the edge.
The compliance signal is header-shaped, so it can be checked statically from a copy of the raw source of a sent message. This validator grades the seven signals in one pass: the four RFC 8058 header-level checks and the three Authentication-Results verdicts Gmail and Yahoo pin the bulk-sender floor to. It runs entirely in your browser; the pasted headers are never uploaded.
This is a static check. It confirms the compliance headers are present and well-formed, and that the SPF/DKIM/DMARC verdicts the receiver stamped satisfy the bulk-sender rules. It does not fire the one-click POST against your unsubscribe endpoint — a header can be present and the endpoint still return 500 to the mailbox provider’s probe. A live tester ships separately. Parsing runs entirely in your browser; no upload endpoint.
What the tool checks
RFC 8058 (four checks):
List-Unsubscribe:header is present.- Its value contains at least one
<https://…>URL. A bare<mailto:…>isn’t RFC 8058 compliant on its own — the one-click POST is HTTP-only. List-Unsubscribe-Post:header is present with the exact valueList-Unsubscribe=One-Click.- The https URL parses cleanly — has a scheme, has a hostname, isn’t a bare IP literal.
Gmail / Yahoo bulk-sender floor (three additional checks):
- The receiver’s
Authentication-Results:line recordsspf=passon the Return-Path domain. - Records
dkim=passon a signature whoseheader.daligns with the From: domain (relaxed alignment on the eTLD+1). - Records
dmarc=pass.
All seven pass and you have both verdicts — the compliance floor at the receiver is met.
Static check versus live one-click test
The header can be present, well-formed, and still not work. The RFC 8058 spec requires the endpoint to accept an HTTP POST with an empty body and return a 2xx response — Gmail and Yahoo periodically probe the endpoint from their side, and if it 5xx’s, times out, or requires cookies, they treat the sender as if the header weren’t there. A static header check is a necessary-not-sufficient signal: it catches the common failure mode (header missing, wrong value, mailto-only), but it can’t catch a broken endpoint.
The live list-unsubscribe tester fires an actual POST against the endpoint and reads the response code, headers, and timing. Static check first, live POST second.
How to get raw headers
- Gmail / Google Workspace. Open the message. Three-dot menu → Show original. Copy from the top of the raw source down through the blank line that ends the header block.
- Outlook (web) / Microsoft 365. Three-dot menu → View → View message source. Copy the header block.
- Apple Mail (macOS). View → Message → Raw Source.
- Thunderbird. View → Message Source (
Ctrl+U).
Paste into the textarea above. The tool parses in your browser — nothing crosses the network.
Why the four RFC 8058 checks read the way they do
The List-Unsubscribe: header predates one-click by more than a decade — RFC 2369 (1998) defined it as a comma-separated list of <URI> entries so mail clients could offer an “unsubscribe” button on newsletters. That original spec allowed mailto: URIs and expected a reader interaction, so a lot of legacy campaign infrastructure emits List-Unsubscribe: <mailto:…> and stops there. It’s compliant with RFC 2369; it’s not compliant with RFC 8058.
RFC 8058 tightens the header in two ways. First, at least one URI must be an https URL — mailbox providers need a target they can POST to, and the empty-body POST semantics only make sense over HTTP. Second, the List-Unsubscribe-Post: header (also introduced by 8058) has to be present and has to carry exactly the value List-Unsubscribe=One-Click, which is the sender’s affirmation that “yes, POSTing to the URL above is an unsubscribe — no confirmation page, no CAPTCHA.”
The URL-sanity check catches the mistakes that make an endpoint impossible to POST to before you deploy: a List-Unsubscribe: <https:> with no host, a hostname that’s a bare IP (mailbox providers won’t POST to those), or a scheme mismatch. It’s cheap and it saves you a live-tester round trip.
Why the Gmail/Yahoo floor is stricter than one-click alone
One-click on its own doesn’t reach the bulk-sender floor. Both providers require the sending domain to be authenticated end-to-end — SPF pass on the envelope-from, an aligned DKIM signature, and a DMARC pass — so that the unsubscribe request Gmail or Yahoo eventually POSTs on the reader’s behalf is going to a domain the sender actually controls. Without alignment, a compromised or spoofed sender could ship the compliance headers and use the endpoint as a channel for something else entirely.
That’s why the tool grades the seven signals as a set. A green RFC 8058 verdict with a red bulk-sender verdict tells you the headers are right but the auth story isn’t; a red RFC 8058 verdict is a message that will never satisfy the bulk-sender rules regardless of how the domain authenticates.
When you’re ready to check further
- The header auth visualizer reads the same header block into a visual SPF / DKIM / DMARC / ARC chain — useful for tracing a
dmarc=failback to which mechanism didn’t align. - The DNS auth checker reads the live SPF, DKIM, DMARC, MTA-STS, and TLS-RPT records for a domain over DNS-over-HTTPS and scores them against the same Gmail, Yahoo, and Microsoft 365 bulk-sender requirements. It’s the check to run before you flip a sending domain into production.
