Check the number is a live mobile before paying to send to it

The requirementstatement

Destination numbers should be validated as real, active mobile numbers before sending, since platforms bill accepted requests regardless of delivery.

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: destination number validation
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: AWS
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

Billing happens on acceptance, not delivery, so a list full of landlines, disconnected numbers and typos costs money on every send and returns nothing. It is also a quality signal the carriers read: a high proportion of invalid destinations is one of the shapes that distinguishes a purchased list from an organic one, so the waste and the reputational damage arrive together.

How to fix itremediation

Run a lookup against the list before a large send and drop landlines, invalid formats and disconnected numbers. Done when the invalid rate on a send is measured rather than assumed.

A compliant exampleexample

Pre-send lookup: 40,000 numbers → 38,900 mobile, 700 landline, 400 invalid → send to 38,900.

Check this yourselfattestation

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

Is the invalid rate on your sends measured, rather than assumed?

1Run a lookup against the list before a large send and drop landlines, invalid formats and disconnected numbers.
2Weigh the per-number lookup cost against the per-message cost of sending to numbers that cannot receive — for a list built from typed-in phone fields it usually pays for itself on the first send.

What wrong looks like: Billing happens on acceptance, not delivery, so the waste is invisible in the delivery metrics. A high proportion of invalid destinations is also one of the shapes that distinguishes a purchased list from an organic one.

Notesnotes

A paid per-number lookup at the provider. What the user has to weigh is the lookup cost against the per-message cost of sending to numbers that cannot receive — for a list built from typed-in phone fields the lookup usually pays for itself on the first send.

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-057Log the sends you did not makeMediumMEDIUM OPS-062An opted-out consumer must be able to come backMediumMEDIUM

All operational rules

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