What Is A2P Messaging? Application-to-Person SMS Explained

A2P messaging, short for application-to-person messaging, is any text message generated by a software system and delivered to a person’s mobile handset. One-time passcodes, delivery notifications, appointment reminders, fraud alerts, booking confirmations and marketing campaigns are all A2P. The opposite category is P2P, person-to-person, where a human composes a message on one handset and it arrives on another.

The distinction has almost nothing to do with how the message is technically constructed. An A2P message and a P2P message can be byte-identical when they reach the handset. What separates them is who sent it, how it was submitted to the network, what commercial agreement covers it, and what regulatory obligations attach to it. Those four things determine whether your message is priced as enterprise traffic, whether it is delivered at all, and what happens to your sender name on the way.

Quick facts

The SMS standards never define A2P

This is the single most useful thing to understand, and almost no explanation of A2P mentions it.

If you open 3GPP TS 23.040, the specification that defines how SMS actually works, you will not find the terms A2P or P2P anywhere. The specification defines two basic services: short message mobile originated (SM MO) and short message mobile terminated (SM MT). It defines a Service Centre that acts as a store-and-forward point, and it defines a Short Message Entity, or SME, as an entity that can send or receive short messages. The specification is explicit that an SME may sit in a fixed network, in a mobile station, or in the Service Centre itself.

In other words, the standard was written from the start to accommodate an application as a legitimate endpoint. It simply does not care whether a human or a program composed the text.

A2P is therefore a commercial and regulatory category layered on top of a protocol that is indifferent to it. That layer is real and has teeth, but it lives in interconnect agreements, operator firewalls and national regulation, not in the message format. Understanding this explains several things that otherwise look arbitrary: why identical messages can be priced very differently, why a message can be blocked without any protocol error being wrong, and why “is this A2P?” is a question your provider and the terminating operator answer, not one you answer for yourself.

How an A2P message reaches a handset

The path has four stages.

Submission. Your application hands the message to a messaging provider, either over an HTTPS API or over SMPP. SMPP, the Short Message Peer-to-Peer protocol, is the native interface: your application acts as an External Short Message Entity (ESME) and binds to the provider’s message centre, then issues a submit_sm operation for each message. Version 3.4 remains the working default across the industry, and its specification is published at smpp.org. An HTTPS API is almost always a convenience wrapper over the same underlying SMPP path.

Routing. The provider determines which mobile network currently holds the destination number. This is not a matter of reading the country code and the prefix, because number portability means a number’s original network is frequently not its current one. Getting this wrong is a common and expensive cause of failed delivery, which is why a network lookup step exists. Our guide to HLR lookups covers what that query returns.

Interconnect. The message crosses from your provider into the terminating operator, either through a direct commercial interconnect or through one or more intermediate hubs. The GSMA documents the architecture for hub-based interworking in IR.75, which specifies both SS7 and SMPP interconnection and the address-handling rules that keep the originating party identifiable across hops.

Termination. The terminating operator’s SMSC attempts delivery to the handset, retrying according to its own policy if the subscriber is unreachable, and discarding the message once the validity period expires.

A P2P message covers most of the same ground. The difference is at the front: a handset submits it to its home operator’s SMSC as a mobile originated message, and that SMSC forwards it onward. From the terminating operator’s perspective, both flows arrive as mobile terminated traffic that has to be classified.

A2P and P2P compared

The last row is the one that catches people out. You describe your traffic when you contract with a provider, but the terminating operator forms its own view based on volume, message content, sender address, submission path and traffic shape. If A2P traffic is submitted in a way that makes it look like P2P, whether deliberately or through a badly chosen route, the terminating operator may treat it as a bypass attempt and block it. Traffic taking that kind of route is generally referred to in the industry as a grey route, and detecting it is one of the main functions of an operator’s messaging firewall.

Sender IDs and who authorises them

What the recipient sees in the sender field is not free text, even though the protocol permits an alphanumeric value there.

Three sender types are in general use. A long number is an ordinary E.164 telephone number, which supports replies and looks like an individual sender. A short code is a shortened number allocated nationally for messaging, usually expensive and slow to obtain. An alphanumeric sender ID is a short text string, typically a brand name, which is what most transactional and marketing traffic uses where it is permitted.

