# One-click unsubscribe in Salesforce Marketing Cloud

> Understand one-click unsubscribe on Salesforce Marketing Cloud commercial sends and validate the delivered-message result.

One-click unsubscribe in Salesforce Marketing Cloud Engagement is documented for commercial sends: the platform includes the List-Unsubscribe header, and an inbox provider may use it to present an unsubscribe control. When a provider sends the RFC 8058 POST, Salesforce handles it as a publication-list unsubscribe. You cannot force an inbox to display the control, so validate the headers in a real commercial test message and verify the resulting subscriber status. [Salesforce's List-Unsubscribe documentation](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5) is the controlling product source.

## Quick takeaways

- Salesforce documents the header behavior for commercial sends, not every message type or every mailbox interface.
- Inbox providers decide whether to show a built-in unsubscribe control.
- A one-click request is separate from an unsubscribe link in the email body or a custom preference center.
- Salesforce documents the resulting action as an unsubscribe from the publication list.
- Inspect a delivered commercial message before treating the feature as working for your sending path.

## Who is affected?

This applies to operators who send commercial email through Salesforce Marketing Cloud Engagement and need to understand what a mailbox-provider unsubscribe action changes. [Salesforce's unsubscribe documentation](https://help.salesforce.com/s/articleView?id=sf.mc_es_unsubscribes.htm&language=en_US&type=5) distinguishes list, publication-list, and broader unsubscribe states. This article concerns the documented header-driven publication-list outcome, not a custom CloudPage, preference-center design, or consent synchronization with another system.

The mailbox, not Marketing Cloud Engagement, controls whether a recipient sees an unsubscribe control. A missing control in one mailbox is therefore not proof that Salesforce failed to include the header. For the vendor-neutral header pair, POST rules, and DKIM coverage, see [our RFC 8058 one-click unsubscribe guide](/learning/one-click-unsubscribe).

## What are the requirements?

### Commercial sends use the documented header path

[Salesforce Help says commercial sends include the List-Unsubscribe header](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5), and that customers cannot disable or alter this header behavior. Its documentation also states that an inbox provider can use the header to offer an unsubscribe option. That describes the sending-platform behavior; it does not require a particular Gmail, Yahoo, or Outlook display.

```text
Delivered commercial test message
  List-Unsubscribe: <https://...>
  List-Unsubscribe-Post: List-Unsubscribe=One-Click

Expected evidence: headers in the raw message, not a guaranteed inbox button.
```

### A one-click request is a mailbox-to-sender POST

[RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) is an Internet Standards Track specification. It defines a `List-Unsubscribe` HTTPS URI and `List-Unsubscribe-Post: List-Unsubscribe=One-Click` as the one-click signal. A receiver may send an HTTPS POST after user consent; it should use `multipart/form-data` and may use `application/x-www-form-urlencoded`. The standard requires no cookies or HTTP authorization in that POST and says the sender must not rely on an HTTPS redirect.

![Commercial send to header, optional mailbox control, RFC 8058 POST, and publication-list unsubscribe.](/images/editorial/one-click-unsubscribe-marketing-cloud/one-click-unsubscribe-marketing-cloud-flow.svg "800x1500")

*Source: Original Palisade protocol flow based on [Salesforce Help's List-Unsubscribe behavior](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5) and [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html). It illustrates the documented request path, not a mailbox or Salesforce interface. [Open the full-size diagram](/images/editorial/one-click-unsubscribe-marketing-cloud/one-click-unsubscribe-marketing-cloud-flow.svg).*

### The documented Salesforce outcome is publication-list unsubscribe

[Salesforce documents the resulting one-click POST as a publication-list unsubscribe](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5). Do not infer from that alone that a CRM consent record, another data extension, or an external suppression system has changed. Those integrations and any broader consent policy need their own tenant-specific evidence.

## When does the requirement take effect?

The Salesforce behavior above is product documentation, not a date-based mailbox-provider mandate. For Gmail, [Google's Email sender guidelines](https://support.google.com/a/answer/81126) apply one-click unsubscribe requirements to covered bulk senders of marketing and subscribed messages. The applicable provider rule depends on the recipient provider and sending volume, while the Salesforce question is whether the delivered commercial message follows the documented header path. Check the current provider guidance when the campaign is in scope for a bulk-sender rule.

## How do I implement the requirement?

### 1. Confirm that the send is commercial

Use the same commercial message type and sending path that your subscribers receive. Salesforce scopes the documented automatic header behavior to commercial sends, so a transactional or custom path is not evidence for this case. Keep the body unsubscribe link and preference-center workflow under their own requirements.

### 2. Send a controlled message and inspect its raw source

Deliver a test to a mailbox you control, then inspect the original message source. Record whether `List-Unsubscribe` and `List-Unsubscribe-Post` appear. The raw headers are stronger evidence than a mailbox button because Salesforce states that the inbox provider controls the display.

### 3. Verify the publication-list result safely

Where your test procedure permits it, use the mailbox's unsubscribe action and confirm the expected publication-list status in an approved non-production test record. Do not test against a customer address or assume the result proves changes in connected CRM or consent systems. If the header is absent, first confirm the message was a commercial send before escalating the case with the delivered headers.

## How do I validate compliance?

Start with the delivered message and the intended subscriber outcome. A useful validation record includes the send classification, the raw `List-Unsubscribe` and `List-Unsubscribe-Post` lines, the mailbox provider used for the test, and the observed publication-list status after an approved test. Keep screenshots of inbox controls optional, because an interface can change or remain hidden even when the header is present.

For broader provider readiness, use the [Gmail and Yahoo sender-requirements checklist](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025) and distinguish it from [email authentication](/learning/what-is-email-authentication-and-why-does-it-matter). DNS, SPF, DKIM, and DMARC evidence can support authentication troubleshooting, but they do not prove that a specific Marketing Cloud Engagement message contained the one-click header or that its publication-list update completed.

## Check the wider provider requirements

Once the commercial-send test is documented, compare the campaign with the wider [Gmail and Yahoo 2024 sender update](/resources-post/how-to-make-sure-you-hit-your-leads-inbox-gmail-and-yahoo-update-2024). That guide is the closest next step for a team that needs the rest of the provider rules alongside this Marketing Cloud Engagement behavior.

[Review the sender-requirements checklist](/learning/google-is-making-email-sender-requirements-stricter-starting-nov-2025)

That checklist cannot inspect a delivered Marketing Cloud Engagement message, force a mailbox control to appear, or prove a subscriber-status or consent-system change.

## Sources and further reading

- [Salesforce Help: List-Unsubscribe Header Unsubscribe](https://help.salesforce.com/s/articleView?id=sf.mc_es_one_click_header_unsubscribe.htm&language=en_US&type=5)
- [Salesforce Help: Unsubscribes](https://help.salesforce.com/s/articleView?id=sf.mc_es_unsubscribes.htm&language=en_US&type=5)
- [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html)
- [Google Email sender guidelines](https://support.google.com/a/answer/81126)

## Frequently asked questions

### Does Salesforce Marketing Cloud Engagement always show an unsubscribe button?

No. Salesforce documents the header on commercial sends, but the inbox provider decides whether to present an unsubscribe control. Inspect the delivered raw message to verify the header path before using the absence of a button as a troubleshooting signal.

### Does one-click unsubscribe replace the email footer link?

No. The header-driven action and an in-message unsubscribe or preference-center link serve different paths. Keep the body link according to your applicable provider and legal requirements, even when the commercial message contains the one-click headers.

### What status does the Salesforce one-click request change?

Only the documented outcome is a publication-list unsubscribe. Do not assume that a universal unsubscribe, global unsubscribe, CRM consent record, or another connected suppression system changes unless your tenant configuration and integration evidence confirm it.

### Can I customize the Salesforce one-click headers?

No. Salesforce's List-Unsubscribe documentation says customers cannot disable or alter the headers for the documented commercial-send behavior. Use a delivered-message test to establish what your actual sending path contains instead of attempting to construct a replacement header.

### What should I retain from a validation test?

Keep the commercial send classification, raw header lines, the receiving mailbox provider, the date, and the publication-list result from an approved test record. Those facts let you separate platform behavior from mailbox display and from any separate consent-system synchronization.