Sender ID and header guide
Your SMS sender ID should match the business, the message, and the code.
DLT header registration is not only about choosing a short name. The sender identity should connect to the brand, the message category, the approved template, and the API payload used by the SMS provider.
SMS sender ID is one of the most searched DLT topics because it is visible to customers and easy to misunderstand. Business teams think about branding. Developers think about the sender field in the API. Providers think about DLT-approved headers. Operations teams think about why one message arrived with one display name and another arrived differently.
The practical answer is to treat sender ID and DLT header registration as an identity register. Every sender header should have a reason, a category, supporting evidence, related templates, provider mapping, and a handover owner.
Official source note: TRAI's sender guidance explains that commercial communication is carried through registered headers and lists header registration alongside entity, content template, consent, and bulk communication requirements: TRAI Advice to Senders.
A useful header is connected
Quick answer
A DLT sender ID should be planned as a governed sender identity.
Before submitting a sender header, document:
- The business or product name the header represents.
- The message category and use case.
- Brand evidence such as website, app, invoice, product, or customer journey.
- Whether the header is for OTP, service alerts, explicit-consent reminders, or campaigns.
- Which content templates will use this header.
- Which provider API field will carry the approved sender value.
- Who owns future header changes and support tickets.
What is a DLT sender ID or SMS header?
In business conversations, "sender ID" usually means the name or identity customers see when an SMS arrives. In DLT implementation work, the more precise operational asset is the sender header registered for the business and mapped to message traffic.
The final handset display can include operator, route, or category formatting that the business does not design directly. That is why the useful internal question is not only "what will the customer see?" It is:
- Which approved header should this message use?
- Does the header match the business and category?
- Which template IDs are allowed under this header?
- Which API request field sends the value?
- How will support know whether a production message used the correct header?
Sender header planning checklist
Header registration preparation
- List the business names, product names, and abbreviations customers already know.
- Remove candidates that are too generic, misleading, or disconnected from the legal entity.
- Separate OTP and security messages from service alerts and promotional communication.
- Create evidence notes for each candidate header.
- Decide whether each header is permanent, temporary, or only for a campaign.
- Keep a requested/approved/rejected status table outside the portal.
- Map approved headers to templates and API payloads.
The evidence note is important. A sender header that makes sense to the founder may not be obvious to a reviewer or a future developer. Write the connection down.
Header examples by use case
| Business flow | Better header planning | Risky header planning |
|---|---|---|
| SaaS login OTP | Product or company abbreviation tied to account access | Generic security name unrelated to the business. |
| Dry cleaning order alert | Store or brand abbreviation tied to order status | Promotional brand variant used for service updates. |
| Clinic appointment reminder | Clinic or platform header tied to booking flow | One broad header shared with campaign messages. |
| Offer campaign | Promotional header with consent and preference controls | Reusing OTP header for discounts. |
These examples are planning patterns, not approval guarantees. The live portal rules and operator review still control outcomes.
How headers connect to templates
A sender header should not be approved in isolation and then forgotten. Each content template should point back to the header that will send it.
Header-template mapping
| Header asset | Related template | API note | Maintenance rule |
|---|---|---|---|
| Login header | OTP login template | sender plus approved template ID | Do not add marketing copy. |
| Order header | Order status template | Include order ID and status variables | Retest if wording changes. |
| Clinic header | Appointment reminder template | Confirm consent basis and appointment source | Keep reminder copy fixed. |
| Campaign header | Offer template | Apply provider campaign controls | Review before every campaign set. |
If the developer sends a different header or modifies the template wording, the approved DLT record may no longer match the production behavior. That is why the DLT runbook should sit next to the SMS integration notes.
Handover register for approved headers
Every approved sender header should have a row in a handover register:
- Approved header value.
- Portal or operator where it was registered.
- Category or use case.
- Associated content template IDs.
- Associated consent template IDs where applicable.
- SMS provider account and API field name.
- First successful test date.
- Owner for future changes.
- Notes for rejection or expiry review, if relevant.
Common sender ID mistakes
Choosing a clever abbreviation no one can prove
The header may be short and memorable, but if it does not connect to the business identity, the submission becomes harder.
Mixing service and promotional flows
Customers and reviewers should not see one sender identity used for both account security and unrelated offers without a deliberate plan.
Not telling developers the approved value
Portal approval does not update source code. The sender value must be mapped into the provider integration and tested.
No record of rejected headers
Rejection notes are useful. They prevent the team from resubmitting the same weak candidate later.
FAQ
Is SMS sender ID the same as DLT header?
In daily language they are often used together. In implementation work, use the exact DLT and provider terminology from the portal and API docs so the approved asset maps correctly.
Can I register multiple SMS sender IDs?
Many businesses plan multiple headers for different brands or message categories. Each should have a clear use case and supporting evidence.
Should the sender ID be hardcoded in the app?
Avoid hardcoding without documentation. Keep the sender, template ID, and variables in a controlled configuration or runbook so future updates are reviewed.
Can Shinka prepare the header register?
Yes. Shinka can help organize sender candidates, category mapping, evidence notes, provider fields, and the post-approval handover register.
