Sending stops on receipt, including on a political programme

The requirementstatement

No message may be sent to a number after a valid opt-out is received, whatever the campaign type.

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: send-time suppression check
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: Hard stopHARD_STOP; Not remediable. Resubmitting will not help, and anyone offering to fix it is selling you a rejection.
Who requires itauthorities: FCCCTIAT-Mobile
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

This is the obligation every other opt-out rule exists to make achievable, and the way it is breached is almost never a decision: a send was already queued, a scheduled blast was built from a list exported yesterday, or the suppression check happens at list-build time rather than at send time. Political programmes get their own line in the carrier rules because operators assume the exemptions that cover consent also cover revocation. They do not.

How to fix itremediation

Check the suppression list at send time, not at list-build time, and re-check anything that has been queued for more than a few minutes. Purge suppressed numbers from scheduled sends when the schedule fires rather than when it is created.

Common mistakespitfalls

A CSV exported for a blast is a snapshot of consent at export time; every opt-out between export and send is invisible to it unless the platform re-checks.

Check this yourselfattestation

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

Where in your send pipeline does the suppression check run — at list-build time, or at send time?

1Trace one scheduled send from list construction to dispatch and find the check. Build time is the common answer and it is the wrong one.
2Confirm anything queued for more than a few minutes is re-checked before it goes.
3Political programmes are not exempt: the exemptions that cover consent do not cover revocation.

What wrong looks like: A blast built from yesterday's export goes out this morning to someone who opted out overnight. Nobody decided to send it, and the recipient cannot tell the difference.

Notesnotes

Absorbs OPS-069 and MSG-268, which restate it for political programmes where the carriers call it out specifically. Undecidable before traffic. What the user has to verify is where in their send pipeline the suppression check sits — build time is the common answer and it is the wrong one.

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-045 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.