Alphanumeric sender IDs cannot receive replies, which is the trade-off for showing a brand name. More importantly, the rules governing them vary sharply by country. Some markets allow them freely, some require pre-registration of each string with a national registry before traffic will be delivered, and some prohibit them outright and require a long number instead. There is no global rule, and assuming otherwise is one of the most common ways a multi-country launch fails.

The direction of travel is towards more control, not less. In the UK, Ofcom finalised new rules in July 2026 requiring mobile operators and the aggregators that carry business messages to run due diligence checks on new senders, to run ongoing checks on their traffic, and to corroborate a sender’s ID against what they know about that business. Ofcom’s own illustration is a business presenting itself as a hairdresser while sending parcel delivery messages. Providers must also maintain a policy covering protected sender ID lists and generic sender IDs such as “customer service”. Notably, Ofcom frames the problem by splitting messaging scams into person-to-person and business messaging categories, which is the A2P and P2P line drawn in regulation rather than in a protocol.

That obligation is UK-specific, but the pattern behind it is not. Sender identity is where regulators are concentrating, because it is the part of a text message a recipient uses to decide whether to trust it.

Why “delivered” is an unreliable word in A2P

Ask three engineers what a delivery receipt proves and you will get three answers, because there are genuinely three different acknowledgements travelling back along the path.

The first is the response to your submission. Over SMPP this is submit_sm_resp, which returns a message identifier. It means the provider accepted the message and took responsibility for it. Nothing has reached a mobile network. The second is an intermediate acknowledgement passed back between hops. GSMA IR.75 is unusually candid about this one: it describes a store-and-forward hub responding with an acknowledgement that the message has been sent, and states plainly that this is not reliable, because the hub has not in reality forwarded the message anywhere yet. The third is the delivery receipt proper, returned as a deliver_sm carrying a final message state. The documented states include ENROUTE as an intermediate value and DELIVERED, EXPIRED, DELETED and UNDELIVERABLE as final ones, usually seen in the abbreviated form stat:DELIVRD.

Only the third relates to the handset, and even then with a qualification. IR.75 notes that honest delivery reporting is not usually guaranteed in an SMPP environment, and recommends MAP over SS7 for operators to whom delivery reporting genuinely matters. The GSMA document goes as far as listing “honest delivery reports supported” as a technical parameter that hubs need to collect and share about each connected operator, which tells you how routinely the answer is no.

The practical consequence is that a delivery rate quoted without reference to which acknowledgement it counts is close to meaningless. When you evaluate a provider or debug a delivery problem, the question to ask is not “what is your delivery rate” but “at which point in the chain is that measured, and for which destinations does the terminating network return real receipts”. That question separates providers who know their own routes from those who are reselling someone else’s.

How terminating operators decide whether to carry your traffic

An operator’s messaging firewall sits in front of its SMSC and inspects arriving traffic before delivery. IR.75 sets out the filtering that hubs and operators are expected to support, and the list is a useful description of the levers involved: blocking by originating Service Centre address, by originating or destination number, by operator, by message content, and by the presence or absence of a contractual interworking relationship. It also requires that a routing lookup precede each delivery attempt so the originating node’s address can be validated first, and specifies which error codes should be returned when a message is rejected.

Rejections therefore look like ordinary protocol errors. A message blocked for commercial reasons may come back as “unknown subscriber”, which is the same error a genuinely invalid number produces. This is deliberate, and it means error codes alone rarely tell you whether you have a data problem or a routing problem.

Three factors weigh most heavily on whether your traffic is accepted cleanly:

• Whether the route is commercially recognised. A direct interconnect or a properly contracted hub relationship is visible to the terminating operator as legitimate enterprise traffic. Traffic arriving by other means is a candidate for blocking.
• Whether the sender identity is consistent. Sender IDs that rotate unpredictably, or that do not match the business behind the traffic, are exactly what the newer regulatory duties are designed to catch.
• Whether the traffic shape matches the stated use case. A sender registered for one-time passcodes that suddenly sends promotional bursts to unfamiliar ranges will attract attention.

Fraud pressure is what hardened all of this. Two patterns matter most. Smishing uses a spoofed or plausible sender ID to impersonate a trusted organisation. Artificially inflated traffic, often called SMS pumping, exploits a public form that triggers one-time passcodes, driving large volumes of messages to number ranges that the attacker profits from. Both push operators towards stricter filtering, and both make life harder for legitimate senders. The same dynamic is visible on the voice side, which we cover in caller ID reputation and “spam likely” labels.

