Salesforce Link Expirations Break Opt-Out Compliance

On Friday, January 24, Salesforce notified many Marketing Cloud Engagement (f/k/a "Salesforce Marketing Cloud") customers of a security vulnerability affecting links in previously sent emails. On January 21, it changed the encryption scheme used for links, and two days later it expired all links generated before the update, including Clicks, CloudPages, Forward to a Friend, Profile Center, Subscription Center, Unsub Center, and View as Web Page links.¹

Salesforce's decision to invalidate those links has real consequences for its customers' opt-out obligations.

CAN-SPAM and CASL both require the opt-out link to keep working

CAN-SPAM requires that opt-out mechanisms "remain[] capable of receiving such messages or communications for no less than 30 days after the transmission of the original message."² Any commercial email whose unsubscribe link stops working within that window violates the law and exposes the sender to potential liability, unless it qualifies for the safe harbor discussed below.

CASL imposes a stricter standard. Canada's anti-spam law requires the unsubscribe mechanism to remain valid for at least 60 days after transmission.³ Salesforce's default URL lifespan of 60 days matches that requirement. The mass expiration of those links on January 23 means any commercial email to Canadian recipients sent as far back as November 22, 2025, now has a non-functional opt-out mechanism inside the statutory window.

The CAN-SPAM safe harbor doesn't cover a deliberate fix

CAN-SPAM includes a safe harbor. An unsubscribe mechanism does not fail the statutory requirements if it is "unexpectedly and temporarily unable to receive messages or process requests due to a technical problem beyond the control of the sender if the problem is corrected within a reasonable time period."⁴

Every element has to be present. The cause must be a technical problem beyond the sender's control. It must leave the mechanism unable to receive or process unsubscribe requests. And the failure must be unexpected, temporary, and corrected within a reasonable time.

Salesforce would likely argue that the safe harbor applies because the vulnerability was a technical problem, and that problem has been corrected through the encryption upgrade. Under this reading, the mechanism was compromised by the security flaw, and Salesforce fixed it. The cost of that fix was expiring vulnerable links, but the underlying system now works properly.

I believe that argument is flawed. The safe harbor applies when a mechanism is "unable to receive messages or process requests due to a technical problem" (emphasis added). I believe the language contemplates scenarios such as a data center losing power, where servers cannot receive or process requests for the few minutes it takes backup systems to engage, or even the need to spin up new servers after a ransomware attack that takes days to recover from. In those cases, no one would be responsible for a failure to process opt-out requests.

Salesforce's situation is different. It can plainly receive the requests. Its inability to process more than two months' worth of them must be "due to a technical problem," not to the fix, for the safe harbor to apply. The only reason Salesforce can't process these requests on behalf of its customers is that it took affirmative action that left it unable to. A deliberate decision to break the links as part of a remediation strategy is not a "technical problem" causing the inability.

The safe harbor also requires that "the problem is corrected within a reasonable time period." I am more than willing to believe Salesforce when it says that it fixed a data security issue. But "corrected," as the statute uses that word, should mean the original mechanism is restored to functionality, not replaced with something incompatible. The statute contemplates a temporary outage followed by restoration. Here, the links in previously sent emails are permanently non-functional. A recipient clicking an unsubscribe link in an early-January email will never reach the intended destination through that link. The problem has not been corrected for those messages. It has been made permanent.

CASL offers even less. Section 11 contains no safe harbor for technical problems. If the electronic address or web page is not valid for 60 days after transmission, the sender is non-compliant.

A custom destination URL restores an opt-out path

CAN-SPAM's obligations fall on message senders. There was one FTC settlement, with Yesmail, treating a service provider as an initiator,⁵ but the statute's expectations generally run to senders, not their vendors. So, Salesforce customers need to work out what they can do to be as compliant as possible.

The good news, such as it is, is that Salesforce lets administrators configure a custom destination URL. By default, expired links redirect to a Salesforce error page, but organizations can change that.

For CAN-SPAM compliance, consider pointing expired links to a dedicated subscription management or opt-out page. When a recipient clicks any expired link in the email, including a product link or other tracking URL, they land on a page that lets them unsubscribe. That is not a great experience for someone trying to click through to your content, but it restores a functional opt-out path for the original transmission.

Under CASL, this approach may also satisfy the section 11 requirement that the "electronic address or World Wide Web page" remain valid,⁶ again at the expense of user experience.

Senders need to act on their own exposure window

Organizations using Marketing Cloud Engagement should start by assessing their exposure window. Review send dates for commercial emails transmitted on or before January 21 to identify messages still inside the 30-day CAN-SPAM window or the 60-day CASL window (back to December 22 and November 22, respectively).

Statutory compliance problems deserve a conversation with a qualified attorney who can explain your rights and obligations for your specific situation. While that happens, document your response. If regulators or litigants later question compliance, contemporaneous records showing that you identified the issue, assessed its scope, and put a remediation path in place demonstrate good faith.

Configure your custom destination URL to route expired links to a page where recipients can opt out. It is an imperfect solution, but it should close the compliance gap. After the windows have run (February 20 for CAN-SPAM and March 22 for CASL), you can change the custom destination URL back to its default or to whatever you would like.

Then ask Salesforce, in writing, what it is doing to make sure unsubscribe requests are honored when they are received. Salesforce caused this problem, and its customers shouldn't have to absorb the compliance cost of fixing it without that assurance on paper.

This post does not constitute legal advice. Readers should consult competent legal counsel before taking action based on the analysis presented here.