Sender ID (SMS Header)

The short alphabetic code shown as the sender of a commercial SMS in India — registered on DLT and permanently tied to one message category.

A sender ID, also called a header, is the identifier recipients see in place of a phone number when they receive a commercial SMS. In India these are six alphabetic characters, assigned to a registered entity through the DLT system rather than chosen freely at send time.

The critical property is that a header is bound to a category, and the category determines who you are allowed to reach:

  • Transactional. Messages arising from a customer action or an existing relationship — one-time passwords, order confirmations, appointment reminders, account alerts. These reach numbers registered on the Do Not Disturb list, because the consumer has an existing relationship with the sender.
  • Service (implicit / explicit). Informational messages within an existing relationship that are not strictly transactional. Reach depends on the consumer's registered preferences.
  • Promotional. Marketing content. Blocked for consumers who have opted out of that preference category, and typically restricted to daytime sending windows.

Because the binding is enforced at the operator, a header cannot be repurposed. An organisation that sends both OTPs and offers needs at least two headers, and the sending platform has to route each message to the correct one. Getting this wrong is one of the most common causes of unexplained delivery gaps: promotional content submitted on a transactional header may be dropped, and repeated violations can put the header itself under review.

Headers are also a branding asset. A recognisable, consistent header improves open behaviour and reduces the chance of a message being read as spam — which is why it is worth registering something readable rather than accepting whatever six characters happen to be free.

Common mistakes

  • Using one header for everything. Transactional and promotional traffic need separate headers; sharing one puts delivery at risk.
  • Assuming a header is portable across providers instantly. The entity registration carries over, but routing has to be reconfigured.
  • Choosing an opaque code. Recipients judge legitimacy partly by the header; an unrecognisable string reads as spam.

Need this handled properly? See how we run it →

Related terms