One-click unsubscribe connects two systems: the message that advertises the action and the service that processes it. A correct-looking header is only half the implementation. The endpoint must identify the intended subscription, accept the specified request without a login, and make the opt-out effective.
Construct the message before signing it
RFC 8058 calls for one List-Unsubscribe field containing an HTTPS URI and one List-Unsubscribe-Post field containing List-Unsubscribe=One-Click. A valid DKIM signature must cover both fields. Other non-HTTP/S unsubscribe URIs, such as mailto, may also appear in List-Unsubscribe. RFC 8058 sections 3 and 4.
A minimal illustrative header pair is:
List-Unsubscribe: <https://unsubscribe.example.test/u/opaque-token>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
The reserved hostname and token are teaching placeholders, not an operational endpoint. Add these fields before the final relevant signing step. Inspect the emitted message to ensure the signature's h= list includes them and cryptographic verification succeeds after all transformations.
Make the URI identify the exact action
The URI must carry enough information to identify the recipient and list. The receiver cannot supply an extra recipient field or answer a preferences questionnaire. Use an opaque, hard-to-forge component and validate it at the endpoint. Avoid exposing addresses unnecessarily in URLs, logs or analytics.
Treat the token as authority to perform a narrowly scoped unsubscribe, not as a general account credential. Someone with access to the message may be able to use it. Do not let it change account ownership, sign in as the user or alter unrelated subscriptions. Choose retention and expiry behavior deliberately so old messages do not become useless opt-out paths without a considered policy.
Process the specified POST directly
The receiver sends an HTTPS POST with the advertised key/value pair in its body. RFC 8058 allows application/x-www-form-urlencoded and recommends multipart/form-data. The request must not rely on cookies, HTTP authorization or prior browser context. The sender must not return an HTTPS redirect. The receiver must obtain user consent before performing the action.
A body link can still offer a human-readable preference page, but the POST action must complete without further interaction. As an implementation safeguard, keep GET requests non-destructive so automatic link fetching does not itself remove a subscriber. That safeguard is an operational design recommendation motivated by the problem the RFC addresses.
Verify application state, not just a status code
Suppose a hypothetical endpoint returns success for a valid newsletter token, but the next campaign export still includes that same recipient/list pair. The protocol request may have reached the service, but the operational suppression is not established. Inspect the durable decision, propagation acknowledgement and audience-selection input rather than treating the status code as completion.
For an authorized test, define expected outcomes first: a GET and an invalid token should not remove subscriptions; a valid POST should affect only its intended pair; repeating it should preserve that same final state. These are design expectations, not executed local or production tests.
For deployment, separately verify TLS certificate validity, hostname, public reachability, both supported form encodings, proxy behavior and rate limits. Check that the response does not redirect to a login or tracking service. Ensure the next campaign selection honors the suppression, including any caches or third-party exports.
Operate the endpoint as a durable service
Make repeated valid requests safe, record a minimal audit event and monitor failures without exposing tokens. Alert on processing errors and suppression backlogs. A response that claims success before a durable update needs a reliable processing design and bounded completion time.
Close the implementation with message verification, endpoint tests and an observed next-send exclusion for a controlled recipient. None of these alone proves that every mailbox interface will display an unsubscribe button.
Choose the repair from the failed checkpoint
A redirect or login requirement calls for endpoint repair. A wrong recipient/list mapping calls for authorization-scope repair. A correct endpoint with a stale campaign export calls for propagation repair. Do not close all three because one POST returned success.