One-click unsubscribe lets a recipient’s mail service request removal from a mailing list without a website confirmation step. For Gmail’s bulk-sender requirement, a footer link alone does not count: you need the correct email headers and a working HTTPS unsubscribe action. Keep a visible body link too, and verify which future marketing sends the opt-out stops.
Treat this as a sending-system check. A template with an “Unsubscribe” link is a useful starting point, but the acceptance test should also cover the request handler and the resulting contact status.
Is one-click unsubscribe different from a footer link?
Yes. Header-based one-click and the visible link in your email are separate mechanisms. The headers carry instructions for the receiving mail system. The body link gives the reader somewhere to click inside the message.
Google’s sender guidelines require both for marketing and subscribed messages from bulk senders to personal Gmail accounts. Replacing a footer link with a prominent button does not supply the missing headers.
A preferences page can still have a place. Google’s FAQ permits a body link to lead there when compliant header-based one-click is also present. Keep that distinction in your brief to the person building the email: the preference experience and the automatic unsubscribe action each need checking.
This article covers how someone leaves a mailing list. Whether you may send to them in the first place is a separate question covered in the email consent guide.
What do Gmail and Yahoo require?
Under their bulk-sender rules, Gmail and Yahoo require one-click unsubscribe plus a visible body unsubscribe link for marketing and subscribed mail. Their accepted header methods and processing expectations differ, as shown below.
| Check | Gmail | Yahoo |
|---|---|---|
| Relevant messages | Marketing and subscribed mail under its bulk-sender guidelines | Marketing and subscribed mail under its bulk-sender requirements |
| Header mechanism | RFC 8058 HTTPS one-click; mailto alone does not satisfy it | Functioning one-click list-unsubscribe; RFC 8058 POST is highly recommended, and mailto is also accepted |
| Visible unsubscribe link in the body | Required | Required; may lead to preferences |
| Processing time | Google’s FAQ recommends fulfilling requests within 48 hours | Yahoo requires honoring unsubscribes within two days |
These distinctions come from Google’s guidelines and FAQ and Yahoo’s sender requirements. An RFC 8058 HTTPS setup addresses Gmail’s specified mechanism and Yahoo’s recommended method; that does not make their rules identical.
Google’s FAQ excludes transactional messages from its one-click requirement, giving password resets and reservation confirmations as examples. Keep the audit focused on the message’s purpose, with a separate row for each marketing route you operate.
What should the headers and unsubscribe action do?
RFC 8058 requires an HTTPS unsubscribe address, a header specifying the POST action and a valid DKIM signature covering both unsubscribe headers.
This is an illustrative structure, using a placeholder domain and token, not a working endpoint:
List-Unsubscribe: <https://example.com/unsubscribe/recipient-list-token>
List-Unsubscribe-Post: List-Unsubscribe=One-ClickThe receiving service sends an HTTPS POST with List-Unsubscribe=One-Click in its body. The URL must identify the recipient and list without requiring a logged-in browser session. The request does not carry cookies or HTTP authorization, and its handler must not return an HTTPS redirect.
The standard also requires a valid DKIM signature covering both unsubscribe headers. Ask the technical owner to verify that coverage; seeing the two field names is only the first check.
Why distinguish a POST from opening a link? The RFC describes anti-spam software fetching URLs automatically and accidentally causing unsubscribes. Do not accept “opening the URL in a browser worked” as proof that the required POST works. Give the provider or developer the delivered message and ask them to check that specific request path.
How do you test one-click unsubscribe before sending?
Use controlled subscribed test contacts and send representative marketing messages through the routes you intend to use. The following is a proposed audit, not a claim that any platform has been tested here.
| Audit item | Evidence to retain | Decision it supports |
|---|---|---|
| Delivered message | Sending service, campaign or flow, recipient and raw message headers | Which route was actually checked? |
| Header and signing check | Both unsubscribe fields; technical confirmation of valid DKIM coverage | Are the mechanism and authentication present? |
| Request handling | Technical owner’s result from exercising the HTTPS POST for the controlled contact | Does the action complete without a login, extra confirmation or redirect? |
| Visible body link | Destination and the steps a reader encounters | Can the reader use the separate body-link route? |
| Contact state | Before/after subscription or list status, with the request and processing times | Was the intended opt-out recorded? |
| Later send eligibility | Whether that contact is excluded from the marketing sends within the promised scope | Does the recorded state affect the sends it should? |
Keep the result beside the route name and its owner. “Headers present; request handler not checked” is a useful open issue. So is “contact removed from newsletter list; other promotional route unverified.” Neither should be recorded as a completed end-to-end test.
Do not use Gmail’s visible top-of-message unsubscribe control as the sole verdict. Google says its display depends on automated eligibility checks as well as correct headers and sender requirements. If it is absent, inspect the message and request path before deciding what failed. For a broader authentication or delivery problem, use the deliverability guide.
Which future messages should the unsubscribe stop?
Write down the scope you promise the recipient, then check the systems responsible for honoring it. Google’s FAQ says one-click can remove someone from the mailing list associated with the message; it does not automatically require removal from every list belonging to that sender.
Product settings matter. Klaviyo documents automatic one-click headers for supported inboxes and global unsubscribe behavior by default. Paid plans can configure list-specific behavior for list-based sends. Its documented exception is a campaign sent to multiple lists: unsubscribes are always global. Confirm the behavior of the send you are auditing.
Consider an invented setup: an ESP sends your newsletter, while a separate application sends promotional reminders. Your declared policy is that unsubscribing stops both kinds of marketing.
The newsletter test shows the controlled contact has opted out in the ESP. That establishes the first result. Before signing off the promised scope, ask the reminder application’s owner to demonstrate that the same contact is excluded there too. If that check has not happened, record it as unverified rather than assuming the ESP result covers it.
If you offer list-specific opt-outs instead, name the list and check that scope. The audit should test the promise you make, not silently substitute a narrower one. Finish with a record of which message was tested, what changed, which later sends are excluded and who owns any remaining gap.
Frequently asked questions
Does a footer unsubscribe link satisfy Gmail’s one-click requirement?
No. Gmail’s bulk-sender rules require header-based RFC 8058 one-click for marketing and subscribed messages, alongside a visible body unsubscribe link. A footer link by itself does not satisfy the header requirement.
Is a mailto List-Unsubscribe header enough for Gmail and Yahoo?
It is not enough for Gmail’s one-click requirement, which needs RFC 8058 HTTPS functionality. Yahoo’s bulk-sender guidance accepts mailto and highly recommends RFC 8058 POST. Both also require a visible unsubscribe link in the message body for the relevant mail.
Can the footer link go to a preferences page?
Yes. Google’s FAQ permits a body link to a preferences page when compliant header-based one-click is also implemented. The page alone does not replace that mechanism.