What Is SMS? Protocol, OTP Mechanics & Virtual Numbers 2026
Need quick verification codes? Start your verification journey now
Quick read
SMS is the 1985 GSM standard for 160-character cellular messages. In 2026 it's still the dominant OTP delivery channel because no other channel has universal reach without app or data dependency. This guide unpacks the protocol, the OTP delivery chain, the three reasons OTPs fail, and where virtual SMS numbers fit (and don't).
SMS at the Protocol Level
What SMS Actually Is
- Defined: 1985, GSM standard (later extended to UMTS/LTE/5G)
- Payload: 160 characters in GSM-7 encoding (140 bytes), or 70 characters in Unicode (UCS-2)
- Transport: Cellular signaling channels (SS7 / SIGTRAN / Diameter on 4G/5G) — does NOT use data
- Concatenation: Messages > 160 chars are split into multi-part SMS (each part is a separate billable unit)
The signaling-channel design is why SMS works without internet, without an app, and on any phone going back 40 years. It's also why SMS is slow (signaling channels are low-priority for non-voice traffic) and expensive at scale (each message hops through the originating carrier → SMS gateway → terminating carrier).
SMS vs RCS vs iMessage vs WhatsApp
| Channel | Year | Transport | Encryption | Recipient requirement |
|---|---|---|---|---|
| SMS | 1985 | Cellular signaling | None (clear-text over SS7) | Any phone, any carrier |
| iMessage | 2011 | Internet (TLS + iCloud) | E2E | iOS device with Apple ID |
| 2009 | Internet (Signal protocol) | E2E | Phone number + WhatsApp app | |
| RCS | 2008 (standard); 2019 (deployed) | Internet | E2E (RCS Universal Profile) | Carrier + device support |
For OTP delivery in 2026, SMS remains dominant for one reason: it's the only channel that works on every phone regardless of OS, network state, or app installation. Banks, governments, and authentication systems use SMS because failure to deliver an OTP locks users out — and only SMS guarantees reach.
The OTP Delivery Chain
When you trigger an OTP, this happens:
1. App backend → SMS gateway (Twilio / MessageBird / Sinch / ACS / homegrown)
2. SMS gateway → carrier SMSC (Short Message Service Center)
3. SMSC → terminating carrier (via SS7 / SIGTRAN)
4. Terminating carrier → recipient handset (via cellular signaling)
5. Handset receives → user enters codeFailures can happen at any hop:
| Hop | Common failure | What you see |
|---|---|---|
| 1 → 2 | A2P 10DLC unregistered (US) | Backend logs say "delivered" but message never sent |
| 2 → 3 | Sending number reputation flagged | Silent drop, no error to sender |
| 3 → 4 | Receiving carrier rejects message class | Often blocked at HLR lookup |
| 4 → 5 | Recipient phone offline / out of coverage | Queued, may arrive late |
| 5 | OTP expired before user enters | "Code expired" error |
The hop most users blame ("my carrier is bad") is rarely the actual cause. The hop most commonly responsible is 2 → 3, where the sending gateway's reputation and the receiving carrier's filters intersect.
Why OTPs Fail — Three Real Causes
Cause 1: HLR / Carrier-type Filter
HLR (Home Location Register) is the carrier database that tells the SMS network whether a number is:
- Mobile (cellular SIM) — accepted by most services
- Fixed-line — usually rejected for SMS OTP
- Fixed-VoIP (Google Voice, Twilio retail, TextNow) — rejected by Google, banks, Meta apps
- Premium-rate — rejected outright
Services run an HLR lookup before sending. If the carrier type is "fixed-VoIP", they often refuse to send. The sender's backend says "OTP sent"; in reality, no SMS was generated.
This is the single biggest cause of "Google Voice doesn't work for X" complaints.
Cause 2: A2P Traffic Filtering
A2P (Application-to-Person) messages are messages from a business to a user (like OTPs). Carriers and regulators have tightened A2P filtering since 2022:
- US: A2P 10DLC registration (mandatory since 2023). Unregistered A2P traffic is silently dropped.
- UK: Ofcom Originator-Based Filtering rolled out 2024.
- India: TRAI DLT registry (sender ID + content template pre-approved).
- Brazil: Anatel similar regime.
If the sending service didn't register its A2P traffic properly, OTPs are dropped. The user has zero visibility into this.
Cause 3: Country / Risk Mismatch
The receiving service may run its own risk engine that checks:
- Phone country vs IP country alignment
- Phone country vs declared user country
- Phone carrier (premium MNO vs marginal MVNO)
- Number recency on its own platform (recently used → cooldown)
When the risk engine fails, the OTP never gets requested from the gateway. The button just shows "verifying…" indefinitely. Same UX as a delivery failure but the root cause is upstream.
Q1 2026 Country OTP Pass-Rate Matrix
Measured across ~3,500 OTPs through SMS-Act inventory, March–April 2026, across 12 major services:
| Country | Pass rate | Strong carriers | Notes |
|---|---|---|---|
| United States (+1) | 88% | T-Mobile, Verizon, AT&T | Best general fallback |
| United Kingdom (+44) | 86% | EE, Vodafone | English-language services prefer +44 |
| India (+91) | 87% | Airtel, Jio, Vi | Tightest A2P, but high pass on registered traffic |
| Germany (+49) | 84% | Telekom, O2 | EU GDPR-bound services prefer +49 |
| Indonesia (+62) | 84% | Telkomsel | Highest in SEA |
| Japan (+81) | 76% | NTT Docomo, SoftBank | Tighter HLR, smaller MVNO pool |
| Brazil (+55) | 76% | Vivo > Claro > TIM | Anatel regime strict |
| France (+33) | 81% | Orange | Reliable for EU services |
| Spain (+34) | 79% | Movistar, Vodafone | |
| Australia (+61) | 80% | Telstra | Good for APAC services |
| Russia (+7) | 78% | MTS, Beeline | Strong for VK / Yandex |
| South Korea (+82) | 73% | SKT, KT | Tighter; real-name regime |
Virtual SMS Numbers — What They Are
A virtual SMS number in the SMS-Act sense is a real cellular number from a real carrier, rented to you for a 20-minute OTP window. Three structural facts:
- Carrier-type: mobile — passes HLR lookup as mobile
- Number isolation — one number → one OTP request → that number is then quarantined from re-use on the same service for a cooldown period
- Per-OTP billing — 8 credits per successfully received OTP, auto-refunded on failure
This is structurally different from:
- VoIP services (Google Voice, Twilio retail) — fixed-VoIP carrier type, fails HLR
- Public SMS receivers (free random-number websites) — shared inbox, exposed in real time, services blacklist these number ranges
- Roaming on your real SIM — works but exposes your real number
When Virtual Numbers Work / Don't
Work
- Social media (Instagram, TikTok, Threads, Snapchat)
- Marketplaces (eBay, Mercari, Vinted, Poshmark, Lazada, Shopee, Grab)
- Gaming (Steam, EA, Blizzard, Epic, Tarkov, MMOs)
- Productivity SaaS (Zoho, Microsoft consumer, Google personal, Slack)
- Streaming / content (YouTube, Twitch, Patreon)
- Dating (Tinder, Hinge, OkCupid)
Don't
- Banks (Chase, Bank of America, HSBC, neobanks like Revolut, N26, Wise — downstream KYC)
- Investment brokers (Schwab, IBKR, Robinhood — SEC/FINRA identity)
- Government services (DMV, IRS, equivalent in other countries)
- Healthcare portals (HIPAA-protected accounts)
- Google Voice (FCC E911 + STIR-SHAKEN bars virtual carriers)
- Crypto exchanges with regulated jurisdictions (Coinbase, Kraken — full KYC)
The pattern: regulated services do real identity verification beyond the phone gate. The phone is the first gate; the second gate (ID + address + tax ID + biometric) is unforgivable to virtual numbers.
How OTP Codes Are Actually Generated
Two common server-side patterns:
Pattern 1: Random 6-Digit Code (Most Common)
code = random_int(100000, 999999)
hash = hash(code + secret_salt)
store(user_id, hash, expiry=now+10min)
send_sms(phone, "Your code is " + code)Server stores only the hash. On user submission, server hashes the input and compares.
Pattern 2: TOTP (Time-based One-Time Password)
shared_secret = generate_secret()
code = HMAC-SHA1(shared_secret, current_30s_window)[:6]This is what authenticator apps (Google Authenticator, Authy) use. SMS-based OTPs almost always use Pattern 1 because SMS is delivery-uncertain — you can't sync a 30-second window if delivery takes 90 seconds.
Migrating from SMS-Activate
SMS-Activate announced shutdown 2025-12-29. Users migrating to other services find the SMS verification flow nearly identical — same OTP format, same country preferences, same 10-minute typical window. Structural differences when comparing platforms:
| Dimension | SMS-Act | SMS-Activate (shut down) |
|---|---|---|
| Refund | Per-OTP auto-refund to balance | Manual request, $30 minimum withdrawal |
| Payment | Alipay / WeChat / Stripe | Crypto-first |
| Inventory freshness | Real-time pass-rate data per service | Static lists |
Hero-SMS is the announced SMS-Activate successor for migrating users. SMS-Act has operated independently since 2023 and is not part of the SMS-Activate → Hero-SMS path.
FAQ
Q1: Can I use the same virtual number twice on the same service?
Once a number receives an OTP for service X, that number-to-service binding is recorded by both SMS-Act (to prevent double-billing) and service X (to prevent abuse). The number cannot be re-rented to receive a second OTP from X within the cooldown period.
Q2: What happens if the OTP arrives after the 20-minute window expires?
The number is released back to the pool. The OTP message is not visible to the next renter (SMS-Act enforces inbox-isolation per rental). If you missed the window, you'll need to buy a fresh number.
Q3: Why does my real phone sometimes not receive OTPs either?
Same three causes — A2P filtering by your carrier, HLR-type misreport (if your line is a VoLTE-only VoIP line), or service-side risk control. Real phones can fail too; they just usually fail less.
Q4: Can I receive SMS from short codes (5-digit numbers) on virtual numbers?
Depends on the inventory. Long-code (full E.164 number) SMS works universally. Short-code SMS (e.g., 22000 in the US) is harder because short codes are leased per-country and many SMS receiving services don't route them. Check service availability before buying.
Q5: Is SMS encrypted in transit?
No. SMS over GSM/3G/4G uses clear-text SS7 signaling. SMS over 5G is somewhat better (Diameter protocol) but still not end-to-end encrypted. This is why high-security services prefer authenticator apps over SMS-OTP — but SMS retains its universal-reach advantage.
Related Reading
- Virtual SMS Guide: Secure Online Verification — virtual numbers deep-dive
- How to Receive Foreign Verification Code — country selection strategy
- Free vs Paid SMS Verification Platforms — platform tradeoffs
- SMS Verification Platform 2026 — selection criteria
- Receive SMS Online Guide — hub for the use case
Disclaimer
This platform is designed to support development testing, business verification, and international service scenarios, helping users complete processes in a reasonable and compliant manner.
Users are expected to ensure that their use of the service complies with applicable laws, regulations, and the policies of third-party platforms. The platform does not participate in or control how the service is used.
Accounts associated with abnormal or improper usage may be subject to restrictions in accordance with platform policies.
Users must be at least 18 years old and acknowledge that they are fully responsible for their own use and any resulting outcomes. If you do not agree with these terms, please discontinue use of the service.
Try SMS-Act for OTP verification — 160+ countries, 600+ services, 8 credits per OTP with auto-refund on failure.