Requalifying A2P SMS Routes: When to Retest and What Evidence to Require
An operational guide to reviewing changes, designing comparable tests, interpreting DLRs cautiously, and documenting decisions about A2P SMS routes without mistaking signals for delivery guarantees.
What It Means to Requalify a Route
Requalifying a route means reassessing whether it remains suitable for a defined traffic scope based on changes or signals that justify new tests. It is not the same as initial qualification, which establishes a baseline for an intended use. Nor is it the same as a routine periodic review, which may check indicators even when no specific change has occurred.
Requalification does not certify that all future messages will be delivered. Its conclusion should describe the tested scope, period, conditions, and limitations of the evidence. The available evidence does not establish a universal procedure or technical thresholds that apply to every route; each organization should define internal, verifiable criteria.
- Qualification: an initial assessment for a stated use case and set of conditions.
- Periodic review: planned monitoring of a route that has already been approved.
- Requalification: an additional assessment when a change or signal raises doubt about whether the approval remains valid.
What Can Trigger a New Assessment
Use a log of changes and signals to decide whether requalification is appropriate. Do not treat a provider’s statement as proof that a change occurred exactly as described, or an observed variation as automatic identification of its cause.
Events worth reviewing include declared changes to the intermediary chain, connectivity, sender configuration, or applicable restrictions. Observed variations in availability, latency, DLR consistency, or sender and content behavior may also justify an assessment. These are categories for organizing a review, not a regulatory checklist or a diagnosis in themselves.
- Record what changed, who reported it, when it took effect, and which destinations or traffic may be affected.
- Compare the observed signal with your baseline across equivalent segments, taking missing data into account.
- If the cause is uncertain, describe that uncertainty and avoid attributing it to a specific link without evidence.
Define the Scope Before Testing
Specify the conclusion you are seeking and the legitimate use it applies to—for example, transactional traffic, OTP, or marketing with the applicable permissions and requirements. Define destinations, operators where they can be identified, traffic types, senders, and relevant conditions. Do not generalize results from one segment to others that were not assessed.
If you cannot reliably identify the destination operator or separate traffic categories, state that limitation. Available institutional references, such as 3GPP specifications, GSMA network resources, and ITU-T Recommendation E.164, do not provide a specific requalification procedure or universal acceptance criteria here.
- Define the destinations and the method used to classify them.
- Specify the senders, message types, and sending conditions included.
- Separate segments with different behavior or configurations.
- Note which dimensions are outside the assessment.
Design Comparable Tests and Set Criteria in Advance
Before sending test traffic, agree on the period, expected volume, test numbers, and controls. Use authorized numbers and recipients who have consented to participate; avoid unsolicited messages. Document whether tests run in parallel with a comparison route or against a historical baseline, and identify differences that could affect the comparison.
Set in advance which observations are acceptable for each segment and what conditions require expanding the sample, limiting use, or stopping the test. The available evidence provides no universal thresholds for volume, latency, or delivery: the organization should define values for the use case, with their justification and limitations stated explicitly.
- Keep the destination, content, sender, timing, and configuration as consistent as possible between the route under assessment and the control.
- Record both planned and completed volume, including failed attempts and attempts with no result.
- Define in advance how to handle duplicates, errors, late results, and missing data.
- Do not change criteria after seeing the results without documenting why.
Separate Declarations, Observations, and Evidence
Classify each data point by source. A provider declaration records what the provider says about the route; a platform log shows what the sending system observed; a network response or DLR provides a signal received by the system. These are distinct forms of evidence, and none should automatically be presented as independent confirmation of receipt on the phone.
Treat DLRs cautiously: record the status received, its source, and its timestamp, and distinguish a reported status from an independent check on the recipient’s device. Do not describe a DLR as proof that a message was read or effectively received on the handset without suitable additional verification. The supplied sources do not allow the fields, codes, or DLR semantics for each network to be specified.
- Retain the provider’s original statement and its date.
- Store sending logs, responses, DLRs, and timestamps as separate categories.
- Identify which evidence was corroborated by a test recipient and which was not.
- Explicitly flag discrepancies and unconfirmed results.
Interpret Results Without Overstating Their Scope
Analyze results by destination, operator where possible, sender, traffic type, and period. An aggregate figure can hide failures in a small segment or combine non-comparable conditions. Present the numerator, denominator, and missing data alongside each proportion, and explain how messages without a final status were counted.
A limited sample describes only the observations it includes; it does not prove how the entire route will behave in the future. State the sample size and composition, duration, relevant uncertainty, and any known bias. If independent checks are missing, explain which conclusions cannot be drawn.
- Compare equivalent segments and avoid extrapolating to untested destinations.
- Distinguish availability, latency, reported statuses, and verified receipt.
- Include inconclusive or missing results in the report, not only successful ones.
- Explain whether test conditions differ from normal traffic.
Decide the Route’s Status and Document Reversal Conditions
The decision should match the tested scope and the risk accepted by the organization. Keeping the route may be reasonable if the evidence meets the criteria agreed in advance; limiting, pausing, or retiring it are options when there are failures, material uncertainty, or signals requiring investigation. Do not turn this guide into an automatic rule: the available sources do not establish universal criteria for assigning these statuses.
Assign an owner, record the rationale, and specify conditions for reviewing or reversing the decision. If the route is limited, detail which traffic and destinations the limitation applies to. If it is paused or retired, document what evidence would allow a new assessment to be considered.
- Keep: approved scope and monitoring conditions documented.
- Limit: clearly defined authorized segments and exclusions.
- Pause: reason, owner, and condition for resuming the assessment.
- Retire: decision recorded and requirements for any future reconsideration.
Retain the Record and Set When the Conclusion Expires
The record should make it possible to reconstruct what was assessed, using which data, and why the decision was made. Include the configuration version, scope, period, methodology, original logs, segmented summary, missing data, provider statement, discrepancies, owner, and decision. Protect test data in accordance with applicable policies and obligations.
State which future changes require the conclusion to be reviewed—for example, declared changes to connectivity, the route chain, sender, or restrictions, as well as observed deviations from the baseline. Set a review date or condition based on risk and use, without presenting a fixed duration as a universal standard.
- Save the configuration version and test conditions.
- Link every conclusion to its supporting evidence and limitations.
- Define which events invalidate, narrow, or reopen the assessment.
- Review the decision if the scope, use, or observed signals change.
Frequently asked questions
Does requalification guarantee future SMS delivery?
No. Requalification assesses observations within a defined scope, period, and set of conditions. It does not guarantee future results or cover untested segments.
Does a DLR prove that a message reached the phone?
That should not be assumed. A DLR is a status reported by the relevant system; an appropriate independent check is needed to claim effective receipt on the device.
How many messages should be sent in a test?
The available evidence does not establish a universal volume. Set the sample size according to the use case and internal criteria, and record the sample, its composition, and its limitations.
Which changes require a route to be requalified?
The available sources do not support a universal list. Assess declared changes to connectivity, the route chain, sender, or restrictions, along with observed deviations; document why each event does or does not trigger a new assessment.
How can a provider’s claim be distinguished from independent evidence?
Record separately what the provider reports, what the platform observes, the responses or DLRs received, and any independent check at the recipient’s device. State the source of each data point and note any discrepancies.
Sources consulted
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA