No regulator requires one opt-out to stop every channel. Do it anyway, and not for the reason you think.

A corridor of identical closed doors with a single one standing open and warm light spilling out.
Cite this as

Systems Ninjas (2026). Cross-channel opt-out scope across five regimes, and the identifier failure underneath it. Regulator positions researched 2026-08-06 against primary sources; platform behaviour measured 2026-08-12 across a 2,500-conversation sweep. systemsninjas.com/post/opt-out-one-channel-or-all

Take any of it. You do not need to ask. If you find an error in here we would rather hear about it than not, and the correction goes on the page.

You are probably not legally required to, and you should probably do it anyway. Those are two different answers to two different questions, and most of the advice you will find online quietly merges them.

Here is what the regulators actually say, what every major platform actually implements, and why we still recommend the stricter option for anyone whose business runs on messaging.

01 / The uncomfortable partThe uncomfortable finding first

There is no industry consensus for global cross-channel suppression. The consensus is: opt-out binds the channel it was given on, you must always offer a global "stop everything" option alongside, and an explicit request to stop entirely is absolute.

Two regulators state the channel-scoping rule in nearly identical words. Every major email and CRM platform implements per-channel suppression in its data model. And the one regulator that tried to MANDATE cross-topic suppression, in the US, has delayed its own rule twice on cost and burden grounds, currently to 2027-01-31.

If your instinct was "an opt-out anywhere should kill everything everywhere", that instinct is a defensible business choice. It is not the legal floor and it is not what the industry does. Know which one you are arguing, because you will eventually have to defend it to someone.

02 / The mapThe map

RegimeChannels coveredWhat an opt-out binds
US CAN-SPAMEmail onlyThat address, that sender. The statute does not reach other channels
US TCPA / FCCVoice and SMS to phone numbersThat number. A cross-topic rule is pending and has been deferred to 2027-01-31
UK PECR and UK GDPREmail, SMS, calls, postThe channel. An objection binds everything, and it is absolute
Singapore PDPA (Do Not Call)Voice, SMS, and messaging apps reached via a phone number, including WhatsApp. Not Instagram or MessengerExplicitly that channel only, unless your notice says otherwise
Australia Spam ActEmail, SMS, MMS and instant messaging including WhatsAppPer electronic address, within five business days

Note the Singapore line carefully, because it is the one that surprises people: a messaging app reached via a phone number is inside the do-not-call regime. A messaging app reached via a social profile is not.

03 / Seven rulesThe seven rules that actually govern this

  1. An opt-out binds the channel it was given on, and all message types on that channel, not just the campaign that triggered it.
  2. An explicit objection ("stop contacting me entirely") is absolute, channel-agnostic and cannot be refused. No particular form of words is needed. It can arrive verbally, in a DM, to anyone in your organisation.
  3. Always offer a global off-switch alongside any granular preference menu. A preference centre with no "none of it" option fails under US statute.
  4. Label the scope of every opt-out at the point you offer it. "Unsubscribe" alone does not tell anyone what they just switched off.
  5. Ambiguous scope means suppress broadly. You may send one non-promotional message asking them to narrow it. Absent an answer, stop everything that needs consent.
  6. Marketing suppression must never kill transactional messages. Firewall them structurally, before you turn any of this on. An appointment reminder is not marketing and a customer who stops receiving theirs is a support problem you created.
  7. Suppress, never delete.

04 / Rule 7Rule 7 is the one people get wrong

The UK regulator publishes the worked example, and it is perfect. A company deleted an opted-out phone number, because deleting felt like the respectful thing to do. Later it bought a marketing list, the same number was on it, they called, and they were in breach.

Keeping a suppression list is not "processing their data for marketing". It is how you comply. Deleting an opt-out is the classic own goal, and it always fails on the second contact rather than the first, which is why nobody catches it in testing.

05 / Our recommendationOur recommendation, and it is a business argument not a legal one

For a business whose primary channel is WhatsApp or SMS, suppress globally. Not because the law requires it, but because the failure modes are wildly asymmetric.

  • Over-suppressing costs you one contact's marginal revenue, and it is reversible. They can opt back in.
  • Under-suppressing produces exactly the complaint pattern that damages a shared account-level quality rating. On WhatsApp specifically, that rating is scored over a rolling window and it throttles sending for everyone on that business number, not just the person who complained. The block reason a cross-channel leak produces is "didn't sign up", which is the most damaging one available.

So the cost of being slightly too strict falls on one relationship. The cost of being slightly too loose falls on your entire list. That is not a close call, and it is a much better argument than "it is the right thing to do", because it survives a conversation with someone counting revenue.

One thing we will not do is quote you a return-on-investment figure for preference centres. Every one we traced leads to an uncited vendor blog post.

06 / The identifier failureThe failure that has nothing to do with policy

A suppression list is only as good as the identifier it joins on, and on WhatsApp that identifier can now be absent.

Since a platform-level change reached this market in 2026-07, an inbound WhatsApp contact can arrive with a system identifier and no phone number at all. We measured it: a sweep of 2,500 conversations found 30 affected contacts, starting from a specific date and rising, roughly 1 to 2% of new WhatsApp contacts at the time.

Nothing is broken and nothing was deleted. The platform stored exactly what it was sent. But:

  • A suppression list held OUTSIDE your CRM and keyed on phone number cannot match those people. Spreadsheets, import files, another vendor's list.
  • Import deduplication is the live danger. A later import carrying the same person WITH a number will not match the phone-less record. You now have a duplicate that inherited none of the suppression, which is rule 7's failure arriving through a different door.
  • Any export or reporting join that assumes a phone number exists silently drops or mis-buckets those contacts.

07 / Our own correctionAnd a correction we owe against our own reasoning

When we first wrote this up, we stated that a phone-keyed suppression system "cannot match these contacts, so someone who opted out can be re-messaged".

That was reasoned from the data model and never measured, and measurement contradicted it. We went and read a real opted-out record with no phone number on it. The opt-out had landed correctly on every channel, because the platform stores suppression against the CONTACT, not against the phone number. A missing phone is irrelevant to it.

The real exposure turned out to be narrower and entirely at the joins: external lists, imports, exports. Which is a smaller finding, a more precise one, and one we would not have reached by thinking harder about it.

That is the general lesson and it is worth more than the specific one. A mechanism that explains the symptoms is not evidence. Go and read the record.

Regulator positions researched 2026-08-06 against primary sources; the platform behaviour measured 2026-08-12. Malaysia's PDPA section 43 is deliberately NOT covered here, because we have not verified it and we are not going to state a position we cannot support. This is not legal advice.

We will read your current suppression setup and tell you where it leaks

Most leaks are not in the policy, they are at the joins: a list held outside the system, an import that does not match, an export that assumes a phone number exists. Send us how you handle an opt-out today and we will tell you which of the seven rules you already meet, and which one will fail on the second contact rather than the first.

Find the leak [email protected] · No client of ours is named anywhere on this page, and if you become one, you will not be either.
Uldis Zalcmanis
Written by

Uldis Zalcmanis aka Systems Rockstar

Founder, Systems Ninjas · Kuala Lumpur

I build the automation and AI systems businesses actually run on, and I am the person who gets called when one of them quietly stops working. Born in Riga, based in Malaysia, father of two, and constitutionally unable to stop reading page source.

The Lab is where the measurements get published, including the ones that do not flatter us.

↑