Suppression is brand-wide, not per number

The requirementstatement

An opted-out consumer must be suppressed across every sending number and every campaign belonging to the brand, not only the number that received the STOP.

Severityseverity: HighHIGHRejected by at least one carrier or provider, and a common cause of failure at the rest.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: suppression list scope across the brand
Where it liveslayer: OperationalOPERATIONAL
How Ekas settles itdetectability: Post-submissionUNDETECTABLE_PRE_SUBMISSION; The subject does not exist yet at submission time: a reply window, an expiring PIN, a queue position. Reported with its deadline.
What the fix involvesfailureClass: Wait on someone elseTERMINAL_EXTERNAL; Needs an external system or a waiting period, such as IRS propagation, a vetting result, or a carrier queue.
Who requires itauthorities: FCCCTIA
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

Consumers experience a brand, not a sending number. Suppressing only the number that received the STOP means the next campaign — or the next number in the pool — reaches them anyway, and from their point of view the brand ignored them and changed number to do it. That is also exactly what filter-evasion looks like from the carrier's side, so the accidental version is punished like the deliberate one.

How to fix itremediation

Scope the suppression list to the brand and check it before every send on every campaign and number. Done when a STOP received on one campaign prevents a send on a different one to the same number.

A compliant exampleexample

Suppression keyed on (brand_id, msisdn) rather than on (campaign_id, sending_number, msisdn).

Common mistakespitfalls

A number pool makes this worse rather than better: the next send picks a different originator, so a per-number list looks like it is working right up until the consumer complains.

Check this yourselfattestation

No tool can settle this one for you. Here is the check, and what wrong looks like.

Does a STOP received on one campaign prevent a send on a different campaign, or a different number, to the same person?

1Ask your platform how the suppression list is scoped. Per campaign is a common default.
2Test across two campaigns on the brand, and across a number pool if you use one.
3Compare two campaigns' recipient lists — nothing else makes this visible.

What wrong looks like: The next campaign, or the next number in the pool, reaches them anyway. From the consumer's side the brand ignored them and changed number to do it, which is also what filter evasion looks like from the carrier's side.

Notesnotes

A property of the platform's data model. What the user has to establish is how their platform scopes suppression, because per-campaign is a common default and nothing about it is visible until somebody compares two campaigns' recipient lists.

Rules you will hit next

Other operational rules at the same severity. A registration is judged as a whole, not rule by rule.

OPS-034A programme in another language still owes the English keywordHighHIGH OPS-035The mandatory keywords must work over MMS tooHighHIGH OPS-047A state may give you less time than the federal limitHighHIGH OPS-052Silence after a scope question revokes everythingHighHIGH OPS-053A STOP answering a scope question must not be answered with anotherHighHIGH OPS-054Revoking against an exempt message stops everything else tooHighHIGH

All operational rules

OPS-044 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.