Revoke-all across categories has a deadline

JSONMarkdown

The requirementstatement

A suppression architecture that cannot revoke across every message category for a sender must be flagged before the federal revoke-all rule takes effect on 31 January 2027.

Severityseverity
LowLOWBest practice. Worth fixing, rarely fatal on its own.
When it bitesphase
After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject
suppression list data model
Where it liveslayer
OperationalOPERATIONAL
How Ekas settles itdetectability
Human checkHUMAN
Only someone holding the document or making the call can settle it. Ekas tells you exactly what to look at.
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
FCC
When it appliesapplicabilityText
Applies to every 10DLC registration.
In forceeffectiveFrom / effectiveTo
From 2027-01-31

Why this rule existsrationale

The rule is scheduled rather than hypothetical, and the work it implies is architectural: a brand whose consent and suppression are modelled per programme cannot become category-wide with a configuration change. Naming it now is what makes it a planned migration rather than a discovery made in the month it applies.

How to fix itremediation

Check now whether one revocation can suppress every category a sender operates, and if it cannot, schedule the change against the January 2027 date. Done when a single revocation demonstrably clears every programme the brand runs.

Check this yourselfattestation

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

Is suppression on your platform keyed per sender or per programme — and if per programme, is the migration scheduled against 31 January 2027?

  1. 1Answer the one architectural question: can a single revocation clear every category this sender operates?
  2. 2If it cannot, schedule the change now. A per-programme consent model does not become category-wide with a configuration change.

What wrong looks like: The rule is scheduled rather than hypothetical, and it is discovered in the month it applies — when the work it implies is architectural rather than a setting.

Notesnotes

A future obligation about a system we cannot inspect, carried at LOW until it takes effect and BLOCKING after. What the user has to do is answer one question about their own platform — is suppression keyed per sender or per programme — and start the migration if the answer is the second.

Rules you will hit next

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

OPS-096A state may black out whole daysLowLOWOPS-116Carrier approval is not legal coverLowLOWOPS-131A validity period shorter than the queue drops messages silentlyLowLOWOPS-146Identical bodies across a bulk send fingerprint the campaignLowLOWOPS-208The consent record should carry the browser user agentLowLOW

All operational rules

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

Reading the rules is the easy part.

Ekas runs every rule that gates approval, 823 of these 915, against your registration before it reaches the carrier. It reads your site, your policy pages and your opt-in the way a reviewer would, and hands you the fix, not just the verdict.

Talk to UsHow 10DLC works