Which SMS gateways support compliant alphanumeric sender IDs by country
No SMS gateway uniquely “supports” compliant alphanumeric sender IDs by country: compliance is a property of each market’s registration regime, not of the provider. Any gateway can submit an alphanumeric Originating Address where the destination allows it; none can bypass pre-registration or in-transit replacement. Select providers by which markets they already pre-register in, how they handle unregistered IDs, and whether they will show an in-market handset test—not by a country-support badge.
Compliance is a market regime, not a gateway feature
The title question assumes sender-ID compliance is something a gateway product either has or lacks for a given country. That framing is wrong. Alphanumeric sender IDs (the GSM 03.40 Originating Address encoded as an alphanumeric string rather than an E.164 number, which is limited to 15 digits) are accepted, rewritten, or rejected according to rules enforced by destination networks and, where they exist, national registration schemes. A gateway is a submit path. It can present the OA you ask for; it cannot create a legal or commercial right to use that OA on a foreign network.
Where a market permits unregistered alphanumeric OAs on the routes you actually use, every competent SMPP or HTTP SMS API can send them. Where a market requires the sender string to appear in an operator or consortium registry before delivery, no gateway can “support compliance” for an ID that was never filed on that path—the message is filtered, failed, or delivered under a substituted address. Where networks strip or replace alphanumeric OAs in transit, the gateway’s submit log and the handset display will disagree no matter which brand you paid.
So the useful question is not “which gateways support country X?” It is “what regime does country X impose, has this provider pre-registered my brand on the routes it will use, and what happens to traffic that is not registered?” Those are operational facts you can demand in writing and then verify on a real device.
SMSRoute's country fact sheets record each market's sender-ID regime with a named basis and a retrieval date.
Four regime classes worth documenting
In practice, destination behaviour clusters into a small number of regime classes. Documenting the class—and the basis and retrieval date for that classification—is more honest than a binary “supported / not supported” matrix next to a vendor logo.
Pre-registration required. The alphanumeric string must be filed with a central registry, a lead operator, or each MNO before it is allowed to pass as the displayed sender. Unregistered traffic is rejected or rewritten. Provider differentiation here is real: it is about who maintains registrations, under which entity name, on which downstream routes, and how long provisioning takes. It is not about a special protocol flag.
Allowed without a central registry. Networks accept alphanumeric OAs without a national filing step, subject to normal anti-spoofing, content, and commercial-route controls. “Allowed” still does not mean “every route preserves the string.” Grey routes and some wholesale interconnects rewrite OAs even when the domestic regime is permissive. Preservation remains a path property.
Carrier-specific practice. There is no single national rule you can cite; each MNO (or each wholesale path into that MNO) applies its own accept/replace/reject policy. Your gateway’s answer for “Spain” or “India” is incomplete until it names the operators on the intended route and the policy observed on those operators.
Replaced in transit. Regardless of what you submit, the handset shows a numeric short code, a long code, or a generic network label. Marketing pages that list the country as “alphanumeric supported” are describing submit-side syntax, not display-side reality. For product UX and for brand trust, display-side reality is the only metric that matters.
These classes overlap at the edges. A market can require pre-registration on branded traffic while still replacing unregistered strings rather than failing them. Treat the class as a prior, then measure the path.
| Regime class | What it means for alphanumeric OAs | What to verify with a provider |
|---|---|---|
| Pre-registration required | Unregistered IDs are rejected or rewritten on compliant routes | Which entity is registered, on which MNOs/routes, provisioning lead time |
| Allowed without central registry | No national filing step; path quality still varies | Whether their routes preserve OA or substitute numerics |
| Carrier-specific practice | Accept/replace/reject differs by MNO and wholesale path | Named operators on the route and observed policy per operator |
| Replaced in transit | Handset display will not match the submitted alphanumeric string | What the handset actually shows; do not rely on submit ACKs |
Spain as a concrete example
Spain is a useful worked example because it is easy to over-claim and because our dataset carries it explicitly as a typed regime row rather than a marketing tick. In that row, Spain is classified under pre-registration required for alphanumeric sender use on commercial terminating routes. The named basis is operator-level sender-ID registration practice on routes into Spanish networks—not a gateway feature bit—and the row carries a retrieval date so the classification can age out and be re-checked instead of freezing into folklore.
Practical consequence: if your brand string is not provisioned on the downstream path your gateway will use, you should expect failure, substitution to a numeric or short-code identity, or inconsistent display across MNOs. A provider that says “we support alphanumeric in Spain” without saying whether your specific string is registered on their Spanish routes is answering a different question—the question of whether their API accepts the field—not the question of whether Spanish handsets will show your brand.
Nothing in that Spain row licenses broader EU generalisations. Neighbouring markets differ in registry structure, in whether substitution is preferred to reject, and in how strictly upstream providers enforce filings. Spain illustrates the method: regime class, named basis, retrieval date, then path-level proof. It is not a template you copy onto every country code.
The same dataset shape is applied across a full 40-market table: each market carries regime class, basis, and retrieval date, plus notes where carrier-specific practice or in-transit replacement dominates. Use that table as a prior for route design and for procurement questions. Do not treat it as a substitute for a handset check on the live path you will productionise. Regimes change; retrieval dates exist so you know when a row is stale.
The SMSRoute sender-ID rules tool exposes the same sourced dataset interactively.
The SMSRoute country fact sheets record each sender-ID regime with a named basis and a retrieval date — that dataset is what this page summarizes.
What to verify: handset display, not submit promises
Sender-ID preservation is testable. It is not a contractual vibe. The only observation that answers “will my users see BRANDNAME?” is the string rendered on a real handset, on a real MSISDN in the destination market, served by the MNO population you care about, on the same gateway route class you intend to buy.
Method, stripped of theatre: submit a unique alphanumeric OA (and a control message from a known numeric) through the candidate route; receive on in-market SIMs across the major operators; photograph or read back the displayed sender; compare to what you submitted and to what the gateway DLR or delivery webhook claims. Repeat after any registration change. If you need latency context for the same probes, record p50 and p95 of submit-to-handset time yourself—those figures vary by path and load; published composites will not match your route.
Read the logs you do control carefully. A success DLR means the downstream accepted the message under whatever OA identity that hop uses after transformation. It does not prove the handset UI showed your string. Conversely, a reject at submit may be your only clean signal that an unregistered ID was blocked before substitution. Build your acceptance tests around display equality, not around gateway acceptance alone.
Segment length rules are orthogonal but easy to confuse with sender compliance. GSM 7-bit single-part bodies top out at 160 characters (153 per part when concatenated); UCS-2 single-part bodies at 70 (67 per part when concatenated). Those are encoding limits. They do not tell you whether the OA was preserved. Keep the two checklists separate.
Never outsource the handset observation to a claim that cannot be reproduced on your numbers. If a provider will not participate in a simple in-market display test for the markets they list, treat their country matrix as syntax documentation only.
What to ask a provider before you integrate
Procurement questions should map to regime classes and to proof, not to slogan features. Ask which markets they actively pre-register alphanumeric IDs in, under which legal entity the registration sits, and how they onboard a new brand string—including lead time and which MNOs or aggregators are covered. “We support Europe” is not an answer.
Ask what happens to unregistered IDs on each critical route: hard fail, silent substitution to a shared numeric, substitution to a tenant-specific long code, or best-effort pass-through. Ask whether that behaviour is consistent across the operators inside the country or only on a subset of paths. Ask them to show a recent in-market handset result for a registered ID and for an intentionally unregistered control on the same route class you will use.
Ask how they notify you when a registry or operator policy changes—because your production sender can break without any change on your side. Ask whether traffic for a given country code always rides the registered path or can spill to an unregistered wholesale path under congestion. Spill routes are a common reason handset display drifts from the brand you tested in week one.
Finally, align on responsibility boundaries. You own trademark rights to the brand string and the content compliance of the body. They own honest description of the routes they will actually use and the registrations they have actually filed. No gateway should be asked to promise outcomes a destination network can unilaterally change; you should ask them to promise transparency about path, registration scope, and test evidence.
If you build against that checklist—regime priors from the 40-market table, Spain-style attention to basis and retrieval date, handset verification, and written answers on pre-registration scope—you will know which gateways can carry your alphanumeric identity compliantly in the markets you care about. You will not need a leaderboard of who “supports” a country.
Frequently asked
- Which SMS gateways support compliant alphanumeric sender IDs in Spain?
- None uniquely do. Spain is documented as pre-registration required on commercial terminating routes; any gateway can submit an alphanumeric OA, but only paths where your string is actually registered will display it consistently. Pick a provider by whether they pre-register your brand on their Spanish routes and by an in-market handset test—not by a country-support badge.
- Can I use my brand name as the SMS sender ID in every country?
- No. Markets fall into different regimes: pre-registration required, allowed without a central registry, carrier-specific practice, or alphanumeric replaced in transit. Where registration is required or replacement is normal, submitting your brand does not mean handsets will show it. Check the regime for each destination and verify display on real in-market devices.
- How do I verify that an alphanumeric sender ID is preserved?
- Send through the candidate route to real handsets on major in-market MNOs and compare the displayed sender to the string you submitted. Treat gateway success DLRs as insufficient: they do not prove UI preservation. Repeat after registration changes, and ask the provider what they do with unregistered IDs on that same path.
SMSRoute publishes its rates outright (US $0.0125 all-in, from $0.004, 149 countries), so compliance questions never hide a pricing surprise.