List-Unsubscribe<https://email.example.com/unsubscribe/{{unsubscribe_token}}>, <mailto:unsubscribe@example.com?subject=unsubscribe>
ready All tools
RFC 8058 / ONE-CLICK POST / DKIM COVERAGEBuild the headers.
Build the headers.
Design the exit.
Generate the exact one-click header pair, model the receiver POST, and verify the endpoint and suppression work that a copied string cannot prove.
- Header injection checks
- POST contract
- Local generation
GENERATED MESSAGE HEADERS
Header pair assembled—verify the delivered message.
RFC 8058
RAW HEADER BLOCK4 physical lines · longest 80 bytes
List-Unsubscribe: <https://email.example.com/unsubscribe/{{unsubscribe_token}}>,
<mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-ID: Product updates <updates.example.com>List-Unsubscribe-PostList-Unsubscribe=One-Click
requiredList-IDProduct updates <updates.example.com>
optionalHeaders signal a capability; the endpoint and suppression system deliver it.
A compliant-looking pair is not enough if POST redirects, asks for confirmation, trusts a forgeable identifier, or leaves queued promotional mail active.
scheme and URI structure
alternate RFC 2369 action
998-byte hard limit review
attestations recorded
RECEIVER ACTION
The POST your endpoint must complete without a confirmation step.
POST /unsubscribe/opaque-token HTTP/1.1
Host: email.example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 26
List-Unsubscribe=One-ClickNot a crawler-triggered GET.
List-Unsubscribe=One-Click
No cookie or HTTP authorization dependency.
No redirect or extra recipient action.
DKIM SIGNING HANDOFF
Cover both fields after final header assembly.
Personalized URI is final.
Include list-unsubscribe and list-unsubscribe-post.
Inspect the delivered message.
h=...:list-unsubscribe:list-unsubscribe-post;Do not insert or rewrite the personalized unsubscribe fields after DKIM signing. Header order, canonicalization, and duplicate-field behavior belong to the signer configuration.
IMPLEMENTATION REVIEW
No blocking header issue found.
A physical line is longer than the recommended 78 characters
This is common for personalized URLs. The tool folds only between alternate URIs and preserves each URI without whitespace.
Operational evidence is incomplete
7 endpoint, signing, suppression, or message-control attestations remain unchecked.
The generated header syntax is coherent
One-click behavior still depends on final personalization, DKIM coverage, endpoint behavior, and suppression propagation.
TOKEN DESIGN
Put authorization in the opaque URI—not in cookies or a second form.
The delivered URI carries enough state to suppress exactly the intended subscription.
Reject tampered, guessed, expired-by-policy, or cross-list identifiers safely.
Repeated valid requests preserve the unsubscribed state.
OPERATIONAL EVIDENCE
0/7 checks recorded.
ENGINEERING HANDOFF
Export headers, endpoint assumptions, findings, and operator attestations.
THE PROTOCOL PAIR
One-click is two headers and a working HTTPS action.
RFC 2369 defines List-Unsubscribe URI syntax. RFC 8058 adds a separate signal that tells a receiver the HTTPS URI accepts an automatic one-click POST. A body link, mailto action, preferences page, or GET-only endpoint can be useful, but none alone is the RFC 8058 pair.
List-Unsubscribe: <https://example.com/u/opaque-token>List-Unsubscribe-Post: List-Unsubscribe=One-ClickENDPOINT CONTRACT
The URI must contain everything needed to finish the request.
The receiver POST has no recipient form, account session, cookie, or authorization header. The endpoint must validate the opaque URI state, identify the exact subscription, perform an idempotent suppression, and return directly without asking a person to confirm.
GETMay be prefetched by security systemsDo not auto-suppress
POSTUser-consented receiver actionComplete suppression
RedirectHistorically unreliable for POSTAvoid
PreferencesUseful visible body destinationNot one-click
AUTHENTICATED SIGNAL
Sign the final personalized fields.
RFC 8058 requires a valid DKIM signature that covers both List-Unsubscribe and List-Unsubscribe-Post. The signer must see the final personalized HTTPS URI. A downstream system that inserts or rewrites these headers after signing breaks that evidence.
SUPPRESSION SYSTEM
Stopping one campaign is not the same as honoring an unsubscribe.
- 01Receive
Accept the one-click POST without relying on browser state or interactive confirmation.
- 02Validate
Verify the opaque token and bind it to the intended recipient, tenant, list, and allowed action.
- 03Persist
Write an idempotent suppression event with an auditable timestamp and source.
- 04Propagate
Update segments, queues, replicas, vendors, and scheduled work before more list mail leaves.
- 05Verify
Test the exact delivered URI and inspect subsequent sends across every campaign path.
COMMON QUESTIONS
Does a mailto URI satisfy RFC 8058 one-click?+
No. It can be an alternate RFC 2369 action, but one-click requires an HTTPS URI plus List-Unsubscribe-Post.
Can the HTTPS URI open a preferences page?+
It may support a manual GET experience, but the receiver’s POST must complete the unsubscribe without another action.
Should the URL contain the recipient email?+
Prefer an opaque, hard-to-forge token that resolves to the recipient and list. Raw addresses leak identity and are easier to manipulate.
Why might an inbox not display an unsubscribe button?+
Correct headers signal capability, but mailbox providers can apply reputation, authentication, message classification, and product-specific eligibility checks before showing UI.
Are transactional messages required to carry one-click headers?+
Provider bulk-sender requirements generally target marketing or subscription traffic. Message classification and applicable law need contextual review, especially for mixed-purpose content.
PRIMARY REFERENCES