A plainly-worded opt-out counts even with no keyword in it

The requirementstatement

Revocations phrased in ordinary language — "take me off your list", "please opt me out" — must be honoured even though they contain no declared keyword.

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: inbound message intent classification
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: FCCCTIAT-MobileAT&TBandwidth
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

The federal rule is that a revocation is effective if a reasonable person would understand it as one, not if it matches a word list. So a consumer who writes "I never signed up for this, please remove me" has revoked, and a keyword-only handler files the message as an ordinary reply and keeps sending. It is the most common route to a complaint that the brand genuinely did not see coming, because the operator can point at a suppression list that never received anything.

How to fix itremediation

Route every inbound message that did not match a keyword through an intent check — a classifier, or a human queue if the volume is small — and suppress on anything a reasonable person would read as "stop". Done when a message with no keyword in it can still remove somebody from the list without an agent deciding to be helpful.

A compliant exampleexample

Inbound "hi, I never signed up for these, can you take me off?" → no keyword match → intent = revocation → suppressed, and the raw text kept on the opt-out record.

Check this yourselfattestation

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

Who or what reads the inbound messages that matched no keyword, and how quickly?

1Name the classifier or the human queue. An unread inbox is the same as no handler.
2Test it: send "take me off your list" with no keyword in it and confirm the number is suppressed without an agent deciding to be helpful.

What wrong looks like: "I never signed up for this, please remove me" is filed as an ordinary reply. The operator can point at a suppression list that never received anything, and the complaint is the first anyone hears of it.

Notesnotes

Undecidable before traffic exists and not settleable by configuration alone. What the user has to establish is who or what reads the non-keyword inbound messages, and how fast — an unread inbox is the same as no handler. OPS-056 covers keeping the raw text, which is what later shows the message was understood.

Rules you will hit next

One other rule reads inbound message intent classification. Fixing one field to satisfy a single rule is how a resubmission trades one rejection for another, so read these before you change anything.

OPS-032A help request containing a stop-word is not an opt-outMediumMEDIUM 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-033STOP must never come back as an errorBlockingBLOCKING OPS-037On a shared address, STOP must stop everythingBlockingBLOCKING

All operational rules

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