One recognisable number per programme

JSONMarkdown

The requirementstatement

A business or programme should send from one primary, recognisable source number.

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
programme to source number mapping
Where it liveslayer
OperationalOPERATIONAL
How Ekas settles itdetectability
External recordEXTERNAL_DATA
The fact that settles it lives in a register we cannot query, such as the IRS file, a postal database, or another provider’s tenant. Reported as a warning with the evidence to check, not as a pass.
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
T-Mobile
When it appliesapplicabilityText
Applies to every 10DLC registration.

Why this rule existsrationale

Recognition is the consumer's only defence against smishing: somebody who knows the number their pharmacy texts from can tell a fake from a real one. A programme that sends from a rotating set trains its own customers to accept messages from unfamiliar numbers, which is precisely the habit the industry is trying to break.

How to fix itremediation

Send each programme from one number and publish it, so customers can recognise and save it. Done when a customer could tell you which number your texts come from.

Check this yourselfattestation

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

Could a customer tell you which number your texts come from?

  1. 1Send each programme from one primary number and publish it so customers can recognise and save it.
  2. 2Reconcile this against any pool you operate: a pool is legitimate for capacity and still argues for one primary number per programme rather than a rotating presentation.

What wrong looks like: A programme sending from a rotating set trains its own customers to accept messages from unfamiliar numbers — precisely the habit that makes smishing work.

Notesnotes

Sending configuration. What the user has to reconcile is this against any pool they operate — a pool is legitimate for capacity and still argues for one primary number per programme rather than a rotating presentation.

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-outMediumMEDIUMOPS-042Somebody has to own revocations that arrive in conversationMediumMEDIUMOPS-050The opt-out confirmation is worth sending inside five minutesMediumMEDIUMOPS-051Only ask which messages to stop when there is more than one kindMediumMEDIUMOPS-057Log the sends you did not makeMediumMEDIUMOPS-062An opted-out consumer must be able to come backMediumMEDIUM

All operational rules

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

Reading the rules is the easy part.

Ekas runs every rule that gates approval, 823 of these 915, against your registration before it reaches the carrier. It reads your site, your policy pages and your opt-in the way a reviewer would, and hands you the fix, not just the verdict.

Talk to UsHow 10DLC works