TL;DR: SMS Sender ID is the name or number recipients see as the message sender. In many markets, what you configure and what arrives are two different things — the US blocks alphanumeric Sender IDs on A2P routes entirely, India requires DLT registration, and carriers on any route type can substitute or strip it without warning. TelQ verifies what actually arrives on the handset.
Your platform's sent record shows exactly the Sender ID you configured. The message status says Delivered. But on the recipient's handset in Chicago, Mumbai, or São Paulo, something different appears: a random long code, a truncated string, or no Sender ID at all. Nothing in your logs flagged it.
That gap between what your platform reported and what the recipient actually saw is the core Sender ID problem. It exists in every market to some degree, and in a few markets it's entirely by design.
What is a Sender ID in SMS?
A Sender ID is the identifier that appears in the "From" field when a recipient receives an SMS. For most A2P (application-to-person) messaging, it's the element that tells a recipient a message came from their bank, delivery service, or OTP provider, before they've read a word of the body.
There are three main types:
| Type | Format | Typical length | Where it's used |
|---|---|---|---|
| Alphanumeric | Letters, numbers, or a combination | Up to 11 characters | Europe, Australia, and most markets outside North America |
| Shortcode | Short numeric string | 5–6 digits | US, Canada, and select other markets for high-volume A2P |
| Long code (MSISDN) | Standard phone number format | 10–15 digits | Global, including markets where alphanumeric isn't supported |
How a Sender ID travels to the recipient
When you send an A2P message, the Sender ID passes from your platform to your SMS supplier, through any intermediate carriers, to the destination network's SMSC (Short Message Service Centre), and finally to the recipient's device. Each handoff is a point where the Sender ID can be inspected, modified, or replaced, depending on what the carrier at that point is configured to do.
Most of the time, it arrives as sent. The problem is that "most of the time" is not the same as "always," and in several major markets it's never.
Why Sender ID behaves differently by market
Sender ID behavior is determined by regulation, carrier policy, and route configuration. The same Sender ID that displays correctly in one market can fail silently in another — and the reason matters, because the fix is different depending on which type of restriction you're dealing with.
There are three distinct mechanisms:
| Restriction type | How it works | Examples | What to expect |
|---|---|---|---|
| Alphanumeric ban | Network operators don't deliver A2P messages with alphanumeric Sender IDs | US, Canada | Numeric sender (10DLC or shortcode) regardless of configuration |
| Mandatory pre-registration | Alphanumeric is supported but must be registered before delivery | India (TRAI DLT), Singapore (SSIR) | Unregistered Sender IDs filtered by operators |
| Carrier-level filtering | Route-specific policy, not formal regulation | Any market | Substitution or stripping on specific routes — only detectable by testing |
Alphanumeric bans
Some markets simply don't deliver A2P messages with alphanumeric Sender IDs. The US is the largest example: whatever you configure, recipients receive the message from a 10-digit long code (10DLC) or a shortcode. Carriers enforce this at the network level, and the substitution happens regardless of which supplier you use. Canada operates similarly in practice.
This is the most predictable restriction type. The behavior is consistent and expected — the task is to configure a numeric sender correctly from the start, then test to confirm the right one arrives.
Mandatory pre-registration schemes
A growing number of markets support alphanumeric Sender IDs but require them to be registered with a regulatory body or carrier scheme before delivery. India's TRAI DLT platform is the largest example: every alphanumeric Sender ID must be registered before Indian operators will deliver it. Singapore's SSIR (SMS Sender ID Registry), launched in 2023, works the same way.
A Sender ID that delivers correctly in Europe won't automatically work in these markets, even on the same supplier route. Registration is a prerequisite, and the registered Sender ID must match exactly what your platform is sending.
The list of markets with pre-registration schemes is growing. Checking current registration requirements for each destination is part of the operational baseline for any route you send into.
Carrier-level filtering
The hardest restriction to predict. Individual carriers apply their own filtering rules on specific routes, independent of any formal regulation. A carrier may replace alphanumeric Sender IDs with the originating MSISDN for certain interconnect agreements. A route intermediary may add a Sender ID header that overrides yours before the message reaches the destination network.
This can happen in any market — including markets where alphanumeric Sender IDs are formally supported. It generates no error in your delivery reports. Testing the full route end-to-end — sending through your actual supplier chain and checking what arrives on a real SIM — is the only way to see what a recipient actually receives, regardless of where along the route the modification happened.
What can go wrong: Sender ID failure modes
When a Sender ID doesn't arrive as configured, the failure takes one of three forms:
| Failure mode | What the recipient sees | Typical cause |
|---|---|---|
| Substitution | A different number or name — often the originating long code | Carrier policy or route intermediary override |
| Stripping | No Sender ID displayed | Network filtering removes the field entirely |
| Modification | Sender ID truncated or altered | Character encoding issues or carrier character limits |
Substitution is the most common and commercially significant. A recipient who sees a random +1 number instead of "BankAlert" may treat the message as spam. A routing engineer whose customer is paying for branded Sender ID delivery may not know the substitution is happening unless they test on that specific route to that specific network.
Stripping tends to happen on routes where the carrier rejects alphanumeric Sender IDs but doesn't perform substitution: the message delivers, the body arrives intact, but there's no sender information. Harder to catch because the delivery report still shows success.
Modification (truncation specifically) often traces to character encoding mismatches between systems. "Support24" becomes "Suppo" when a handoff strips characters above a certain byte limit.
None of these failure modes are limited to grey-route traffic. They occur on premium and direct A2P routes when carrier filtering is the cause.
How to verify what your recipients actually see
Your SMS platform reports what it sent. Your supplier's SMSC reports what it received. Neither is the same as what the recipient's handset displayed.
Delivery reports don't capture Sender ID modification — the same way that fake delivery reports can report success on messages that never arrived at all. Real-handset testing is the only way to close the gap.
You send a message through your supplier's route with your intended Sender ID configured, to a test number in the destination market. A real SIM on a physical device receives it. The test platform records exactly what arrived: the Sender ID as displayed, the message content, the SMSC identity, and the delivery latency.
TelQ runs this across 180+ countries and 1,500+ networks, using physical handsets with real SIM cards. When a Sender ID is substituted or stripped in transit, the test result documents it — even when your supplier's delivery report shows success. Since 2016, TelQ's platform has processed 100M+ SMS delivery tests across all types using this real-handset approach.
Connor C., a TelQ customer: "The TelQ platform allows us to easily identify which SMS have been successfully delivered, whether we have received a false DLR, and if there are any changes to the sender id or content of the SMS."
For routing engineers, the test result identifies which SMSC handled the message at the destination and what the handset received. For enterprise messaging teams, it answers why a brand name displays correctly in some markets but not others, with the specific network identified.
One note on test methodology: results reflect the specific route and network at the time of the test. The SMS whitelisting guide covers cases where test conditions may differ from production traffic, and how to account for that when interpreting results.
If you're testing a new supplier route or seeing inconsistent Sender ID behavior across markets, TelQ runs verification through real SIMs on the destination network. Test your Sender ID with TelQ.
Common questions about SMS Sender ID
What is a Sender ID in SMS?
A Sender ID is the alphanumeric name or number displayed as the sender when a recipient receives an SMS. Three types exist: alphanumeric (up to 11 characters, typically a brand name or identifier), shortcode (5–6 digit numeric string), and long code (standard phone number format). Which type the recipient actually sees depends on the destination market, the carrier, and the route — not only on what you configured in your platform.
Why does my Sender ID show differently in some countries?
Markets regulate and implement Sender ID differently. The US doesn't support alphanumeric Sender IDs on A2P routes — all messages arrive with a shortcode or long code regardless of what was configured. India requires DLT registration for any alphanumeric Sender ID before delivery will succeed. Beyond regulated markets, individual carriers apply their own filtering rules on specific routes regardless of local regulation, which can substitute or strip Sender IDs on legitimate A2P traffic.
What is Sender ID modification?
Sender ID modification is when a carrier or route intermediary replaces your configured Sender ID before delivery. The recipient sees a different name or number from what you sent. The three forms: substitution (your brand name replaced by a long code), stripping (no Sender ID displayed at all), and truncation (Sender ID cut to fewer characters). Modification happens on legitimate A2P routes, not only on grey-route traffic — carrier filtering is the cause in many cases.
How do I test whether my Sender ID is delivering correctly?
Send a test message through your supplier route to a TelQ test handset in the destination market, with your intended Sender ID configured. TelQ's real SIM card receives the message and records what arrived — including the Sender ID as displayed on the handset — and compares it against what you sent. Discrepancies are documented in the test result, including SMSC identity. For context on how Sender ID testing fits within a broader SMS delivery testing workflow, see the SMS Testing Guide.
Does Sender ID work the same way for OTP messages as for marketing messages?
Sender ID support and carrier filtering apply regardless of message type. The complication is that OTP and marketing messages often travel on different routes from the same supplier — which means a Sender ID that delivers correctly on the marketing route may behave differently on the OTP route. Run Sender ID verification separately for each route in production. A substitution on an OTP route tends to cause more immediate damage than on a marketing route, because recipients may not recognize an unexpected number as a legitimate source.