Common mistakes

Treating A2P as a single global product. Sender ID rules, registration requirements, content restrictions and permitted sender types differ by country. A configuration that works in one market can be rejected outright in the next.

Assuming a submit response means delivery. It means acceptance. Build your retry and escalation logic around final states, and know which destinations return them.

Optimising purely on per-message price. The cheapest route is frequently the one most likely to be filtered, and a rejected one-time passcode costs far more than the message saved. Price and route quality are the same decision.

Ignoring number portability. Routing on the number’s original range rather than its current network produces failures that look random and are not.

Confusing A2P with bulk SMS. Bulk describes volume. A single high-value one-time passcode is A2P; a hundred thousand promotional messages are also A2P. The category is about origination, not quantity.

Sending an alphanumeric sender ID where replies are expected. Alphanumeric senders cannot receive responses. If your workflow needs two-way conversation, you need a long number, which brings its own routing and registration questions.

Where didlogic fits

didlogic operates at the connectivity layer of A2P messaging. It provides the numbers, the routes and the interconnects that carry messages between an application and the mobile networks that terminate them. It is not a campaign tool, a CRM or a customer engagement platform, and it does not compose or schedule your messages.

On the outbound side, SMS is sent through a REST API or the account portal, with messages submitted by HTTP request and message status retrievable by identifier. Outbound sending is available across account levels. Inbound messaging works differently: it is tied to the Mobile DID product, available on Plus accounts and above, and delivers each received message to a URL you configure as an HTTP POST containing the source number, destination number, message body and timestamp. Your endpoint must respond with HTTP 200, or the delivery is retried. Inbound coverage is limited to a defined list of countries published on the setup page.

Routing is the part that connects back to everything above. didlogic runs its own autonomous system and interconnects with carriers directly rather than routing through public aggregators, which is the same infrastructure position it holds for voice. In A2P terms, that reduces the number of hops between submission and termination, and it means the commercial relationship behind your traffic is the kind terminating operators recognise. Whether an alphanumeric sender ID is permitted, and whether registration is required first, depends on the destination country’s rules rather than on the provider, so sender configuration is worth confirming per market before launch. Per-destination outbound rates and inbound per-number pricing are published on the SMS rates page.

Frequently asked questions

What does A2P stand for?
Application-to-person. It describes a message originated by a software system and delivered to a person’s mobile handset, as opposed to P2P, person-to-person, where both ends are people using handsets.

How does A2P messaging work?
An application submits a message to a messaging provider, usually over SMPP or an HTTPS API layered over it. The provider identifies the network that currently holds the destination number, passes the message across an interconnect to the terminating operator, and that operator’s SMSC attempts delivery to the handset. Status information flows back along the same chain.

Is A2P messaging the same as bulk SMS?
No. Bulk SMS describes volume. A2P describes origination. A single one-time passcode sent to one recipient is A2P; a large promotional campaign is also A2P. Most bulk SMS is A2P, but not all A2P is bulk.

Do I need to register before sending A2P messages?
It depends entirely on the destination country. Some markets require registration of alphanumeric sender IDs before traffic is delivered, some require registration of the sending business or campaign, and some require neither. There is no single global registration.

Why do some of my messages disappear without an error?
The most common causes are a delivery receipt that never arrives because the terminating network does not return genuine reports, and a message that was accepted at submission but filtered further along the chain. A rejection can also surface as a generic error such as “unknown subscriber” even when the number is valid, because operators reuse standard error codes for commercial blocking.

What is the difference between A2P messaging and A2P calling?
Both describe automated traffic originated by an application, but they run over entirely different infrastructure. A2P messaging uses the SMS network and its message centres. A2P calling uses voice interconnects, and is subject to a separate set of caller ID, consent and answer-rate considerations.

Can A2P messages be two-way?
Yes, but only if the sender is a number rather than an alphanumeric string. Replies arrive as mobile originated messages and are delivered to your application, typically as a webhook. Alphanumeric sender IDs cannot receive replies.

Continue learning

• What is a DID?
• Virtual phone numbers explained
• E.164 explained: the international number format
• HLR lookup explained: what it tells you about a number
• Caller ID reputation and “spam likely” labels explained
• VoIP toll fraud and SIP security: how attacks happen