Log the sends you did not make

The requirementstatement

Every send attempt suppressed because the number was opted out must be logged.

Severityseverity: MediumMEDIUMUsually survives review, but lowers your trust score or invites a manual look you would rather avoid.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: suppressed-send log
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: Supply evidenceTERMINAL_EVIDENCE; Needs proof only you hold: a screenshot, a recording, a scan of the form people signed.
Who requires itauthorities: T-Mobile
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

The suppression list proves what you intended; the suppressed-send log proves it worked. Without it there is no evidence that the check ran at all — an empty complaint file and a suppression list with a million entries are consistent with a suppression check that has been silently failing since a deploy, and an audit asks for exactly this.

How to fix itremediation

Log the number, the campaign and the timestamp each time a send is dropped for suppression, and retain it for the same period as the consent records. Done when you can show how many sends the list stopped last month.

A compliant exampleexample

suppressed_send: msisdn +14155550134, campaign acme-marketing, at 2026-03-04T14:22Z, reason=opted_out.

Check this yourselfattestation

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

Can you say how many sends your suppression list stopped last month?

1Check whether your platform exposes suppression events at all — several drop them silently, and where that is true the evidence has to come from a pre-send check you run yourself.
2Log the number, the campaign and the timestamp on every dropped send.
3Retain it for the same period as the consent records.

What wrong looks like: An empty complaint file and a suppression list with a million entries are equally consistent with a check that has been silently failing since a deploy. Without the log there is no evidence it ever ran.

Notesnotes

A log inside the sending platform. What the user has to check is whether their platform exposes suppression events at all — several drop them silently, and where that is true the evidence has to come from a pre-send check they run themselves.

Rules you will hit next

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

OPS-032A help request containing a stop-word is not an opt-outMediumMEDIUM OPS-042Somebody has to own revocations that arrive in conversationMediumMEDIUM OPS-050The opt-out confirmation is worth sending inside five minutesMediumMEDIUM OPS-051Only ask which messages to stop when there is more than one kindMediumMEDIUM OPS-062An opted-out consumer must be able to come backMediumMEDIUM OPS-063Opt-out records must not be shared onwardMediumMEDIUM

All operational rules

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