Most technical teams assume sending an SMS internationally works roughly the same as sending one locally. It doesn't. Understanding how global SMS delivery actually works — the carrier agreements, the intermediaries, the registration requirements — is what lets you diagnose why a message arrives in seconds in one market and silently disappears in another. This guide walks through the transmission path, the routing categories, what a delivery receipt actually tells you, and how to measure delivery honestly instead of trusting the DLR at face value.
The transmission path: application to handset
When your application sends an SMS via API, the message does not travel in a straight line to the recipient's phone. The typical path is:
- Application — your platform submits the message to a gateway or API.
- Gateway / supplier (aggregator) — the gateway routes the message to a supplier that holds interconnect agreements for the destination market.
- Carrier or hub — the supplier hands the message to the destination carrier directly, or via an intermediary hub that itself has carrier agreements.
- Destination SMSC — the operator's Short Message Service Center (SMSC) is the store-and-forward node that queues the message and attempts delivery to the handset, retrying within a validity window if the device is unreachable.
- Handset — the message is delivered to the device and, separately, may or may not be rendered and read.
For domestic traffic this chain can be a single hop between two carriers. For cross-border traffic it usually involves at least one intermediary supplier, because no single aggregator holds direct interconnect agreements with every carrier in every country. Each additional hop is a place where a message can be delayed, filtered, or dropped, which is why understanding the full path — rather than treating "send" as a black box — matters operationally.
Message-level factors that affect how this plays out:
- Sender ID — the alphanumeric or numeric identifier shown to the recipient; format and registration requirements vary by country and carrier.
- Message encoding — GSM-7 supports 160 characters per segment; Unicode (UCS-2), required for non-Latin scripts and some emoji, drops that to 70 characters per segment, which increases segment count and cost.
- Validity period — how long the SMSC will keep retrying before marking the message expired. This is configurable and varies by supplier and market rather than following one fixed industry-wide window.
- DLR (delivery receipt) — a status callback intended to confirm what happened to the message somewhere along that chain.
What a DLR actually tells you — and what it doesn't
A DLR is a report from the network, not a report from the handset. A "delivered" status generally means the destination SMSC accepted the message for delivery to the device — it does not reliably mean the handset rendered it, and it says nothing about whether the recipient read it.
Three specific failure modes to design around:
- Silent failure — some routes, particularly lower-quality ones, drop messages without ever returning an error status. If you only alert on explicit failure codes, you will miss this category entirely.
- Synthetic or fabricated DLRs — some suppliers, particularly on lower-quality or grey routes, return a "delivered" status regardless of what actually happened downstream, because there's commercial incentive to report success. A DLR from an untrusted route is not evidence of delivery.
- Network acceptance vs. handset outcome — even a genuine "delivered" status from the terminating network is a statement about network handoff, not about what the user saw or did.
The practical conclusion is that DLRs are a useful operational signal for detecting route-level degradation (a route that suddenly returns far more failures than usual is worth investigating), but they are not a substitute for measuring outcomes at the application layer — did the user click the link, enter the OTP, or complete the flow the message was meant to trigger. Build your health dashboards around that conversion signal per route, not around DLR percentage alone.
Sender registration
A growing number of markets require sender identities to be registered before traffic is allowed through: alphanumeric sender ID pre-registration with national regulators or carriers in some countries, India's DLT platform requiring entity, sender ID, and template registration before sending, Nigeria's NCC rules on sender ID and unsolicited messaging, and similar frameworks elsewhere. Unregistered or misconfigured sender IDs are typically filtered or blocked at the carrier level — often silently, which is another reason DLR-only monitoring misses real problems. Registration timelines and requirements differ by market and by supplier relationship, so treat this as something to plan per market rather than assume follows a single global process.
Mobile number portability and why routing by number range fails
Historically, a phone number's prefix indicated which carrier it belonged to, and some routing logic still assumes this. Number portability — the ability to keep your number when switching carriers — broke that assumption in most markets years ago. Routing decisions based on number-range lookups without a current portability check will misroute a meaningful share of traffic to the wrong carrier, which shows up as delivery failures or degraded DLR accuracy that has nothing to do with route quality. Reliable routing requires querying current portability/HLR data rather than relying on a static number-range table.
Route categories: direct, transit, and grey
Not all paths between your platform and a destination carrier carry the same risk.
Direct routes are bilateral interconnect agreements, either carrier-to-carrier or between a carrier and a licensed aggregator with its own agreement. These generally offer the most reliable delivery and the most trustworthy DLRs, because the reporting comes from a party with a direct contractual relationship to the terminating network.
Transit routes go through one or more intermediary suppliers who hold their own interconnects with regional carriers. This is how most international SMS actually moves — no single provider has direct agreements everywhere — and a well-run transit route through a licensed, accountable supplier can be entirely reliable.
Grey routes (SIM-box / SIM-farm bypass) are a commercial and technical bypass of the normal interconnect. Traffic is injected into the destination network in a way designed to look like ordinary person-to-person traffic — often via banks of SIM cards in "SIM boxes" physically located in the destination country — instead of being carried under a proper A2P commercial agreement. This is cheaper for whoever is selling the route, because it avoids the interconnect and termination fees a legitimate A2P agreement requires. The tradeoffs are real: sender identity is unreliable (the recipient may see a local mobile number instead of your brand's sender ID), delivery is inconsistent, DLRs from this path should not be trusted, and terminating networks actively look for and block or filter this kind of traffic, which is why grey-route volumes can degrade or stop working with no warning.
It's worth being precise about a separate issue that sometimes gets conflated with grey routes: SS7 signalling vulnerabilities. SS7 is the signalling protocol carriers use to route calls and messages and manage subscriber location between networks. Known weaknesses in SS7 allow certain kinds of interception, location tracking, or message rerouting by parties who gain access to the signalling network — this is a network security issue affecting the interconnect infrastructure itself. It is not the same thing as SIM-box bypass, and it is not a cost-saving routing mechanism — nobody sends A2P campaign traffic over SS7 exploits as a business model. Conflating "cheap grey-market SMS route" with "SS7 vulnerability" misdescribes both: one is a bypass of commercial routing, the other is a signalling-security concern for the industry generally.
Content filtering and retry behaviour
Carriers filter content at the network level for a range of reasons: spam heuristics, restricted categories in some markets (financial promotions, gambling references, political messaging), and enforcement of sender ID registration status. A message can be silently filtered post-submission even if the initial DLR looked normal, and retry logic varies by carrier and by supplier — some retry aggressively within the validity window, others do not retry at all after an initial soft failure. None of this is visible from the DLR alone, which reinforces the same conclusion as above: use application-layer conversion signals as your source of truth, and treat DLRs as a diagnostic aid for route health, not a delivery guarantee.
Measuring what actually matters
A workable approach at scale:
- Segment traffic by category. OTP and other transactional traffic need the fastest, most reliable routes; marketing traffic has different compliance and timing constraints. Mixing them on shared route configuration is a common source of degradation for the more time-sensitive traffic.
- Monitor DLR patterns for route-level anomalies, with alerting on sudden shifts — but pair this with conversion data rather than relying on DLR percentage in isolation.
- Use multi-vendor routing for critical traffic. Distributing OTP and transactional messages across more than one licensed supplier limits exposure to a single vendor's outage or filtering issue, and a channel fallback (WhatsApp, RCS, voice) can recover a flow when SMS delivery in a specific market is degraded.
- Track cost per completed action, not cost per message sent. A route with a lower headline price that fails a meaningful share of OTP deliveries is more expensive once you count the support load and lost conversions.
- Have a tested escalation process with each supplier before you need it — who you contact, how fast, and what triggers a route switch.
Where Flowstates fits
Operating this reliably across multiple markets, suppliers, and traffic categories is a full-time discipline, separate from understanding how it works. Flowstates runs the messaging gateway layer — multi-vendor routing, delivery monitoring, sender registration tracking, and category-aware failover — on top of capacity we sell directly, on routes and vendor contracts you already hold, or a mix of both, so your team isn't stuck choosing between rebuilding vendor relationships and having no operational visibility.