# OPS-153 — The sender must be who the message says it is

> The message number and sender name must not be spoofed or substituted in any way that misleads a consumer.

- **Rule ID:** OPS-153
- **Layer:** Operational (`OPERATIONAL`)
- **Checks:** `outbound sender identity`
- **Severity:** BLOCKING — Breaking this rule gets the submission rejected outright.
- **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:** Hard stop — not remediable, resubmission will not help
- **Required by:** CTIA, all MNOs
- **Applies:** Applies to every 10DLC registration.
- **Canonical URL:** https://ekas.io/rules/10dlc/operational/ops-153/

## Why this rule exists

Sender identity is the only thing a recipient has to judge a message by, and misrepresenting it is the mechanic behind every smishing campaign — which is why the prohibition is absolute rather than proportionate. Legitimate substitution exists, for failover or for a shared brand, and it requires an arrangement with the provider rather than a configuration change.

## How to fix it

Send from the numbers registered to the campaign, presented as themselves. Where a substitution is genuinely needed, arrange it with the provider in advance rather than configuring it.

## Check this yourself

**Does any part of your stack rewrite the originating number or sender name?**

1. Ask your provider and check any aggregation layer between your application and the carrier — some rewrite the originator for routing reasons.
2. Confirm messages arrive from the numbers registered to the campaign, presented as themselves.
3. Where a substitution is genuinely needed, arrange it with the provider in advance rather than configuring it.

*What wrong looks like:* A routing layer substitutes the originator without anybody choosing it. Sender identity is the only thing a recipient can judge a message by, and the sender is accountable for the result either way.

## Notes

Wire-level behaviour. What the user has to confirm is that no part of their stack rewrites the originator — some aggregation layers do it for routing reasons, and the sender is accountable for the result either way.