A carrier opt-out is authoritative even if your list has no record

The requirementstatement

A delivery rejection indicating the carrier holds an opt-out for the number must be treated as a suppression event in its own right.

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: delivery error stream into the suppression list
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: Bandwidthall MNOs
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

Carriers maintain their own opt-out state, and a consumer who texted STOP to a shared originator or used a handset-level block can be opted out there while your list shows them active. Retrying that number burns delivery reputation and, more importantly, means you are trying to message somebody who has revoked — your own list not knowing about it is not a defence.

How to fix itremediation

Write back to the suppression list on every opt-out-class delivery error rather than counting it as a failed send. Done when a carrier-held opt-out appears in your own suppression list within a day of the first rejection.

A compliant exampleexample

Delivery error 21610 (opted out) → suppress the number locally, channel=carrier, and stop retrying.

Check this yourselfattestation

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

Does anything in your systems consume opt-out-class delivery errors and write them to the suppression list?

1Ask whether the platform surfaces opt-out-class errors distinctly from other delivery failures.
2Trace where they go. The common answer is a failure metric nobody reads.
3Done when a carrier-held opt-out appears in your own list within a day of the first rejection.

What wrong looks like: A consumer opted out at the carrier or blocked the number on the handset, your list shows them active, and you retry — messaging somebody who has revoked. Your list not knowing is not a defence.

Notesnotes

Reaches you as a delivery code after launch. What the user has to establish is whether their platform surfaces opt-out-class errors distinctly, and whether anything consumes them — the common answer is that they land in a failure metric nobody reads.

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-044Suppression is brand-wide, not per numberHighHIGH 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

All operational rules

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