{"schema_version":"2.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/email-one-click-unsubscribe-header-proof","id":"email-one-click-unsubscribe-header-proof","slug":"email-one-click-unsubscribe-header-proof","title":"Verify One-Click Unsubscribe in Received Email Headers","description":"Distinguish a footer browser link from RFC 8058 mailbox-driven unsubscribe. A received-message header and endpoint acceptance checklist.","dek":"Distinguish a footer browser link from RFC 8058 mailbox-driven unsubscribe. A received-message header and endpoint acceptance checklist.","category":"Deliverability","topics":["Migma","email marketing","deliverability"],"publishedAt":"2026-09-18","updatedAt":"2026-09-18","lastVerifiedAt":"2026-09-18","readingMinutes":4,"author":"Marketing Wiki Research Automation","reviewer":null,"featured":false,"sources":[{"title":"Migma: Preference center and unsubscribe","url":"https://docs.migma.ai/audience/preference-center?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-one-click-unsubscribe-header-proof"},{"title":"Migma: Export options","url":"https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-one-click-unsubscribe-header-proof"},{"title":"IETF RFC 8058: One-Click Unsubscribe","url":"https://www.rfc-editor.org/rfc/rfc8058?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-one-click-unsubscribe-header-proof"}],"wordCount":787,"body":"Verify one-click unsubscribe on a received message from the actual sending path used for your Migma campaign. A visible footer link and an inbox provider's unsubscribe action are different mechanisms; successfully opening the footer does not prove RFC 8058 support.\n\n> **Editorial disclosure:** Prepared by Marketing Wiki Research Automation under standing direct-publication authorization and not independently reviewed. Product capabilities are vendor-documented unless labeled otherwise; sources were refreshed on September 18, 2026.\n\n> **Affiliation disclosure:** Marketing Wiki’s commissioning maintainer also maintains Migma. This guide is published directly by automation without independent review.\n\nMigma's [preference-center documentation](https://docs.migma.ai/audience/preference-center?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-one-click-unsubscribe-header-proof) describes browser-based subscription management but explicitly lists RFC 8058 headers as unavailable. Treat that as the current documented limitation, not a measured statement about every message emitted by every connected provider. Its [export guide](https://docs.migma.ai/email-editor/export-options?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-one-click-unsubscribe-header-proof) distinguishes the destination that owns the final send. We recommend verifying the received artifact for that destination before making a protocol claim.\n\n[RFC 8058](https://www.rfc-editor.org/rfc/rfc8058?utm_source=marketingwiki&utm_medium=referral&utm_campaign=email-one-click-unsubscribe-header-proof), published in January 2017, defines an HTTPS POST mechanism using `List-Unsubscribe` and `List-Unsubscribe-Post`, with the relevant headers covered by a valid DKIM signature. This article is an evergreen verification method; it does not announce a new mailbox-provider deadline.\n\n## Ask for the right artifact\n\nAn HTML export contains the message body, not necessarily the final transport headers. A design screenshot cannot show them. Ask the delivery owner for the raw source of a controlled received message sent through the intended production path to an authorized test recipient.\n\nPreserve the sending configuration and time alongside the source. Remove recipient tokens and other sensitive values from any shared review excerpt. The reviewer needs to know whether the required fields and signature coverage exist, not possess a working unsubscribe URL for a real subscriber.\n\n## Inspect the protocol as a connected set\n\nUse this acceptance checklist with the engineer who owns delivery:\n\n| Evidence | Question to resolve |\n| --- | --- |\n| List-Unsubscribe header | Is the required HTTPS URI present? |\n| List-Unsubscribe-Post header | Does it specify the one-click action defined by the RFC? |\n| DKIM signature | Does a valid signature cover both relevant headers? |\n| Endpoint contract | Does the server accept the specified POST without an interactive login? |\n| Controlled state change | Does the authorized fixture become unsubscribed as intended? |\n| Later audience decision | Is the resulting state respected before another marketing send? |\n\nThe protocol header value to look for is `List-Unsubscribe-Post: List-Unsubscribe=One-Click`. That field works together with the HTTPS address in `List-Unsubscribe`; neither field alone proves a functioning unsubscribe.\n\nDo not mark the checklist complete because the field names appear in a copied template. Signature validity and endpoint behavior require their own evidence. The final row extends the protocol check into business behavior; it does not replace the earlier protocol requirements.\n\n## Keep browser navigation and POST testing separate\n\nThe RFC was designed in part to distinguish deliberate one-click requests from automatic fetching of unsubscribe URLs. A browser visit usually exercises a different request path from the specified POST. Do not use a production subscriber's link as a convenient diagnostic target.\n\nHave the delivery engineer prepare a controlled subscriber and an authorized test. Record the request type, response and resulting subscription state without publishing a token. The method should not require cookies, a login session or additional user interaction to complete the RFC one-click action.\n\nA successful HTTP response alone is insufficient: inspect the stored subscription outcome. Conversely, a footer link that immediately changes state may work as a browser unsubscribe while still failing to establish the separate header protocol.\n\n## Apply the result to the Migma handoff\n\nWhen Migma supplies creative to another sending platform, keep the footer and preference wording accurate, then assign final header verification to the platform that sends the message. Do not assume the exporter adds delivery headers or that the destination preserves every setting from an earlier campaign.\n\nFor native sending, ask for current implementation confirmation if the documented limitation conflicts with observed received headers. Preserve both pieces of evidence and their dates. A fresh controlled artifact can clarify one path; it cannot justify claiming universal support across all historical or external paths.\n\nIf the protocol is unavailable on the required route, report that limitation and choose an approved sending route that meets the team's requirements. Do not disguise a browser link as standards support in the campaign readiness record.\n\nThe [unsubscribe reconciliation runbook](/articles/unsubscribe-webhook-reconciliation-runbook) starts when a subscription change must propagate between systems. This checklist establishes the recipient-facing mechanism before that propagation. No unsubscribe request or test email was sent for this article. Begin by collecting a permitted raw message from the exact route you intend to use, then leave any untested checklist item explicitly unresolved."}