Quarantining Numbers for A2P SMS: An Operational Guide
Design a reviewable process for placing destinations under observation, temporarily pausing traffic, and deciding when to restore it—without turning an isolated signal into a permanent block.
What Quarantine Does—and Does Not—Address
A quarantine is a temporary operational control for limiting or pausing messages to a destination while a risk or failure signal is reviewed. Its purpose is to prevent a problem from recurring while preserving a way to correct false positives and restore legitimate traffic.
This is not the same as a consent-based suppression list. If a person has opted out or there is no valid basis for sending them messages, the destination must be managed in accordance with applicable consent and compliance rules. A technical review does not replace that obligation.
There are no universal failure thresholds or standard quarantine duration that can be recommended for every sender, route, and destination. The available evidence does not support setting specific figures. Each organization should define criteria suited to its data, risks, obligations, and operational agreements, and document why it applies them.
- Use quarantine to manage a reviewable operational risk, not to conceal the cause of the problem.
- Keep technical reasons, fraud signals, and consent-related decisions separate.
- When the evidence is incomplete, prefer a temporary, narrowly scoped restriction to a permanent block.
Signals That May Trigger a Review
A signal is a reason to begin a review, not necessarily to decide its outcome. Possible signals include a pattern of repeated errors, complaints received through legitimate channels, status changes reported by available systems, or internal alerts. Before taking action, verify that the event corresponds to the correct destination and time period.
A DLR is a status report associated with a message. It should not be presented as independent proof that the message reached a device or as a conclusive explanation of why a failure occurred. Interpret each status according to the documentation for the platform or route that generated it, and bear in mind that reports may be incomplete or uncertain.
Compare signals relating to the same destination and context: sender, traffic type, route, period, and previous behavior. A concentration of events may justify a priority review, but on its own it does not prove that a number is fraudulent, invalid, or unrelated to a legitimate user.
- Check that the issue is not a formatting error or a mismatch between the message, destination, and result.
- Distinguish sending data, DLR reports, and alerts from number-intelligence systems.
- Do not treat a single complaint, an isolated DLR, or a one-off failure as a definitive conclusion.
What HLR Lookup Can Contribute
HLR Lookup is a number-intelligence query offered in certain SMS contexts. Its availability and the fields it returns depend on the service used; the information provided here does not specify which attributes will be available in any given query.
Do not treat an HLR query as proof of consent, identity, number ownership, or guaranteed message delivery. Nor does it replace validation of sending logs, interpretation of DLRs, or review of complaints.
Before incorporating this type of query into your workflow, confirm what data the specific service provides, when it is updated, what limitations it states, and what uses are permitted. If the result cannot be interpreted with sufficient certainty, record that uncertainty and avoid using it as the sole basis for a suspension.
- Document the source and date of the query.
- Treat the result as a supporting signal, not a verdict on identity, permission, or delivery.
- Limit access and use to what is necessary for the review.
Clear Operational States
Define states that show what can happen to a destination and who needs to act. One possible scheme is active, under observation, quarantined, pending review, and reactivated. The names matter less than having clear rules, assigned owners, and recorded transitions.
While under observation, traffic may continue under the controls established by the organization. In quarantine, the organization may pause or limit affected traffic while reviewing the case. Do not assume that a particular platform implementation supports restrictions by destination, route, or message type; first confirm your systems’ actual capabilities.
Reactivation should not erase the history. Record who made the decision, what evidence was reviewed, and what follow-up control will apply, if any.
- Active: no operational restriction is currently in effect.
- Under observation: a signal requires monitoring, but there is no conclusion that the destination is illegitimate.
- Quarantined: a temporary restriction is in place with a defined reason and scope.
- Pending review: the available evidence is insufficient to close the case.
- Reactivated: the restriction was lifted following a documented review.
Deciding Whether to Quarantine and Defining the Scope
No error or complaint threshold is supported here as a universal rule. Set internal criteria for when a combination of signals requires review and when it justifies a temporary restriction. Consider recurrence, evidence quality, potential impact, and whether the event may have a different technical or contextual explanation.
Apply the narrowest control that reduces the identified risk. If the signal concerns one specific destination, do not automatically extend the measure to other numbers, senders, or routes without supporting evidence. When the case is unclear, observation or a priority review may be more proportionate than a broad block.
Before activating the measure, check that the restriction will not unduly prevent legitimate, critical communications and that an appropriate review channel is available. Applicable obligations and service commitments should form part of the decision.
- Identify the signal, its quality, and the context in which it occurred.
- Define which traffic is restricted, how long the case will be reviewed, and who is responsible.
- Avoid irreversible decisions based on a single uncorroborated event.
- Provide a way to correct errors and request a review.
Review and Decision Workflow
First, validate the destination’s format and context. ITU-T E.164 addresses the international public numbering plan; it may serve as a reference for numbering questions, but it does not by itself establish an A2P quarantine procedure. Also verify that the records being reviewed belong to the same destination and that events have not been mixed together.
Next, gather the available evidence: sending attempts, DLR statuses with their source, relevant complaints, and internal alerts. Record what is known and what cannot be concluded. If HLR Lookup is used, note the provider or system queried and the date, without attributing undocumented capabilities to it.
Finally, choose whether to close the alert, continue observation, apply a narrowly scoped quarantine, or request further review. Document the reason for the decision and the evidence supporting it. If the cause cannot be determined, record the uncertainty rather than assigning an unverified explanation.
- Validate the format, event associations, and time period.
- Separate direct observations from interpretations.
- Consult only relevant, documented sources.
- Record the decision, owner, scope, and next review point.
Reactivation, Temporary Controls, and False Positives
Reactivate when the review finds that the restriction is no longer justified or that the signal has been explained in a way consistent with legitimate traffic, in accordance with internal rules. The information provided does not establish a fixed timeframe or a single test for authorizing reactivation.
If uncertainty remains, the case may stay pending review or be subject to a more limited temporary control, provided that this is feasible on the platform and proportionate to the risk. Do not let a quarantine continue indefinitely through inertia: specify who will review the case and when it will be reassessed.
When a false positive is confirmed, correct the operational status and retain a record of the correction. Also check whether other destinations were affected by the same rule; do not automatically broaden the block in response.
- State what evidence supports lifting or maintaining the restriction.
- Assign a person or team to the next review.
- Remove measures that are no longer needed and record the date.
- Keep any suppression required by consent or compliance separate.
Traceability and Limited Access
A useful record makes it possible to reconstruct the decision without collecting unnecessary information. Include the reason, date, observed signal, sources consulted, scope of the measure, responsible person or team, planned duration, and review outcome.
Limit access to those who need to manage the case, and follow the organization’s data retention and protection policies. Do not include message content or other personal data unless it is necessary to justify and resolve the review.
Periodically check whether the rules are generating incorrect blocks or leaving cases open without an owner. The goal is to improve decision quality, not to turn internal metrics into guarantees of delivery or legitimacy.
- Reason and specific signal.
- Start date, duration, or next review date.
- Evidence source and known limitations.
- Quarantine scope and owner.
- Final decision, outcome, and record of corrections.
Frequently asked questions
How many failures should trigger a quarantine?
The available information does not support a universal threshold. Define internal criteria based on context, signal quality, and potential impact; document the rule and avoid treating a single failure as conclusive proof.
Does a DLR confirm that an SMS reached the phone?
Not necessarily. A DLR is a status report from the platform or route that generates it and should not automatically be confused with independent verification of receipt on the device.
Does HLR Lookup prove that the number belongs to the recipient or that they gave consent?
No. Do not use HLR Lookup as proof of identity, ownership, consent, or guaranteed delivery. Confirm the documented scope of the specific service and consider its results only within those limits.
How long should a quarantine last?
The available information does not establish a standard duration. Set an expiry or review date under your internal rules, assign an owner, and avoid maintaining a restriction indefinitely without reassessment.
Does quarantine replace a suppression list for opt-outs or lack of consent?
No. Quarantine is an operational control for reviewing risks or failures. Opt-outs and other consent obligations must be managed separately in accordance with applicable rules.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- SMS concepts for Azure Communication ServicesMicrosoft Learn