DLT Registration

The mandatory process of registering your business, sender IDs and message templates on a telecom operator's DLT portal before you can send commercial SMS in India.

DLT stands for Distributed Ledger Technology. In the Indian telecom context it refers to the blockchain-based registration system that operators run under TRAI's Telecom Commercial Communications Customer Preference Regulations (TCCCPR), 2018. Any business that wants to send commercial SMS to Indian numbers has to be registered on it first.

Registration has three distinct layers, and all three matter:

  • Entity registration. Your legal business identity, verified with documents such as PAN, GST or incorporation certificate. You do this once, on any one operator's DLT portal — the record then propagates to the others.
  • Header (sender ID) registration. The six-character alphabetic code that appears as the sender, for example PRFOXI. Headers are tied to a category — transactional, service, or promotional — and you cannot use a promotional header to send transactional traffic or vice versa.
  • Template registration. The exact message body, with variable fields marked as placeholders. Content that does not match a registered template is rejected at the operator, not at your provider.

Once registered, every message you submit is checked in real time against those records before delivery — a step the industry calls scrubbing. If the header is unregistered, the template does not match, or the consumer has set a preference that blocks your category, the operator drops the message. Your SMS provider will usually report this back as a template or header mismatch rather than a delivery failure, which is why unregistered campaigns often look like they "sent" but never arrived.

The practical consequence for marketers is that DLT work has to happen before a campaign is built, not after. Template approval is not instant, and every creative variation you want to send is a separate template. Campaigns designed around freeform copy tend to get rebuilt once the DLT constraints become clear.

Worked example

A clinic wants to send appointment reminders. They register the header CLINIC under the transactional category, and a template reading:

Dear {#var#}, your appointment with Dr {#var#} is confirmed for {#var#}. - CLINIC

At send time the provider fills the three variables. Because the fixed text matches the registered template character-for-character, scrubbing passes and the message delivers even to numbers on the DND registry — transactional traffic is exempt from consumer preference blocks in a way promotional traffic is not.

Common mistakes

  • Editing template copy after approval. Even a changed full stop breaks the match and the message is dropped.
  • Sending promotional content on a transactional header to reach DND numbers. Operators detect this and it puts the header at risk.
  • Treating variables as unlimited. Placeholders are for short dynamic values such as names and dates, not for swapping in whole sentences.
  • Leaving DLT to the end of a campaign build, then discovering the creative cannot be registered in the form it was written.

Need this handled properly? See how we run it →

Related terms