Back to blog Quality and Trust

How to Create an A2P SMS Test Matrix by Destination, Carrier, Sender, and Message Type

An operational guide to designing repeatable A2P SMS tests, recording technical evidence, and comparing routes without confusing DLRs with delivery observed on a handset.

Equipo editorial de BulkSMSMarket06 September 2026Editorial control 94/100

Operational A2P SMS test matrix with destinations, networks, senders, and delivery results

Why an Isolated Test Does Not Validate an SMS Route

An SMS sent to a single number, on a single network, during a single time window only describes that specific case. It does not demonstrate that the same route will maintain comparable behavior across other countries, subscriber networks, sender types, encodings, lengths, or legitimate content.

An A2P SMS test matrix turns a one-off check into a repeatable evaluation program. Its purpose is not to promise delivery or replace production monitoring: it is to generate comparable evidence for deciding which routes deserve closer observation, which scenarios require investigation, and under what conditions a route can be assessed before receiving more traffic.

The main discipline is not to extrapolate beyond the sample. A favorable result in one destination does not validate an entire country; a favorable result on one network does not necessarily validate another network; and a favorable DLR does not, on its own, prove that a person saw the message in their phone interface.

Treat each combination of variables as an independent test cell.
Maintain an identifiable version of the matrix and of every executed case.
Compare only equivalent cells, or document precisely which variable changed.
Separate observed facts from contractual, technical, or commercial statements made by third parties.

Why an Isolated Test Does Not Validate an SMS Route

What the Matrix Must Answer Before Moving Traffic to Production

Before scaling traffic, the matrix should answer specific operational questions. Which combinations of destination, network, sender, and content have been tested? What results were observed? How many comparable observations exist? Which statuses arrived, in what sequence, and with what delay? Were there differences between initial acceptance, callbacks or DLRs, and delivery observed on a test handset?

Not every decision requires the same level of evidence. A route under exploration may require controlled testing and manual review. A route that will receive sensitive traffic, such as OTPs or transactional notifications, requires case coverage that is closer to its real use, with internal risk limits defined by the responsible team.

The matrix must also make untested areas visible. The absence of a result must not become a positive inference. Mark cells without a sample as not assessed, not as correct.

Coverage: which destinations, networks, and scenarios are actually represented.
Repeatability: whether the same case can be run and compared again.
Evidence: what happened on the platform, what the provider reported, and what was independently observed.
Uncertainty: what cannot be concluded because of sample size, lack of a test handset, or changing conditions.
Decision: scale, keep under observation, pause, or investigate.

What the Matrix Must Answer Before Moving Traffic to Production

Core Dimensions of an A2P SMS Test Matrix

The design begins by defining the dimensions that can affect the result. Normalize the destination number in international format and retain the country as an explicit field. ITU-T Recommendation E.164 is the appropriate reference for representing the international dimension of numbering.

Do not infer the current operator solely from the number range. Mobile number portability allows an MSISDN to be retained when changing subscriber networks. It is therefore useful to distinguish the operator inferred from a range, where available, from the observed or confirmed subscriber operator or network obtained through an authorized procedure.

Record the sender exactly as submitted. The sender type may be alphanumeric, numeric, or another format permitted by the applicable technical and regulatory context. Do not assume that one sender will behave identically to another, even for the same destination.

Country and destination in international format.
Mobile network or subscriber network, with the attribution source.
Numbering type and known portability status, where applicable.
Route, connection, or configuration under evaluation.
Submitted sender and its format.
Message type: OTP, transactional, or authorized marketing.
Encoding, alphabet, length, and segmentation.
Time window and execution date.

Keep OTP, Transactional, and Authorized Marketing Separate

OTPs, transactional messages, and authorized marketing should not be combined in the same operational conclusion. Although they all use SMS, they often involve different expectations for content, timing, and traceability. A test should represent the legitimate use case being assessed, without indiscriminately reusing the same text for every scenario.

For OTPs, use unambiguous test texts without personal data or codes that grant real access. Record the submission time and handset observation when a controlled test device is available. For transactional messages, use a fictional notification that is clearly identified as a test. For marketing, limit tests to authorized numbers and content that complies with applicable obligations.

This separation reduces incorrect interpretations. A technical result for a short test message does not necessarily demonstrate the behavior of a concatenated message, a message with non-GSM characters, or a different sender.

OTP: short test text, with no credentials or real access.
Transactional: fictional, identifiable event with no sensitive information.
Authorized marketing: authorized test recipients only and compliant content.
Do not combine results across categories without stating that the use case changed.

Select Test Numbers Responsibly

Maintain a controlled inventory of test numbers with documented authorization to receive messages. Each number should have an internal identifier, country, international format, source of network attribution, and, where possible, information about whether delivery can be observed on a controlled handset.

