# OPS-065 — A carrier opt-out is authoritative even if your list has no record

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

- **Rule ID:** OPS-065
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `delivery error stream into the suppression list`
- **Severity:** HIGH — Rejected by at least one carrier or provider, and a common cause of failure at the rest.
- **When it bites:** Falls due after approval, once you are live and sending
- **How it is detected:** Not knowable before submission — reported with its deadline
- **Fix type:** Wait on an external system or a required interval
- **Required by:** Bandwidth, all MNOs
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-065/

## Why this rule exists

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 it

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.

## Example of a compliant value

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

## Check this yourself

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

1. Ask whether the platform surfaces opt-out-class errors distinctly from other delivery failures.
2. Trace where they go. The common answer is a failure metric nobody reads.
3. Done 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.

## Notes

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.