A2P SMS Route Eligibility: Filters Before Comparing Quality
Define verifiable filters for destination, traffic, sender, and content. Separate known incompatibilities from outstanding questions, and compare quality only among eligible options.
Eligibility, compliance, and quality are not the same
Operational eligibility answers a specific question: does the route documentation describe conditions that are compatible with this request? Compliance means checking that the intended use follows the applicable rules and relevant market requirements. Observed quality describes a route’s behavior under test or usage conditions and over a defined period.
These assessments are related, but none replaces the others. A route being listed as available does not prove that the use case complies with local rules; being eligible according to the information on record does not guarantee delivery. And a favorable quality observation does not remove an incompatibility involving the sender, content, or destination.
- Eligibility: documented compatibility between the request and the route conditions.
- Compliance: review of the obligations that apply to the traffic and market.
- Quality: assessment based on observed evidence, with its scope and limitations identified.
First, define the request you want to route
Before checking routes, record the attributes needed to assess the use case. If a detail is unconfirmed, mark it as pending rather than filling the gap with an assumption. The assessment is useful only if it describes the traffic you actually intend to send.
At a minimum, specify the destination, traffic category, intended sender, and relevant content or template. Add timing or capacity requirements when they are relevant and documented. For marketing, OTP, or transactional messages, classify the use according to the applicable conditions; do not treat an internal label as proof of authorization.
- Destination: country, market, or other scope required by the route documentation.
- Traffic: the purpose and category that apply to the actual message.
- Sender: the intended value and type, according to the documented conditions.
- Content: a template or description sufficient to check any stated restrictions.
- Operational requirements: the requested time window or capacity, if relevant and verifiable.
Turn documentation into verifiable statuses
Use clear statuses for each route condition: supported, not supported, or unverified. “Supported” means the documentation reviewed covers the attribute and considers it compatible; it is not a delivery guarantee or universal regulatory approval. “Not supported” identifies an explicit incompatibility. “Unverified” means information is missing, its current validity has not been confirmed, or its scope does not match the request.
Do not treat silence in the documentation as authorization. For example, if a route profile describes destinations only, do not conclude that it also supports the intended sender or content. Track each condition separately so that a broad statement such as “route available” does not conceal gaps.
- Supported: the condition is documented and compatible with the case being assessed.
- Not supported: a documented incompatibility; exclude the route for this case.
- Unverified: there is not enough evidence; request confirmation or keep the case under review.
Apply filters before comparing quality
Assess eligibility conditions first. Exclude routes with known incompatibilities. If a required attribute is unverified, do not present the route as eligible: keep it under review and request the relevant clarification. Only then compare quality evidence among options that remain compatible with the request.
The comparison should state what was observed and within what scope: destination, available operator or coverage scope, period, traffic type, and test conditions. Consider only dimensions that were actually measured, such as observed delivery, DLR consistency, latency, or availability. Do not invent missing metrics or turn test results into a guaranteed prediction for every message.
- Step 1: Define the request attributes.
- Step 2: Exclude documented incompatibilities.
- Step 3: Put unverified conditions under review.
- Step 4: Compare quality evidence only among eligible options.
- Step 5: Record uncertainties and the limits of the comparison.
Record the decision and its traceability
A reproducible decision needs more than a final status. Save the source consulted, the review date, and the scope covered by each condition—for example, which destination or traffic type it applies to. Also record the specific reason for inclusion, exclusion, or review, and who is responsible for resolving any outstanding question.
Traceability helps prevent a condition for one market from being mistakenly applied to another, or an old review from being treated as current without confirmation. If the documentation changes, update the record and reassess affected requests.
- Route and version or reference for the condition consulted, if available.
- Source, review date, and scope covered.
- Status for each attribute: supported, not supported, or unverified.
- Decision and specific reason, with an owner assigned to outstanding checks.
Reassess when the traffic changes
Eligibility applies to a specific combination of destination, category, sender, content, and operational requirements. If a template changes, the sender is replaced, the destination changes, or the traffic is reclassified, run the filters again and retain the decision history.
Do not relax controls or change the classification to force use of a route. If there is not enough evidence or the documentation indicates an incompatibility, keep the case under review or exclude it until the issue is resolved and documented.
- Identify which attribute changed and which routes may be affected.
- Repeat the eligibility assessment for the new request.
- Update the source and date for confirmed conditions.
- Keep the previous decision in the history, with its scope and rationale.
Example matrix and limits on interpretation
The table below shows a decision structure, not real route data. Replace the fields with verifiable documentation. If a required attribute is unverified, the prudent choice is to pause the quality comparison for that case until the necessary information is obtained.
A condition stated by a route does not guarantee that every message will arrive. Likewise, a received DLR is a status report, not independent proof that a person saw the message or that it was displayed correctly on the device. Interpret each indicator according to its definition, source, and limitations.
- Example: destination supported, sender unverified, content pending → keep under review.
- Example: destination not supported for the request → exclude, even if other metrics appear favorable.
- Example: required conditions confirmed and no incompatibilities found → compare the available evidence without promising delivery.
Verify requirements using relevant sources
Route conditions help assess operational compatibility, but they do not replace a review of the rules that apply in each market. Consult official technical documentation, regulators, and industry organizations; confirm that the source covers the specific destination, traffic, and attribute being assessed.
General specification pages or resource hubs can help guide research, but they do not justify attributing specific requirements when they do not provide relevant, verifiable content. If a local obligation is unclear, seek qualified advice and record what remains unresolved.
- 3GPP: https://www.3gpp.org/specifications-technologies/specifications-by-series
- ITU-T, Recommendation E.164: https://www.itu.int/rec/T-REC-E.164/
- GSMA, network resources: https://www.gsma.com/solutions-and-impact/technologies/networks/
Frequently asked questions
Does an eligible route guarantee SMS delivery?
No. Eligibility indicates that the documented conditions appear compatible with the request being assessed. It does not guarantee delivery or replace a review of applicable regulations.
What should I do if the documentation does not mention the sender or content?
Mark that attribute as unverified. Request confirmation or keep the case under review; do not interpret missing information as authorization.
Should I compare quality while an eligibility condition is pending?
Resolve the uncertainty first or keep the route under review. A quality comparison cannot correct a known incompatibility or provide missing information.
Does a DLR confirm that the recipient received the message on their device?
Not by itself. It is a status report and should be interpreted according to its definition and source; it is not independent proof of successful receipt on the device.
When should a route be reassessed?
When a relevant request attribute changes, such as the destination, traffic category, sender, content, or a timing or capacity requirement.
Sources consulted
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA