Does Microsoft support RFC 8058 list-unsubscribe-post?
Matthew Whittaker
Co-founder & CTO, Suped
Published 29 May 2025
Updated 24 May 2026
8 min read
Summarize with
Yes. Microsoft supports RFC 8058 List-Unsubscribe-Post in practice. When a message has a valid List-Unsubscribe header with an HTTPS URL and a List-Unsubscribe-Post header, Microsoft can send an HTTP POST request to the unsubscribe URL. The important catch is that the subscriber identifier belongs in the URL, not in the POST body.
That detail catches people because a normal form submission often sends fields in the body. RFC 8058 is different. The body is the fixed signal, and the unsubscribe endpoint should use the path or query string to find the recipient and list. I treat Microsoft support as real, but I do not treat the Outlook unsubscribe button as a guaranteed UI element on every message.
Direct answer
- Support: Microsoft does process RFC 8058 style one-click unsubscribe requests when the message and endpoint are set up correctly.
- Token: Put the recipient or subscription ID in the HTTPS URL, because the POST body is not for your custom data.
- UI: Do not assume the unsubscribe button will appear in every Outlook or Microsoft 365 view, even when the headers are valid.
What RFC 8058 requires
RFC 8058 adds one-click behavior to the older List-Unsubscribe header. The RFC 8058 spec says the message needs one List-Unsubscribe header and one List-Unsubscribe-Post header. The List-Unsubscribe header needs an HTTPS URI. It can also include a mailto option, but the HTTPS URI is the one-click path.
The List-Unsubscribe-Post value is fixed: List-Unsubscribe=One-Click. It is a signal to the mailbox provider that the HTTPS URL can accept a one-click POST without asking the recipient to confirm another step.
Working RFC 8058 headerstext
List-Unsubscribe: <mailto:unsubscribe@example.com?subject=unsubscribe>, <https://example.com/u/abc123> List-Unsubscribe-Post: List-Unsubscribe=One-Click DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; h=from:to:subject:date:list-unsubscribe:list-unsubscribe-post; b=...
The DKIM part matters. RFC 8058 expects a valid DKIM signature that covers both unsubscribe headers. If the signature omits those headers, the receiver has less reason to trust that the unsubscribe URL was placed there by the domain owner. Suped's DKIM checker helps confirm the selector and signing domain before you spend time debugging Outlook behavior.
Outlook on the web showing where an unsubscribe action can appear.
What Microsoft sends
The Microsoft-specific trap is the shape of the request. If your List-Unsubscribe URL is https://example.com/u/abc123, Microsoft can POST to that URL. Your endpoint should identify abc123 from the URL and unsubscribe that recipient. It should not expect a body field such as un=abc123.
The body is normally the standard RFC 8058 value. That value tells your server that this is a one-click request. It does not carry your subscriber ID. A public Microsoft discussion also shows why senders often see uncertainty around Outlook's unsubscribe UI and underlying header handling.
Expected one-click POSThttp
POST /u/abc123 HTTP/1.1 Host: example.com Content-Type: application/x-www-form-urlencoded Content-Length: 26 List-Unsubscribe=One-Click
Correct POST behavior
- Method: Accept POST as the automatic unsubscribe request.
- Identity: Read the recipient token from the URL path or query string.
- Response: Return a normal success status after the unsubscribe is recorded.
Safe GET behavior
- Method: Treat GET as a preview, confirmation page, or no-op.
- Risk: Security crawlers and scanners can fetch links before a person acts.
- Fix: Do not remove a subscriber on GET alone.
This is also why an HTTP List-Unsubscribe URL without List-Unsubscribe-Post is risky. A Microsoft system can still touch the URL during scanning or unsubscribe handling, but that request is not a clean RFC 8058 one-click signal. For a deeper treatment of GET vs POST, keep the automatic action tied to POST and keep GET harmless.
Why Outlook still hides the button
A valid RFC 8058 implementation does not force every Outlook client to show a visible unsubscribe button. The button is a mailbox provider decision. Microsoft can consider authentication, placement, message classification, interface version, and whether the message looks like bulk mail.
That means the right test is not only visual. I check the raw headers, confirm DKIM coverage, send to a controlled Microsoft mailbox, and log requests at the unsubscribe endpoint. If the endpoint receives a POST to the expected URL, the one-click path is working even when the UI is inconsistent.
|
|
|
|---|---|---|
Headers | One is absent | Add both headers |
DKIM | Headers unsigned | Update signing |
URL | Token missing | Encode identity |
 Client | UI differs | Test multiple views |
