Do not spread one message across many numbers

The requirementstatement

Similar or identical content must not be distributed across many sending numbers to dilute per-number reputation or evade filtering.

Severityseverity: BlockingBLOCKINGBreaking this rule gets the submission rejected. There is no partial credit.
When it bitesphase: After you are livepostFalls due once you are sending: STOP handling, quiet hours, suppression, record retention.
What is checkedobject: outbound traffic distribution across numbers
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: Hard stopHARD_STOP; Not remediable. Resubmitting will not help, and anyone offering to fix it is selling you a rejection.
Who requires itauthorities: T-MobileAT&TCTIATwilioTelnyxAWSVonageSinchPlivo
When it appliesapplicabilityText: Applies to every 10DLC registration.

Why this rule existsrationale

Filtering is scored per originator, so splitting a send across ten numbers gives each one a tenth of the complaint rate and a tenth of the volume — which is the entire mechanism, and the carriers named it before anybody built a product around it. The innocent version is indistinguishable from the outside: a brand whose sends were slow buys more numbers to go faster, and is now doing exactly what the rule prohibits. It carries a four-figure pass-through fee rather than a rejection, so the first signal is an invoice.

How to fix itremediation

Route similar content through one registered originator, or request an approved number pool for the campaign so the distribution is declared rather than discovered. Where throughput is the real constraint, raise it through vetting rather than through number count.

Common mistakespitfalls

Needing more throughput is a legitimate problem with a legitimate answer — a registered number pool, or a higher-tier brand vet — and neither of them is more numbers quietly added to a campaign.

Check this yourselfattestation

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

How many numbers does this campaign actually send from, and was a pool ever approved for it?

1Count the originators on the campaign, then ask your provider whether an approved number pool is on record.
2Where throughput is the real constraint, raise it through vetting rather than through number count.
3Route similar content through one registered originator otherwise.

What wrong looks like: A brand whose sends were slow buys more numbers to go faster and is now doing exactly what the rule prohibits. It carries a four-figure pass-through fee rather than a rejection, so the first signal is an invoice.

Notesnotes

Absorbs MSG-138, the same prohibition from the message-content side. A traffic shape we cannot observe. What the user has to check is how many numbers their campaign actually sends from and whether a pool was ever approved for it — OPS-POOL-DECLARED covers the registration-side declaration, and OPS-136 catches the duplicate-campaign version of the same pattern before submission.

Rules you will hit next

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

OPS-026The universal opt-out keyword set must be declaredBlockingBLOCKING OPS-027Opt-out keyword handling must be declared, not assumedBlockingBLOCKING OPS-029A revocation must survive punctuation, case and surrounding wordsBlockingBLOCKING OPS-031A plainly-worded opt-out counts even with no keyword in itBlockingBLOCKING OPS-033STOP must never come back as an errorBlockingBLOCKING OPS-037On a shared address, STOP must stop everythingBlockingBLOCKING

All operational rules

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