Do not expose full numbers in widely shared reports unless necessary. Use an internal identifier or a masked version in dashboards, and reserve complete operational data for appropriate access controls.

Review the inventory regularly. A number may change status, device, or subscriber network. If a result depends on a condition that can no longer be verified, mark that cell as pending update.

Internal identifier for the test number.
Normalized destination and country.
Attributed network and attribution method or date.
Authorization status for testing.
Availability of a controlled handset for independent observation.
Inventory validation date.

Design Cases That Change One Variable at a Time

A baseline case helps detect differences without confusing their causes. Define a legitimate, recognizable test message with no sensitive information. Then create controlled variations: change the encoding, length, sender, or one content element while keeping all other variables constant.

Encoding must be an explicit dimension. 3GPP TS 23.038 includes, among other options, the GSM 7-bit alphabet, 8-bit data, and 16-bit UCS2. It also states that, using the GSM 7-bit alphabet, a message can contain up to 160 characters. Length, characters used, and concatenation can change the technical handling of a message.

Include single-part cases and concatenated cases when relevant to planned traffic. Record the requested configuration and the observed result; do not infer the final encoding from the text visible on the phone.

Baseline case: short, identifiable text with no ambiguous characters.
Encoding variation: test the character set relevant to your traffic.
Length variation: one part and, where applicable, a concatenated message.
Sender variation: assess every sender that will be used.
Content variation: change only the element you want to investigate.
Time window: repeat during defined periods without changing other conditions.

What to Measure for Each Submission

The record for every submission should make it possible to reconstruct the full sequence. Retain the submission time, acceptance result, correlation identifiers returned by the interface, every callback or DLR event, and any independent observation on the handset.

Identifiers are essential. 3GPP TS 23.040 defines elements such as TP-Message-Reference and SMS-STATUS-REPORT, as well as associated timestamps and statuses. In an HTTP or SMPP integration, the identifier exposed by each system may differ; document how a client identifier correlates with the provider identifier, callback, and test observation.

Record temporary statuses and failures, not only a simplified final result. The SMS flow may include temporary unavailability, retries, or later outcomes. Removing these intermediate events makes it impossible to understand whether a difference is caused by acceptance, delivery, notification, or reporting delay.

Internal execution identifier and case version.
Submission timestamp and acceptance result.
Available correlation identifiers.
Route or configuration assessed.
Destination and sender exactly as submitted.
Encoding, length, and expected number of parts.
DLR or callback events: raw status, receipt time, and retained payload.
Handset observation: yes, no, or unavailable; observation time and method.

A Delivered DLR Is Not the Same as Delivery Observed on a Handset

A DLR is valuable technical evidence, but it must be interpreted at the correct level. TS 23.040 distinguishes SMS-SUBMIT, SMS-DELIVER, SMS-DELIVER-REPORT, and SMS-STATUS-REPORT. These mechanisms describe events, acknowledgments, and transfer results; they do not define a message-read event by the recipient.

Classify evidence to avoid excessive claims. Acceptance confirms that an interface accepted the submission under its conditions. A callback or DLR confirms that a report containing a status and timestamp was received. Independent observation on a controlled handset confirms that the message was seen on that device at that time, provided the correlation with the submission is reliable. No level, by itself, proves consent, identity, ownership of the number, or reading by an end user.

When no handset observation exists, report the result as a reported status, not as verified receipt. When it does exist, retain the verification method and the identifier linking the observation to the specific submission.

Level 1: submission acceptance by the interface.
Level 2: DLR or callback received and retained.
Level 3: delivery observed on a controlled test handset.
Do not equate observed delivery with human reading, consent, or identity.
Do not present a DLR as a universal delivery guarantee.

FAQ

Frequently asked questions

How many sends does an A2P SMS test matrix need?

There is no universal number that makes a sample conclusive. Define it based on operational risk, destinations, networks, message type, and the variability you need to observe. The important point is to retain the sample size for each cell and not compare as equivalent cells with different coverage or conditions.

Does a delivered DLR prove that the SMS reached the phone?

Not on its own. A DLR is a technical status report and should be retained as evidence at that level. Delivery observed on a controlled test handset is different evidence. Neither one, by itself, proves that a person read the message.

Should HLR Lookup be included in the matrix?

It can be recorded as a source of context when its use is authorized, but it should not be treated as proof of consent, identity, number ownership, actual route, or delivery. Mobile number portability can separate the number range from the current subscriber network.

Why should characters and long messages be tested?

Because encoding and alphabet are explicit technical variables. TS 23.038 includes GSM 7-bit, 8-bit data, and 16-bit UCS2, and length may require concatenation. A result with short text does not automatically validate different content or a different length.