Watch the opt-out rate, and act at both thresholds

The requirementstatement

The per-campaign opt-out rate must be monitored, audited above roughly 0.5% on a send, and the campaign suspended with a root-cause analysis above 4% in 24 hours.

Severityseverity: BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: per-campaign opt-out rate
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: T-MobileTCR
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

The opt-out rate is the earliest honest signal that a list is not what it was thought to be, and it moves before complaints do. The two thresholds mean different things: the lower one says audit where these numbers came from, the higher one says stop, because a rate that high is usually a purchased list or a consent scope nobody checked, and carriers act on it whether or not you do.

How to fix itremediation

Report the opt-out rate per send and per rolling day, alarm at 0.5% and 4%, and write down what each alarm triggers — a consent audit at the lower, an immediate pause and root-cause analysis at the higher. Done when the numbers have owners rather than dashboards.

A compliant exampleexample

Send of 40,000 → 260 opt-outs (0.65%) → consent audit on the segment before the next send.

Check this yourselfattestation

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

Who is paged when the opt-out rate hits 4% in 24 hours, and do they have the authority to stop a send?

1Report the rate per send and per rolling day, and alarm at 0.5% and 4%.
2Write down what each alarm triggers: a consent audit at the lower, an immediate pause and root-cause analysis at the higher.
3Name the person now — the window in which acting helps is hours.

What wrong looks like: A rate that high is usually a purchased list or a consent scope nobody checked, and carriers act on it whether or not you do. Dashboards without owners are how the hours pass.

Notesnotes

Absorbs OPS-067, the higher threshold on the same monitor. Needs live traffic. What the user has to do is decide now who is paged at 4% and what authority they have to stop a send, because the window in which acting helps is hours.

Rules you will hit next

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

OPS-026The universal opt-out keyword set must be declaredBlockingBLOCKING OPS-027Opt-out keyword handling must be declared, not assumedBlockingBLOCKING OPS-029A revocation must survive punctuation, case and surrounding wordsBlockingBLOCKING OPS-031A plainly-worded opt-out counts even with no keyword in itBlockingBLOCKING OPS-033STOP must never come back as an errorBlockingBLOCKING OPS-037On a shared address, STOP must stop everythingBlockingBLOCKING

All operational rules

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