An accepted SMS request is not proof that your customer received a code. If you build or run a website, online store or business app in India, start an OTP investigation with the message ID and final delivery report, not with the resend button.
The cause might be your registered template, a missing sender mapping, provider routing, an operator problem or the receiving phone. The symptoms look similar to the customer. Changing vendors before you know which stage failed can leave the same broken template behind a different API.
This guide is for the business operating the login flow. It explains the DLT checks on domestic commercial SMS, what to ask your provider, and how to avoid locking people out when delivery fails.
What actually happens to an OTP between your server and the phone?
On domestic commercial SMS routes, TRAI's framework requires registration through operators' Distributed Ledger Technology (DLT) platforms. The business sending messages is the Principal Entity. The registration covers:
- The entity itself, with its business documents.
- Headers, the approved sender identifiers used for your messages.
- Content templates, the exact wording of every message you intend to send, with the variable parts marked.
When your SMS provider hands a message to an operator, it is "scrubbed": the operator checks the header, the template ID and the content against what you registered. If it does not match, it is not delivered. TRAI's own explanation of the early failures lists the reasons plainly — templates not registered, content IDs missing, and a mismatch between the registered template and the message actually sent.
That historical finding is a useful checklist, not evidence that every missing OTP today is a template failure. Confirm the route too: Twilio's India guidance, for example, distinguishes domestic DLT-registered delivery from international gateways. These are different products, not interchangeable workarounds.
Which DLT changes should you check in an older integration?
An integration can keep the same application code while the surrounding requirements change. Check these four areas against your actual operator registration:
Links. TRAI's September 2024 notice announced blocking of SMS containing unwhitelisted URLs, APKs or OTT links from 1 October 2024. A support link added to an OTP needs the relevant approval too.
The delivery chain. The government confirmed rejection of traffic through unregistered paths from 11 December 2024. Check the Principal Entity–Telemarketer chain with your provider, including routing partners.
Message category. The February 2025 amendment announcement introduced category identifiers in headers. Do not assume that every login OTP belongs in the same category; have your provider confirm the approved use case.
Variable pre-tagging. TRAI's January 2026 newsletter describes its 18 November 2025 direction mandating pre-tagging of variable fields in commercial SMS templates. Review existing templates as well as new ones. Confirm the currently enforced tags, validation rules and error handling with the registering operator rather than copying an old template tutorial.
Which template mistakes stop OTPs being delivered?
Use the failed message and its report to work through this checklist. The rows are possible causes, not a ranking of failure rates:
| Mistake | What it looks like | Fix |
|---|---|---|
| Fixed text drifted from the registered template | Someone "tidied up" the wording in code; delivery fell off a cliff on deploy | Treat template text as a registered artefact. Change it on DLT first, then in code |
| Variable used where the template has fixed text | Brand name or validity minutes injected as a variable but registered as fixed | Register the template with the variable where the code actually varies |
| Variable value fails its approved rules | The code or other value does not fit the registered tag or bounds | Check the current operator rules and the actual submitted value |
| Unwhitelisted link in the message | A support URL or tracking link added to the OTP body | Remove links from OTPs, or whitelist them on the DLT portal |
| Wrong template ID passed to the provider | Two similar templates; the code sends one ID with the other's text | Keep a single mapping of template ID to text, in one place |
| Undeclared delivery chain | Some operators deliver, others do not; varies by day | Ask your provider for its full chain and declare it |
| Template registered under the wrong category | Message delivered with the wrong suffix, or treated as promotional | Re-register under the correct category |
Exotel's template-scrubbing guidance specifically calls out missing entity/template parameters, text mismatches and incorrect header mappings. Check your provider's equivalent diagnostics.
First, the application and the registration must stay in sync. A plausible failure is a developer changing "Your OTP is" to "Your one-time password is" in a pull request, with no idea that sentence is registered with an operator. Put the template text in a constant with a comment explaining it is registered on DLT, and require that any change to it goes through whoever owns the DLT account.
Second, connect the initial request to subsequent delivery events. Twilio documents separate accepted, queued, sent, delivered and undelivered states. An API success and a later delivery failure can both be correct. Store the message ID, timestamps and final status; protect phone-number data and keep the actual OTP out of ordinary logs.
Ask whether a reported validation issue is a warning or a blocking rejection on your route. Do not infer the current enforcement mode from an old announcement or treat every provider's numeric error codes as equivalent.
How should the OTP message itself be written?
Short, with no link, and in a format the phone can read for the user.
Browsers can fill a one-time code into your form automatically, which removes the step where people mistype a digit or switch apps and lose the page. Two mechanisms matter:
- The
autocomplete="one-time-code"attribute on the input. Google's SMS OTP form guidance recommendstype="text",inputmode="numeric"andautocomplete="one-time-code", and notes that Safari on iOS 14 and later will suggest the code from an incoming SMS. - Origin-bound codes and the WebOTP API. If the last line of the SMS reads
@yourdomain.com #123456, Chrome on Android can read the code through the WebOTP API, over HTTPS, with user permission on supported setups. Domain binding helps the browser offer the code to the intended site, but does not make manually entered SMS codes phishing-resistant. Always retain manual entry when automatic retrieval is unavailable.
The catch in India is that this last line is part of the message text, so it has to be part of the registered template. Register it with the domain as fixed text and the code as the variable. Teams often add the line in code after the template was approved, which turns a convenience feature into a delivery failure.
An illustrative message to discuss with your provider, not a pre-approved DLT template:
123456 is your OTP to sign in to Example. It expires in 10 minutes. Do not share it with anyone.
@example.com #123456
Both changing code occurrences need appropriate registered variable fields. Confirm that the origin line, formatting and any required domain whitelisting are accepted. Only promise a ten-minute expiry if the server actually enforces it.
How do you design a login that survives a failed SMS?
Assume some messages will fail. Operators have outages, numbers are ported, phones are in poor coverage, and DLT validation requirements can change. The design question is what happens next.
Do not let users hammer "Resend". Repeated sends increase cost and abuse exposure. Use a visible countdown before resend is allowed, and cap attempts per number per hour. This also protects you from SMS pumping, where attackers trigger large volumes of OTPs to numbers they profit from.
Offer a safe fallback. A previously verified email address, an enrolled passkey or another approved channel can help when SMS fails. Do not let someone take over an existing account by entering a new email address after requesting an OTP. New-user phone verification and recovery of an established account are different problems. WhatsApp or voice also needs provider support, appropriate message configuration and its own abuse controls; see our WhatsApp automation guide for that separate channel.
Choose expiry deliberately. NIST's out-of-band authentication guidance requires completion within ten minutes, one-time acceptance and limits on unsuccessful guesses. That is a security reference, not an instruction to use the longest possible window. Choose a lifetime appropriate to the operation and measured delivery delays. Enforce expiry and attempt limits on the server, not only in the countdown shown to the user.
Rate-limit by number and by IP. Enforce limits on the server to constrain brute-force attempts and SMS pumping. Use your verification provider's controls or atomic shared quotas across application instances. A counter in one server's memory cannot enforce a global limit across replicas. Count sends and verification attempts separately.
Measure it. Track, per day, OTPs requested, delivered according to the provider's delivery reports, and successfully verified. If verified divided by requested drops, something broke. Separate rejection, delivery and verification rates, with comparable time windows. A delivery receipt is not proof that the right person saw the message; a completed verification is a distinct event.
When should you stop using SMS for login?
For some products, SMS OTP is the wrong primary method, and no amount of template hygiene changes that.
Returning users on your own app or site. Appropriately managed sessions and passkeys can reduce repeated SMS challenges. Set session expiry, revocation and step-up checks for sensitive operations; do not turn fewer OTPs into indefinite access.
International users. Registration, routing and prices vary by destination and provider. Compare actual coverage and verification completion before choosing a fallback; neither email nor WhatsApp is universally cheaper or more reliable. Confirm what your chosen service supports in each market.
Internal tools. Prefer an appropriately secured identity provider and phishing-resistant authentication for privileged staff access. NIST treats telephone-network out-of-band authentication as restricted and notes that it is not phishing-resistant. Making SMS arrive reliably does not remove SIM-swap and code-relay risks.
SMS can still be useful when a product needs to check access to a mobile number during account creation or checkout. Be clear about what that proves: control of a channel at that moment, not a person's real-world identity or a permanent guarantee of account ownership.
What not to do
- Do not build your own SMS gateway integration with every operator. Choose a provider that supports your required route and explains which registration, chain and delivery-report tasks each party owns. Your engineering effort belongs in the application, not in telecom plumbing.
- Do not put marketing in the OTP message. It changes the category the template belongs to, and it is the fastest way to have it rejected or delivered with the wrong label.
- Do not let your SMS vendor own your DLT account. The entity registration, headers and templates should be under your company's login. Retain control of the entity, headers and templates. Switching providers may still require new chain bindings and mappings.
- Do not treat "accepted" as "delivered". It only means your provider received the request. Check the later delivery report and the separate verification result.
- Do not assume this is a one-time setup. Operator requirements and validation checks can change. Somebody needs to own this, and they need to read the operator notices.
The short version
If OTPs are going missing, check in this order: does the fixed message text match the registered version; do changing values appear only in their approved variable fields; is there a link that is not whitelisted; is the delivery chain declared; and are you reading delivery reports at all. If those checks pass, investigate provider routing, operator status and device-side conditions rather than repeatedly changing the message.
Login is usually one small part of a larger system. When we build web applications or online stores, the verification flow, rate limiting and fallback channels are designed in from the start rather than discovered at launch.
If your OTPs are failing and you cannot see why, tell us what you are seeing. A template correction and an authentication redesign are very different jobs; the delivery evidence should tell you which one you need.
Bharat Vasireddy
Founder & Digital Marketing Strategist8+ years of experience in performance marketing and web development. I help businesses scale through data-driven SEO, Google Ads, and high-performance websites.