Most people who send a text never see the protocol that carries it. For operators, aggregators, and CPaaS providers, though, SMPP is the connection that moves SMS traffic between systems every second of the day. If you are evaluating an SMS platform, you will hear the term in almost every technical conversation.
This guide explains what the SMPP protocol is, how a session works, what commands like submit_sm do, and how SMS platforms use it for routing.
Quick Answer: SMPP, the Short Message Peer to Peer protocol, is an open, session based protocol that runs over TCP/IP and lets external applications exchange SMS messages with an SMSC or SMS gateway. A client opens a persistent connection called a bind, sends messages with submit_sm, and receives delivery reports and inbound messages with deliver_sm. It is the standard for high volume carrier and aggregator SMS traffic.
SMPP Definition
SMPP stands for Short Message Peer to Peer. It is an application layer protocol designed for one job: moving short messages between an external messaging entity, known as an ESME, and a message center such as an SMSC. The protocol has been used for decades and is still the default for wholesale and A2P messaging.
Where SMPP Sits in the Network
SMPP covers the application side of the path. The ESME, such as an enterprise platform or aggregator, connects to the gateway over SMPP. The gateway then handles the network side, including signaling toward the mobile network. Our guide on how an SMS gateway works shows how the two layers fit together.
SMPP Versions
The versions most often seen in production are 3.3, 3.4, and 5.0. Version 3.4 is the most widely deployed, and it is what most platforms support by default. Always confirm which version a partner supports before connecting.
How an SMPP Session Works
SMPP is built around a persistent connection rather than one request per message. That is the main reason it handles volume so well.
The Bind
A session starts when the client opens a TCP connection and sends a bind request with credentials, usually a system ID and password. There are three bind types:
- bind_transmitter sends messages only
- bind_receiver receives messages and delivery reports only
- bind_transceiver does both over one connection
Once the gateway accepts the bind, the session stays open.
Keeping the Session Alive
Either side can send enquire_link to check the connection is still healthy, and the other side replies with enquire_link_resp. A clean shutdown uses unbind. Good platforms monitor bind health and reconnect automatically when a link drops.
PDUs and Sequence Numbers
SMPP messages are called PDUs, short for protocol data units. Every PDU carries a command ID and a sequence number, and each response echoes the sequence number of its request. That lets a client send many messages without waiting for each reply, which is how high throughput is reached.
Key SMPP Commands
| Command | Direction | Purpose |
|---|---|---|
| bind_transmitter / receiver / transceiver | Client to gateway | Opens an authenticated session |
| submit_sm | Client to gateway | Sends a message for delivery |
| submit_sm_resp | Gateway to client | Confirms acceptance and returns a message ID |
| deliver_sm | Gateway to client | Delivers inbound messages and delivery reports |
| deliver_sm_resp | Client to gateway | Acknowledges a deliver_sm |
| enquire_link | Either side | Checks the connection is alive |
| unbind | Either side | Closes the session cleanly |
What Is submit_sm in SMPP?
submit_sm is the command used to send a message. It is the core of outbound SMPP traffic.
What a submit_sm Contains
A submit_sm carries the source address (the sender ID), the destination address, the message content, and control fields such as the data coding scheme, which says whether the text is GSM 7 bit, UCS2, or another encoding. It also includes a flag that asks for a delivery receipt.
submit_sm_resp and the Message ID
When the gateway accepts the message, it replies with submit_sm_resp containing a message ID. Note that this response means the gateway accepted the message, not that the handset received it. Final delivery status comes later.
Long Messages
A single SMS is limited in size, so long texts are split into segments and tied together with concatenation information so the handset can reassemble them. How a platform handles segmentation affects both billing and delivery, so it is worth testing with partners.
Delivery Reports and deliver_sm
After the gateway forwards the message into the network, the final result returns to the client as a deliver_sm carrying a delivery receipt. It includes the original message ID, so the client can match it to the right submit_sm and mark the message as delivered, failed, or expired. The same deliver_sm command also carries inbound messages from subscribers, which is how two way SMS works over SMPP.
How SMS Platforms Use SMPP for Routing
SMPP is not only the sending protocol. It is also how traffic moves between networks of partners, and that makes it central to routing.
Customer Side and Vendor Side
A wholesale or aggregator platform usually runs SMPP on both sides. Customers bind to the platform to send traffic, and the platform binds out to upstream vendors and operators to deliver it. In between sits the routing engine, which picks the upstream bind for each message.
How the Routing Decision Is Made
For each submit_sm, the platform can check the destination, the customer’s rate plan, and the quality and cost of each available route. It then forwards the message on the chosen upstream bind and tracks the receipt coming back. If a route degrades or a bind drops, traffic can fail over to a backup. Our overview of SMS wholesale management explains how this connects to rate cards and margin.
Throughput and Windowing
Because a client can send many submit_sm requests before waiting for responses, platforms set a window size that limits how many unacknowledged messages can be in flight. Tuning that window, along with message rate limits per bind, is how carriers protect their systems and keep delivery steady.
SMPP vs HTTP SMS
SMPP and HTTP APIs reach the same end result with different designs. SMPP uses a persistent binary session built for sustained volume. HTTP uses stateless requests that are easier for web developers to integrate. Most carrier grade platforms support both, so partners can connect in whichever way fits. Our detailed SMPP vs HTTP SMS API comparison covers the trade offs, including when each one is the better choice.
SMPP Security and Fraud Considerations
An SMPP bind is a direct line into a messaging system, so it needs protection. Good practice includes strong credentials, IP allow lists, encrypted connections where supported, and per bind limits on rate and sender IDs. Platforms also pair SMPP access with an SMS firewall to catch spam, spoofed sender IDs, and grey route traffic before it reaches subscribers.
Choosing an SMPP SMS Gateway
When comparing platforms, check these points:
- Which SMPP versions are supported
- Bind types, session limits, and window controls
- Routing logic, failover, and delivery receipt accuracy
- Reporting by bind, route, and destination
- Fraud and security controls on every connection
Enabld’s SMS gateway platform supports SMPP alongside HTTP and SS7, so operators and aggregators can connect partners in the protocol each one already uses. It also forms the messaging base for a branded CPaaS platform.
Final Thoughts
SMPP is a simple idea executed well: a persistent session, a small set of commands, and receipts that return on the same connection. That design is why it has outlasted so many newer technologies and why it still carries a large share of A2P and wholesale SMS. If you are connecting partners or planning an SMPP gateway for your network, talk to the Enabld team about your traffic and connection needs.
Frequently Asked Questions
What is the SMPP protocol?
SMPP, the Short Message Peer to Peer protocol, is an open protocol over TCP/IP that lets external applications exchange SMS messages with an SMSC or SMS gateway using a persistent, authenticated session.
What does submit_sm do in SMPP?
submit_sm is the command a client uses to send a message. It carries the sender, destination, content, and encoding. The gateway replies with submit_sm_resp and a message ID to confirm it accepted the message.
What is the difference between bind_transmitter, bind_receiver, and bind_transceiver?
A transmitter bind only sends messages, a receiver bind only receives messages and delivery reports, and a transceiver bind does both over a single connection.
How do delivery reports work in SMPP?
The gateway returns delivery receipts to the client in a deliver_sm command, using the same message ID returned earlier, so the client can match each receipt to its original message.
What is the difference between SMPP and HTTP for SMS?
SMPP uses a persistent session built for high volume traffic, while HTTP APIs send each message as a separate request and are simpler to integrate. Many platforms support both.
Is SMPP only used by telecom operators?
No. Aggregators, CPaaS providers, and large enterprises also use SMPP, mainly when they need sustained throughput and direct delivery receipts.
How does an SMPP gateway handle routing?
The gateway receives each submit_sm on a customer bind, then chooses an upstream bind based on destination, cost, and route quality, forwarding the message and tracking the receipt that comes back.
Is SMPP secure?
SMPP itself is basic, so security depends on how it is deployed. Strong credentials, IP allow lists, encrypted connections where supported, rate limits, and an SMS firewall all help protect SMPP connections.
