MO and MT are the two directions an SMS can travel, and the abbreviations are named from the handset's point of view rather than the sender's. That inversion is the only difficult part, and getting it backwards makes documentation read as nonsense.
Which is which?
- MT, mobile terminated, is a message whose journey ends at a handset. Everything you send to a customer is MT: the passcode, the delivery notification, the campaign.
- MO, mobile originated, is a message that starts at a handset. A reply to your message, a
STOP, a keyword texted to a short code.
The mnemonic that sticks is the destination: terminated means it terminates at the phone.
Why does the distinction have its own vocabulary?
Because the two directions are genuinely different operations, not one operation with a flag.
In SMPP, the protocol underneath most SMS delivery, an application sends with submit_sm and receives with deliver_sm. They are separate operations on the same session, travelling opposite ways. An HTTP API hides that behind a send endpoint and an inbound webhook, but the shape survives: sending is a call you make, receiving is an event that arrives.
The consequence people meet first is that delivery receipts are inbound messages. A receipt is not a field on the message you sent; it is something arriving the other way, on the same path a reply would take. The SMPP delivery receipt reference puts it plainly:
Message delivery receipts are returned in the deliver_sm and data_sm operations.
That is why a receipt and a reply can be confused for each other, and why both reach you asynchronously rather than as the answer to your send. What is a delivery receipt covers how much to trust one.
Does the direction change what it costs?
Usually, and in ways that change what you can design.
MT is what a sender pays for: one charge per segment, varying by destination. MO is charged differently and often to the recipient, depending on the country, the sender type and the recipient's plan. Per-country specifics are published rather than fixed, so they live on the destinations page rather than in this one.
The design consequence is the useful part. If replying to your message might cost the recipient, a flow that depends on them replying is asking them to pay to use it. That is a reasonable thing to do for a keyword campaign on a short code, and an unreasonable thing to build a password reset around.
What is inbound capability, and do I have it?
Not every sender can receive at all, which is the practical form of this distinction.
A sender you can reply to is one that can receive MO messages. An alphanumeric sender ID cannot: there is no number to reply to, so a recipient's reply has nowhere to go. That is a property of the sender type rather than a setting, and it is the main reason to choose one sender over another when a conversation matters.
Two things follow that catch senders out. A campaign sent from a sender with no inbound capability cannot honour a STOP sent as a reply, which is a compliance problem rather than an inconvenience: what is a STOP keyword covers what has to happen when one arrives. And a flow designed around replies has to pick a sender type before it can work at all.