Reputation | Trust is low | Fix authentication |
Common reasons a visible Outlook unsubscribe control is missing.
The quickest mistake is to rewrite the endpoint when the real issue is authentication. Use DMARC monitoring to find which sources send your mail, which ones pass DKIM, and which ones can safely carry a signed List-Unsubscribe header.
Flowchart showing the Microsoft RFC 8058 one-click unsubscribe path.
How I test Microsoft support
I use two tests: one inbox-facing test and one endpoint-facing test. The inbox-facing test confirms that the message has the right headers and passes authentication. The endpoint-facing test confirms what Microsoft actually sends when the one-click path is used.
Start by sending a real message to a Microsoft mailbox and inspect the received headers. Suped's email tester is useful here because it shows authentication results and header-level issues in one place before you start chasing client behavior.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
On the server side, log method, path, query string, response code, and the first few bytes of the request body. Do not log personal data in plain text. Use opaque tokens that map to subscriptions in your own database.
Endpoint test commandsbash
curl -X POST "https://example.com/u/abc123" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data "List-Unsubscribe=One-Click" curl -X GET "https://example.com/u/abc123"
The POST command should unsubscribe the recipient. The GET command should not. If both commands unsubscribe, the endpoint is unsafe for link scanners. If neither command works, the issue is in routing, token lookup, or the unsubscribe write path.
Do not build one-click around the POST body
A Microsoft one-click request can look broken if your code expects the subscriber ID in the body. The body is the standard one-click signal. Your token should be in the URL.
- Good: POST to a URL that already contains the opaque subscription token.
- Bad: POST to a shared endpoint that expects Microsoft to send your token as form data.
- Fallback: Keep mailto working for clients that choose that route, but do not depend on it for Microsoft.
Where Suped fits
One-click unsubscribe is not a DMARC mechanism, but it sits next to the same operational work. The same sending sources, DKIM selectors, authentication failures, forwarding paths, and policy changes affect whether a mailbox provider trusts the message enough to show native unsubscribe controls.
Suped is the strongest practical choice for most teams when this work needs to sit beside DMARC reporting, hosted SPF, hosted MTA-STS, SPF flattening, real-time alerts, and blocklist (blacklist) monitoring. The useful workflow is simple: add the domain, identify every legitimate source, fix authentication gaps, then test the unsubscribe header on real messages.
Email tester sample report showing total score, email preview, issue summary, and per-section results
For MSPs and teams with many sending domains, the multi-tenant view matters because RFC 8058 issues rarely affect one domain in isolation. A marketing platform, CRM, billing system, or product notification service can all send list mail. Suped keeps the authentication and deliverability checks in one place, with issue detection and steps to fix instead of raw reports alone.
If you need the implementation details for adding the header itself, the companion article on how to add an unsubscribe header covers the header format and message-level requirements.
Implementation checklist
If Microsoft support is the question, the answer is yes. If production reliability is the question, the answer is this checklist. I would not ship RFC 8058 support until every item is true in a real received message.
RFC 8058 readiness
Use these bands to decide whether a Microsoft test failure is a header issue, an endpoint issue, or a UI expectation issue.
Ready
Ship
Both headers exist, DKIM covers them, POST works, and GET is harmless.
Needs work
Fix
Headers exist, but DKIM coverage, token parsing, or GET handling is incomplete.
Unsafe
Block
GET unsubscribes users, tokens sit only in POST body, or headers are unsigned.
- Headers: Include one List-Unsubscribe header with an HTTPS URL and one List-Unsubscribe-Post header.
- DKIM: Sign both unsubscribe headers and confirm the received message still has a valid signature.
- Endpoint: Accept POST, parse the URL token, unsubscribe immediately, and return a success response.
- GET: Show a confirmation page or do nothing, because automated systems fetch URLs.
- Logging: Record enough request detail to prove Microsoft reached the endpoint without storing sensitive data.
A clean Microsoft test is useful, but it does not replace broader domain checks. If a sender is failing SPF or DKIM elsewhere, a one-click header can be correct and still get inconsistent treatment. Use a domain health check before blaming the unsubscribe endpoint.
Views from the trenches
Best practices
Put the recipient and list token in the HTTPS URL, not in the one-click POST body.
Sign both unsubscribe headers with DKIM so mailbox providers fully trust the request.
Treat GET requests as previews or confirmations, never as automatic unsubscribe events.
Common pitfalls
Expecting Microsoft to send the subscriber ID in the POST body breaks working flows.
Sending an HTTPS List-Unsubscribe URL without RFC 8058 causes scanner-like requests.
Assuming the Outlook unsubscribe control appears for every valid message creates alarms.
Expert tips
Log method, path, query string, user agent, and status for every unsubscribe request.
Accept the exact one-click body, but base the unsubscribe decision on the URL token.
Test mailto and HTTPS options separately because clients choose fallback paths differently.
Expert from Email Geeks says Microsoft can send an RFC 8058 POST when the headers are valid, so a failed test should start with endpoint parsing and DKIM coverage.
2023-10-23 - Email Geeks
Marketer from Email Geeks says the Outlook unsubscribe control is not always obvious in the user interface, so absence of a button is not enough proof that the headers failed.
2023-10-23 - Email Geeks
The practical answer
Microsoft does support RFC 8058 List-Unsubscribe-Post, but the implementation has to match the RFC. The unsubscribe URL carries the recipient and list identity. The POST body carries the standard one-click signal. The endpoint removes the subscriber on POST and avoids removal on GET.
The visible Outlook button is useful evidence, not the only evidence. I trust the received headers and endpoint logs more than the UI. If Microsoft sends a POST to the encoded unsubscribe URL and your server processes it safely, the Microsoft side of list-unsub-post is working.
