01What is DLT scrubbing?
DLT scrubbing is the real-time check that an Indian access provider runs on every commercial SMS before delivering it. Under TRAI's TCCCPR framework, a business (the principal entity) first completes DLT Registration of its entity, headers and content templates on an operator's Distributed Ledger Technology (DLT) platform. Scrubbing is the enforcement step that follows: each message is compared with what was registered, and anything that does not match is dropped before it reaches a handset.
The checks follow the same logic on every network, even if the order varies. Is the DLT Header registered, active and owned by the principal entity named on the message? Does the text match a DLT Content Template linked to that header, with only the {#var#} placeholders varying? Does the declared PE-TM Chain Binding (the chain of telemarketers carrying the message) match what was registered? For promotional traffic, does the recipient's preference in the DND Registry (NCPR) allow this category? For service-explicit traffic, is there a valid consent record? And, since 1 October 2024, is every URL, APK or OTT link in the text whitelisted?
Scrubbing is neither registration nor a delivery report. Registration happens once, on a portal; scrubbing happens on every send, inside the operator's network. An SMS Delivery Report says whether a handset received a message, whereas a scrubbing rejection means the message was never sent to the handset at all. Rejections usually reach the sender as a failed DLR carrying an operator- or aggregator-specific error code, which is why mapping those codes to causes is the first job when a campaign under-delivers.
Key takeaways
- DLT scrubbing is the operator-side check every commercial SMS in India passes before delivery: header, template, chain, links, consent and preferences.
- A message that fails any check is dropped, not queued, so one edited word in fixed template text can block a whole campaign.
- Since 1 October 2024, SMS carrying URLs, APK or OTT links that are not whitelisted fail scrubbing.
- Promotional SMS is checked against the recipient's DND preference; service-explicit SMS needs a recorded consent instead.
- Rejections come back as failed delivery reports with operator- or aggregator-specific codes, so map codes to causes before retrying.
02 · How it works, step by step
How does DLT scrubbing work?
- Step 1
The message goes out with its DLT identifiers
Your application or aggregator submits the SMS with the principal entity ID, the header, the registered content template ID and the telemarketer chain details, as SMPP optional parameters or as fields your aggregator's API defines.
- Step 2
Header and entity check
The DLT platform of the operator the traffic enters confirms that the header is registered, active, mapped to that principal entity and of the right type for the message category.
- Step 3
Template match
The text is compared with the template registered under that ID and header. Fixed text must match exactly, including spaces and punctuation; only the
{#var#}positions may differ, within their length limit. - Step 4
Chain and link checks
The declared PE-TM chain must match the registered binding, and every URL, APK or OTT link in the text must be on the entity's whitelist.
- Step 5
Preference and consent check
Promotional messages are scrubbed against the recipient's NCPR preference and the sending-hour rules; service-explicit messages need a valid consent record; transactional and service-implicit messages skip the DND check.
- Step 6
Deliver or drop
Messages that pass go on to the terminating network. Those that fail are dropped and reported back as a failed delivery report with a rejection code.
03DLT scrubbing: key facts and limits
- Where it runs
- On the operator's DLT platform, for every commercial SMS
- Legal basis
- TRAI TCCCPR 2018 and its amendments
- Checked against
- Header, content template, PE-TM chain, links, consent, NCPR preference
- Link rule
- Non-whitelisted URLs, APK and OTT links blocked since 1 October 2024
- Chain enforcement
- Undeclared PE-TM chains rejected since 11 December 2024
- Template variables
- {#var#} placeholders; fixed text must match exactly
- Failure signal
- Failed delivery report with a provider-specific error code
04Example: A Pune lender's festive send that half-failed
A Pune consumer-finance company sends a promotional SMS to 2 lakh customers and sees only about 62% delivered. The failed delivery reports group into three causes. A copywriter changed "valid till" to "valid until" in the fixed text, so one segment failed the template match. A new click-tracking short domain had never been whitelisted, so another segment failed the link check. The rest were customers whose DND preference blocks this category, an expected loss rather than an error. The team re-registers the edited wording as a new template, whitelists its own branded short domain, adds a pre-send template check to its sending service and resends the two failed segments the next morning (figures illustrative).
05DLT scrubbing in code
// Check rendered text against the registered DLT template before submitting.// Fixed text must match exactly; each {#var#} may hold up to MAX_VAR characters.const MAX_VAR = 30; // a common per-variable limit: confirm your DLT platform's rulefunction templateToRegex(template) {const parts = template.split("{#var#}").map((s) => s.replace(/[.*+?^${}()|[\]\\]/g, "\\$&"));return new RegExp("^" + parts.join(`[\\s\\S]{0,${MAX_VAR}}`) + "$");}const registered = {id: "1107160000000000000", // DLT content template ID (illustrative)text: "Dear {#var#}, your EMI of Rs.{#var#} is due on {#var#}. Pay at {#var#} - ABC Finance",};export function matchesTemplate(text, tpl = registered) {return templateToRegex(tpl.text).test(text);}matchesTemplate("Dear Asha, your EMI of Rs.4,250 is due on 05-Nov. Pay at https://abcfin.in/p/x7 - ABC Finance"); // truematchesTemplate("Hi Asha, your EMI of Rs.4,250 is due on 05-Nov. Pay at https://abcfin.in/p/x7 - ABC Finance"); // false: fixed text changed
A local check catches template drift before the operator does. It cannot see the whitelist, consent or DND state, so the delivery report still has the final word.
06 · Common mistakes, and the fix
Common mistakes with DLT scrubbing
Editing fixed template text in code
A changed word, an extra space or swapped punctuation outside a
{#var#}breaks the match. Keep each template's text in one versioned place tied to its template ID, and run a test send after every edit.Retrying scrubbing rejections
A message rejected for its header, template or chain will be rejected again. Classify the failed DLR first; retry only handset-side failures, and fix the registration for the rest.
Putting offers in service templates
Content that mixes a promotion into a service or transactional message is treated as promotional, so it meets the DND check and can be flagged as misuse. Register a promotional template for offers.
Adding links or routes after registration
A new tracking domain or a new aggregator in the route must be whitelisted or added to the PE-TM chain before the first send, not after the rejections arrive.
Reading "submitted" as "sent"
An HTTP 200 from your aggregator only means it accepted the message. Track the delivery report per message to see what scrubbing actually did.
07Why does DLT scrubbing matter?
For any business sending OTPs, order updates or offers by SMS in India, scrubbing decides what actually leaves the network. A template edited by one character, a header that lapsed, a new tracking domain nobody whitelisted or an undeclared aggregator in the route will quietly zero out a send while your application logs "submitted". Teams that understand scrubbing read the failed DLR, fix the right registration and resend within the hour; teams that don't blame the network, retry blindly and pay for messages that were never going to pass.
08 · Tips from the bench
Best practices for DLT scrubbing
- Keep a table mapping your aggregator's rejection codes to causes, and alert when one cause passes a threshold.
- Validate rendered text against the registered template in your own code before submitting.
- Use one template per purpose; templates stuffed with variables are harder to match and more likely to be refused.
- Whitelist a branded short domain once and reuse it across templates.