Seed Numbers in A2P SMS: Controlled Testing to Assess Routes Prudently
How to design a seed number program to observe acceptance, DLRs, latency, and A2P SMS route behavior without mistaking a synthetic test for a delivery guarantee.
What a seed number is and what it represents
A seed number is a destination number controlled by the team or used with demonstrable authorization to run messaging tests under defined conditions. In an A2P SMS program, it is assigned to a specific combination of country, mobile network, device, sender type, and legitimate use case.
The number should be stored or normalized in E.164 format to provide a consistent international reference for the destination. An inventory should also be maintained to identify the expected network, the number's operational status, ownership or authorization, consent status where applicable, and change history.
A seed number is not equivalent to a representative sample of end users. It allows the observation of a controlled combination of variables; it does not demonstrate how all handsets, subscribers, or network conditions will respond. Its primary value is repeatability: identifying changes, inconsistencies, and degradation under the conditions defined by the team.
- Use it as an observability tool for a specific route.
- Do not present it as a commercial delivery guarantee.
- Keep the API result, DLR, and device observation separate.
- Document any change to the SIM, device, operator, operational location, or testing policy.
Operational questions that controlled testing can answer
A well-instrumented test can verify whether the platform accepts a sending request, assigns a traceable identifier, receives status updates, and provides consistency across the available events. It can also measure observed intervals between test creation, submission acceptance, status changes, and independently recorded evidence on the device.
Status terminology must be interpreted precisely. Messaging platforms commonly distinguish stages such as queued, sent, accepted by an upstream carrier, confirmed delivered, and undelivered. API acceptance of a request, or assignment of a message identifier, does not by itself demonstrate that the destination handset received the SMS.
When the team has access to the seed device, it can record an independent observation of receipt. In certain cases, a verifiable subsequent signal linked to the message, such as use of an OTP code in a controlled test environment, can also provide additional evidence. This evidence must be labeled as distinct from the DLR.
- Was the request accepted and associated with a unique identifier?
- Were status events received, and are they consistent with the expected flow?
- How much time elapsed between the observed events?
- Did the message appear on the controlled device?
- Did the sender and content behave as expected for that specific combination?
- Was the test available during the scheduled period?
What seed numbers cannot prove on their own
A positive result from a seed number does not prove the overall deliverability of a route. Delivery conditions can vary due to carrier filtering, handset availability, device behavior, sender type, content, sending time, and traffic conditions not present in the test.
An undelivered DLR should not automatically be attributed to a route issue. It may result from carrier content filtering or the unavailability of the destination handset, among other factors. The investigation should start from the available evidence and avoid causal conclusions that the test cannot support.
A late-arriving DLR requires particularly careful treatment. As an example of a provider-documented window, AWS warns that carrier-generated DLRs may be received up to 72 hours later. Therefore, the time at which the platform receives a DLR should not be used as proof that the outbound submission was delayed for that same period. If no final event arrives, the result should remain unknown or pending in accordance with the program's documented policy.
- Do not infer handset receipt solely from API acceptance.
- Do not equate a DLR with an independent observation when none exists.
- Do not turn an isolated test into a conclusion about an entire network or country.
- Do not interpret delayed DLR arrival as delivery delay without additional evidence.
- Do not attribute all failures to the route without reviewing content, handset, and test context.
Design a minimal and explicit seed number matrix
The matrix should be built around the decisions the team needs to make. Rather than collecting numbers without structure, define each cell as a combination of destination, expected mobile network, sender type, content profile, and legitimate use case. Add a version identifier so that the active configuration for every test can be identified.
Start with coverage that is operationally maintainable. Expand the matrix when there is a specific hypothesis: a difference between senders, uncertainty about an operator, a behavior change caused by encoding, or an incident that requires comparison. Expansion should increase the test's ability to distinguish outcomes, not merely increase message volume.
The expected network in the inventory should be treated as a verifiable attribute subject to review, not as a permanent property inferred from the prefix alone.
- Country or destination normalized in E.164 format.
- Expected mobile network and date of last verification.
- Seed number and operational status.
- Sender type used in the test.
- Content profile and expected encoding.
- Legitimate use case: test OTP, test transactional alert, or another authorized flow.
- Device and independent observation method, where available.
- Matrix version and person responsible for its maintenance.
Select and maintain seed numbers with authorization controls
Only add numbers owned by the team or supported by demonstrable authorization to participate in the program. If messages are commercial in nature or subject to local consent, identification, and opt-out requirements, the program must retain the applicable evidence. Responsibility for demonstrating consent may rest with the sender depending on the jurisdiction.
At a minimum, the inventory should record the number identifier, authorization basis, date and method of collection where applicable, consent status, onboarding date, internal owner, device status, and date of the latest verification. It should also retain a history of changes and removals.
Set replacement rules. A number should be reviewed or replaced if access to the device is lost, authorization is no longer valid, its operational status changes, it produces recurring observations that cannot be interpreted, or it no longer represents the matrix cell for which it was added. Replacement must not erase the previous number's history.
- Restrict access to the inventory and seed devices.
- Separate use authorization, technical status, and test results.
- Record removals, revocations, and resulting actions.
- Periodically review device availability and authorization validity.
- Maintain traceability between a historical test and the inventory version used.
Design test messages that make results interpretable
The test message should be recognizable, legitimate, and stable enough to support comparison between runs. Include a non-sensitive test identifier where needed to correlate device observation with the sending record. Avoid content containing unnecessary personal data, real credentials, or information that is not essential to the technical objective.
Record the encoding and body length. These are relevant variables because the number of transmitted segments depends on encoding and length. As a common technical reference, GSM-7 text exceeding 160 characters and UCS-2 text exceeding 70 characters are segmented for attempted reassembly. Provider documentation warns that not all carriers and handsets support this reassembly consistently.
Test the profiles you need to compare separately. For example, a single-segment GSM-7 message, an authorized UCS-2 case, and a multipart case if it is relevant to the legitimate traffic operated by the team. Do not change sender, content, encoding, and route at the same time if the goal is to identify the cause of a difference.
- Internal test identifier containing no personal data.
- Stable text that is easy to recognize on the device.
- Expected encoding and message length.
- Expected and observed segment count where available.
- Authorized sender type and value.
- Technical purpose of the test and variables kept constant.
- Prohibition on using secrets, real OTPs, or sensitive data in test content.
Record events, evidence, and timing for every message
Each send should be reconstructable from beginning to end. Retain an internal execution identifier and the identifier returned by the platform or provider where available. Record timestamps for creation, sending, status updates, DLR receipt, and independent device observation.
Differentiate the time measured at each stage. The interval between creation and an acceptance or sending event describes one part of the chain. A timestamp received in a DLR may reflect a date supplied by the carrier, while the platform's receipt of the DLR reflects a different moment. Do not merge these fields into a single latency metric without preserving their origin.
Store error codes, raw status where available, status changes, and observation evidence. If the device displays the message, record the verification method and observation time. If a verifiable subsequent signal is used, record what signal it was, how it was linked to the message, and what limitations it has.
- Internal test ID and external message ID.
- Route or configuration version, if internally available.
- Seed destination, matrix cell, and inventory version.
- Content or content fingerprint permitted by the privacy policy.
- Encoding, length, and segments.
- Sender and use case.
- Received statuses, error codes, and raw DLR where applicable.
- Timestamps with time zone and the source of each timestamp clearly distinguished. Device observation may be classified as yes, no, unavailable, or unverifiable. Also record the final classified result and the evidence level.
Handle late DLRs, duplicates, and contradictions without overstating evidence
Define an internal state machine before running tests at scale. It must accommodate late events, repeated events, and status changes that arrive out of the expected order. Preserve the complete history; do not replace an earlier event without retaining a record of the received sequence.
If a final DLR arrives after the operational observation period, record it as a late event and update the classification according to policy, while preserving the initial assessment and its timestamps. If duplicate DLRs appear, retain them for audit purposes and deduplicate only in the analytics layer through explicit rules.
When a DLR and device observation do not match, do not force an explanation. Classify the case as inconsistent, review identifier correlation, device clock, content, and observation method. If reliable correspondence cannot be established, do not claim independent receipt or route failure.
- Pending: no final event exists yet within the defined window.
- Final reported: a DLR or final status has been received.
- Observed on device: documented independent evidence exists.
- Inconsistent: the available sources do not allow a single interpretation.
- Unknown: insufficient final evidence is available after the applicable window.
- Late: the event arrived after the operational window and must be retained separately.
Frequently asked questions
Does a delivered DLR prove that the user saw the SMS?
Not necessarily. A DLR is a status signal received through the messaging chain. It should be distinguished from an independent observation on the device or another verifiable subsequent signal linked to the message. The available evidence and its source should be recorded separately.
How many seed numbers do I need per operator?
There is no universally verifiable number. Define the quantity according to the combinations you need to observe: destination, expected mobile network, sender, content, and legitimate use case. Start with a maintainable matrix and expand it when an operational hypothesis requires greater discrimination.
Can a seed test measure actual delivery latency?
It can measure observed intervals between events, but the source of every timestamp must be identified. A DLR arriving at the platform does not by itself prove the delivery time at the handset or a delay in outbound delivery.
Why should I record encoding and segments?
Because GSM-7 and UCS-2 have different segmentation thresholds, and long messages may require reassembly. Provider documentation warns that this behavior is not supported consistently by all carriers and handsets.
Does an HLR Lookup confirm that a number can receive an SMS?
No. An HLR Lookup does not demonstrate consent, identity, ownership, or guaranteed delivery. It should be treated as a source of information separate from use authorization, sending events, and receipt observation.
What should trigger a route investigation?
A repeated discrepancy against a defined baseline, loss of consistency between DLRs and independent observation, persistent changes by matrix cell, or degradation that cannot be explained by device availability, content, or a documented configuration change. Before attributing a cause to the route, repeat controlled tests and expand the sample in a targeted way.
Sources consulted
- E.164: The international public telecommunication numbering planInternational Telecommunication Union (ITU)
- AWS End User Messaging SMS User GuideAmazon Web Services
- Messages resourceTwilio
- Frequently Asked Questions about Canada's Anti-Spam LegislationCanadian Radio-television and Telecommunications Commission (CRTC)
- From Canada’s Anti-Spam Legislation (CASL) Guidance on Implied ConsentCanadian Radio-television and Telecommunications Commission (CRTC)