Every commercial SMS sent in India has to clear three separate registrations before it reaches a phone: the sender’s Principal Entity ID, the header (sender ID) it’s sent from, and the exact content template being used. Here’s what each one actually is, how they fit together, and why cutting corners on any of them is riskier now than it used to be.
Table of Contents
- The Short Answer
- TL;DR
- Why This System Exists
- Principal Entity: Registering Who You Are
- Header: Registering What You Send From
- Content Template: Registering What You Say
- The PE-TM Chain
- The 2024 Traceability Mandate Raised the Stakes
- Why Borrowing Someone Else’s Registration Is a Bad Bet Now
- DLT Registration vs. NCPR/DND Scrubbing
- A Pre-Launch Checklist
- Next Steps
- FAQs
The Short Answer
If you’re sending commercial SMS to Indian numbers, you need three separate registrations in place before a single message goes out, not one. First, your business registers as a Principal Entity on a telecom operator’s DLT platform. Then you register a header, the actual sender ID people see, under that entity. Then you register the exact wording of the message itself as a content template, tied to that specific header. Miss any one of the three and the message either never sends or gets blocked somewhere in the pipeline.
That’s always been true since TRAI’s 2018 regulations set the system up. What’s changed is the cost of getting it wrong. Since December 2024, telecom operators also check that the whole chain, from your Principal Entity down through whoever’s actually transmitting the message, is consistent and pre-defined. If it isn’t, the message gets rejected outright rather than just flagged.
TL;DR
- Three registrations, not one: Principal Entity (your business), header (your sender ID), content template (your exact message wording). Each sits under the one before it.
- Headers fall into three categories under TRAI’s rules, promotional, transactional, and service, and each comes with different consent requirements.
- A content template has to match its header’s category and, as of the 2024 rules, can only be linked to one header at a time.
- Messages get checked against two separate systems before delivery: the consent/preference registry (NCPR/DND) and the DLT registration chain. They catch different problems.
- Since December 11, 2024, a message where the sender chain doesn’t match what’s registered gets rejected outright, not just flagged for review.
- Using someone else’s registered Principal Entity to skip your own registration carries real risk under the current enforcement model, not just a theoretical one.
- Registration itself happens on the telecom operator’s own DLT portal (Jio, Vodafone Idea, Airtel, Tata, BSNL each run one), not inside a messaging platform’s own panel.
Why This System Exists
India’s Telecom Commercial Communications Customer Preference Regulations, TCCCPR, went into effect in 2018 for one reason: spam. Before DLT, pretty much anyone could buy a bulk SMS connection, pick a six-character sender ID, and start blasting promotional messages with no real way for a telecom operator, let alone a recipient, to trace who was actually behind it.
The fix TRAI landed on was a distributed ledger shared across telecom operators, where every sender has to register who they are, what sender ID they’re using, and exactly what they’re going to say, before any of it touches a phone. Each access provider runs its own version of this ledger and the registrations tend to carry across operators once you’ve done them with one, so a business doesn’t have to repeat the whole process for every network it sends through. The regulation’s own language calls for “verification of identities” before anyone’s allowed to send, and that verification happens in three layers.
Principal Entity: Registering Who You Are
A Principal Entity, usually just called a PE, is the registration of the business itself, not a product, not a campaign, the legal entity sending the messages. This is a one-time setup done with business documents (things like GST registration, company incorporation papers, PAN), and it’s the foundation everything else sits on. No PE registration, no header, no template, nothing else is possible.
This is also where a lot of confusion starts, because the PE registration happens with a telecom operator’s DLT platform rather than with a messaging vendor. A platform like SMPPCenter sits on top of this system, checking messages against it and handling the sending infrastructure, but the registration itself is between the business and the telecom operator (or operators) whose network carries the message.
In practice, most businesses only go through this once. Register as a PE with one telecom operator’s DLT platform, and that registration tends to carry weight with the others too, so a company sending traffic across Jio, Airtel, Vodafone Idea, and BSNL networks isn’t filling out four separate entity applications from scratch. What does need repeating per operator, at least in effect, is the chain-binding step covered further down, since each operator still needs to see which telemarketer or aggregator is authorized to send on the PE’s behalf through its network.
Header: Registering What You Send From
Once a Principal Entity exists, it can register headers under its name. A header is what shows up as the sender ID, the alphanumeric string a recipient sees instead of a phone number.
TRAI’s regulations sort every header into one of three categories, and the category determines how the message can be used:
| Category | What it’s for | Consent needed | Example |
|---|---|---|---|
| Promotional | Marketing and offers | None required, but subject to NCPR/DND preference restrictions and only reaches opted-in categories | Sale announcements, discount codes |
| Transactional | Triggered directly by a transaction, sent within 30 minutes | Bypasses general consent requirements because it’s tied to an active transaction | OTPs, order confirmations, payment receipts |
| Service | Account information, warranty, delivery updates | Relaxed consent, built on an existing customer relationship | Delivery status, service reminders, renewal notices |
A header registered as Transactional can’t suddenly be used to send a promotional blast, and vice versa. The category is locked in at registration and every template under that header has to match it.
A business can register as many headers as it actually needs, a separate one for OTPs, another for order updates, another for marketing, and each one has to be distinct enough that it can’t be mistaken for somebody else’s registered brand name. That last part is also part of what the 2024 enforcement tightened up: a header that looks close enough to an already-registered brand to cause confusion is exactly the kind of thing the traceability push was meant to stop.
Content Template: Registering What You Say
The last piece is the message text itself. Before you can send anything, the exact wording, with variable placeholders marked out for things like names or order numbers, has to be submitted and approved as a content template.
Templates are registered against a specific header and have to match that header’s category. A system check compares the outgoing message against its approved template before sending, and anything that doesn’t match, extra text, a different structure, a swapped-out variable, gets stopped rather than delivered. As of the 2024 rules, a single template also can’t be shared across multiple headers anymore; each header needs its own registered version of a message, even if the wording is identical.
Anything in a template that points somewhere else, a URL, an APK link, an OTT app link, or a callback number, has to be separately whitelisted by the sender since September 2024. An unwhitelisted link in an otherwise-approved template is enough to get the message rejected.
The PE-TM Chain: Linking Your Entity to Whoever Actually Sends
Registering a Principal Entity and a header doesn’t automatically account for the fact that most businesses don’t transmit their own SMS traffic. A platform, an aggregator, a CPaaS vendor, somebody in between is usually doing the actual sending, and that relationship has to be registered too, as a PE-TM chain (Principal Entity to Telemarketer).
The process, as Zoho documents it for businesses setting up SMS through its own platform, works roughly like this: the PE logs into its DLT operator’s portal, creates a chain naming the specific telemarketer entity that will be sending on its behalf, and gets back a chain ID in a pending state. That chain typically needs approval from both sides, the PE and the telemarketer, and a second backup chain is usually created the same way in case the first fails over. Zoho’s own guidance put the approval turnaround at up to two weeks, though that’s going to vary by DLT operator and isn’t something to treat as fixed across the board.
This is the piece that turns three separate registrations into one traceable chain, and it’s exactly what TRAI started actively enforcing in December 2024.
The 2024 Traceability Mandate Raised the Stakes
The three-layer system above has been in place since 2018, but TRAI added something new in 2024: a requirement that the entire chain, Principal Entity down through whichever telemarketer or aggregator is actually transmitting the message, has to be pre-defined and consistent end to end. The original deadline was November 1, 2024, pushed back twice under pressure from telecom operators needing more time for the technical rollout, and finally landing on December 10, 2024.
From December 11, 2024 onward, any message where that chain doesn’t match what’s on record gets rejected outright, not flagged, not delayed, rejected. Over 27,000 Principal Entities had already registered their chains by the time the final deadline hit. On top of that, repeated misuse of a content template now carries a one-month service suspension, and an unregistered telemarketer sending traffic can get blacklisted for up to two years.
Practically, this means the registration work isn’t a one-and-done compliance checkbox anymore. If a business switches which aggregator or platform is sending its messages, that new relationship has to be reflected in the registered chain, or traffic through the new route simply won’t go through.
Why Borrowing Someone Else’s Registration Is a Bad Bet Now
Before the traceability mandate, it wasn’t unusual for a reseller or aggregator to offer clients a shortcut: send under the reseller’s own already-registered Principal Entity and header instead of completing a separate registration. For a client in a hurry, or missing the paperwork to register on their own, this looked like a reasonable workaround.
It’s a much worse trade now. The whole point of the chain-traceability requirement is to make every message traceable back to a specific, verified sender, and a message sent under a PE that isn’t actually the business behind the content is exactly the kind of mismatch the system is built to catch. If that borrowed identity gets flagged for misuse, whether by the client doing something the reseller didn’t authorize or just by inconsistent chain data, the consequences land on whoever’s PE registration was actually used, not on the client who benefited from it. Given that repeated template misuse now triggers a service suspension and unregistered-chain traffic gets rejected outright, the business whose name is on the registration is the one holding the risk for someone else’s sending behavior.
Registering a Principal Entity properly takes paperwork and a bit of waiting, but it’s a one-time cost. Carrying someone else’s compliance risk indefinitely isn’t a one-time cost; it’s ongoing exposure that gets worse every time traffic volume through that borrowed identity goes up.
DLT Registration vs. NCPR/DND Scrubbing
These two systems get mixed together because they’re both part of TCCCPR 2018 and both run before a message goes out, but they’re checking completely different things.
DLT registration, the Principal Entity, header, and template system covered above, verifies who’s sending a message and whether the message matches what they’re approved to send. NCPR and DND scrubbing, covered separately alongside the registered-consent mechanics of this same framework, checks whether the specific recipient has opted out of that category of message. A perfectly registered PE, header, and template can still get blocked at the NCPR/DND stage if the recipient is on the do-not-disturb registry for promotional content. Conversely, a message to a recipient who’s perfectly happy to receive it can still get rejected if the sender’s registration chain doesn’t check out.
Getting a messaging program compliant means clearing both gates, not just one.
A Pre-Launch Checklist
Before a campaign goes anywhere near Indian numbers, it’s worth confirming each of these is actually in place rather than assumed:
- [ ] Principal Entity registered with at least one telecom operator’s DLT platform, using the business’s own legal documents, not a reseller’s or partner’s.
- [ ] Header registered under that PE, in the right category (Promotional, Transactional, or Service) for how it’ll actually be used.
- [ ] Content template registered against that specific header, wording matching exactly what will be sent, variables included.
- [ ] Any URLs, APKs, OTT links, or callback numbers inside the template whitelisted separately.
- [ ] PE-TM chain bound and approved on both sides, naming whichever platform or aggregator is actually transmitting the traffic.
- [ ] A backup chain created in case the primary one fails, per the same process.
- [ ] NCPR/DND scrubbing confirmed as a separate step in the sending pipeline, not assumed to be covered by DLT registration alone.
Missing any one of these doesn’t necessarily mean every message fails. It means the business is one chain mismatch or one unwhitelisted link away from traffic getting rejected with very little warning.
Next Steps
Getting all three registrations in place before launch, rather than scrambling once a template starts getting rejected, saves real time once a campaign is actually ready to go. SMPPCenter’s own DLT scrubbing and filtering checks outgoing traffic against your registered templates, but the underlying Principal Entity, header, and template registrations happen directly with the telecom operators’ own DLT platforms, outside the panel. Current plan and pricing details cover the messaging platform itself, and the why SMPPCenter page covers the compliance infrastructure that sits on top of whatever registrations you bring to it.
FAQs
Do I need a separate Principal Entity registration for each telecom operator? No. Registrations are generally recognized across operators once completed with one DLT platform, which is why most businesses only register once despite multiple telcos carrying their traffic.
Can one content template be used under two different headers? Not anymore. As of the 2024 rules, each template is tied to one specific header, even if the message wording is identical across both.
What happens if a message doesn’t match its registered template exactly? It gets stopped before delivery. The system checks outgoing content against the approved template, and anything that doesn’t match, including an unwhitelisted link, fails that check.
How long does Principal Entity registration typically take? This isn’t stated consistently across telecom operators’ own DLT platforms, and timelines shift as the process changes, so check directly with whichever operator’s portal you’re registering through rather than assuming a fixed turnaround.
What’s the difference between a header and a Principal Entity? The Principal Entity is the business itself, registered once. A header is a specific sender ID that business uses, registered under that entity, and a single PE can hold multiple headers for different purposes (OTPs, order updates, marketing, and so on).
Does switching messaging platforms or aggregators require re-registering anything? The Principal Entity, header, and template registrations stay with the business and don’t need to be redone. What does need updating is the PE-TM chain, since it names the specific platform or aggregator authorized to send, and traffic through a new, unbound platform won’t clear the traceability check until that chain is updated and approved.
Is sending under someone else’s registered Principal Entity actually illegal, or just risky? That’s a legal question specific to the facts of how it’s being done, not something to answer in the abstract. What’s clear from TRAI’s current enforcement model is that the registered entity carries the consequences if the traffic gets flagged, regardless of who actually controls the content being sent.
Checkout other posts
Excel vs Google Sheets vs Airtable for Bulk Messaging: Which Connector Fits
WooCommerce, Shopify, and Magento 2 SMS Plugins: How Each One Actually Triggers a Message
Salesforce, HubSpot, and Zoho SMS Connectors: What They Automate (and What You Still Configure)
Payment Gateway Integration for SMS Platforms: What Auto Wallet Credit Actually Automates
SFTP Bulk SMS Campaigns: An Operations Runbook for File-Drop Messaging at Scale
