Every Indian engineering team eventually hits the same bug: OTPs work in testing, work for some users, and vanish for others, while the SMS provider's dashboard reports successful delivery. The cause is almost always DLT. Under TRAI's TCCCPR 2018 regulation, telecom operators maintain a distributed ledger registry of who is allowed to send commercial messages, under what sender name, and with exactly what text. Outbound SMS is scrubbed against that registry in real time, and anything that does not match a registered template is blocked.
Registration has three parts and they must happen in order. First the principal entity registers on any operator's DLT portal — the registry is shared, so one registration covers all operators. It requires company PAN, GST certificate, business email, authorised signatory details and letterhead, costs in the region of six thousand rupees including GST as a one-off, and takes one to three working days. The output is a Principal Entity ID. Second, you register a six-character sender header. Third, you register each message template.
The header type is the first place products go wrong. Transactional or service headers are alphabetic and reach numbers registered on the Do Not Disturb list. Promotional headers are numeric and are filtered out for those users. Sending a login OTP from a promotional header means that every DND-registered customer — a very large share of Indian mobile users — simply never receives it. The message is not delayed; it is discarded, and nothing in your logs says so.
Templates are the second and more insidious problem. You register the exact message body with variables marked as placeholders, and operators match the static text character by character. A developer who tidies the wording, changes a full stop, adds an emoji or adjusts spacing has created a message that no longer matches, and it will be silently dropped. This is the single largest cause of the mystery in the opening paragraph. Every variant needs registering separately, and URLs and phone numbers in the body usually have to be pre-declared rather than inserted dynamically.
The other recurring failure is registering under the wrong legal name. The entity name must match PAN and GST exactly, and a company that registers under its trading brand rather than its registered name gets rejected or, worse, approved into a state that causes problems later. Teams also treat registration as a one-time setup task and then add new message types months afterwards without registering them, reproducing the original bug in a new place.
The practical defences are simple and worth building once. Keep the registered template text in version control next to the code that sends it, so any edit is visible in review. Alert on delivery-rate drops per template rather than in aggregate, because aggregate rates hide a single broken message type. Allow three to seven working days end to end for a new message to become sendable, and plan launches around that rather than discovering it on the day.
