A2P SMS Message Validity: How to Set Expiration, Retries, and Final States Without Harming the User

SMS validity is not the same as content expiry

In SMS, the validity period describes how long a message should be retained for delivery attempts before it expires. It is a transport and network-retention attribute; it does not by itself determine whether the content remains appropriate for the recipient.

This distinction is essential in A2P traffic. An SMS may remain technically deliverable even though the OTP code is no longer acceptable, an alert has already been resolved, or a promotion has lost its relevance. Keeping the message queued in these situations can create confusion, support requests, and poor security decisions.

The operating policy should not be limited to asking whether the provider or network can still deliver the SMS. It must answer an earlier question: “Is the requested action still correct, safe, and useful if the recipient receives this message now?”

• Technical validity: the maximum retention and delivery-attempt time in the platform, provider, or network.
• Content expiry: the point after which a code, link, or included data is no longer valid.
• Utility window: the period during which receiving the communication still enables an action that is relevant to the recipient.

Use an absolute utility deadline as a control decision

The sending platform should calculate an absolute utility deadline when the operation is created. That point in time should travel with the message through queueing, TPS throttling, connectivity selection, sending, and retries.

Before each relevant transition, check whether enough time remains for the message to retain meaning. If internal waiting, sending limits, or a new retry have already consumed that window, the right decision is usually not to send. This decision should not be delegated solely to a third party’s configurable validity period, because that value may apply only to retention time within its own platform.

The control should run before work is accepted into an outbound queue, before it is submitted to a provider, and before every retry is scheduled. This prevents an outdated message from being sent simply because there is still technical capacity to transport it.

• Define a utility expiry time for every operation.
• Reserve time budget for the internal queue, TPS throttling, provider acceptance, and retries.
• Suppress before sending if the remaining budget no longer allows useful delivery.
• Keep platform expiry as an additional safeguard, not as the only business control.

Define different policies for OTPs, transactional messages, and consented campaigns

There is no single suitable timeframe for every traffic type. The policy should derive from the expected action, the consequences of late delivery, and whether the message can be replaced with updated information. The timeframe should be documented as a product and operational rule, not as an assumption about route latency.

For OTPs, the main reference is the validity of the secret and the authentication context. For transactional communications, what matters is whether the event is still open or whether a more recent status exists. For consented campaigns, commercial timeliness and avoiding an unexpected late repeat are especially important.

Specific timeframes should be approved by the teams responsible for the flow, security, privacy or data protection, compliance, and applicable local regulatory or contractual requirements. The platform should implement these timeframes in a verifiable way and make it possible to identify which rule was applied to each operation.

• OTPs and recovery: a short window aligned with secret acceptance; suppress if it expires before sending.
• Transactional alerts: send while the event remains relevant; replace with an update if the status has changed.
• Confirmations: do not resend an old message if a later confirmation better represents the current state.
• Consented campaigns: do not automatically retry when the offer date, time slot, or opportunity has already passed.

OTPs: coordinate transport and the secret, but do not confuse them

An OTP sent by SMS must be single-use within its validity period. The verifier must reject it when it expires, even if the SMS is delivered later. Reaching the device does not extend the validity of the code or reactivate the authentication operation.

For the out-of-band authentication described in its guidance, NIST states that it must be completed within a ten-minute window and that a particular secret must be accepted only once during its validity period. This reference does not remove the need for a queue-specific policy: the sender must prevent a code that can no longer be useful from continuing toward delivery.

Failed attempts should also be limited when the secret has fewer than 64 bits. Issuing a new secret must not reset that counter. This rule belongs to the verifier and cannot be inferred from the SMS transport status.

SMS may be used as an out-of-band channel, but alternatives should be offered to people who cannot use PSTN. Risk teams should also consider signals relevant to the use case, such as SIM changes, porting, or device changes.

• Assign the OTP a verifiable expiry in the verifier.
• Set a sending utility expiry that prevents already expired or nearly expired codes from being dispatched.
• Do not treat a DLR as evidence that the code was seen, entered, or accepted.
• Issue a new operation only after a new request or within a controlled flow.
• Do not reset failed-attempt controls simply by generating a new code.

Coordinate queues, TPS, and retries with the time remaining

A queue can turn a message that was valid when created into a useless message before it is sent. This happens when work accumulates, TPS limits apply, an upstream response is awaited, or a retry is scheduled without checking the utility deadline.

Scheduling should be based on time remaining, not just age or priority. A message with a short window needs an early decision: send it if it can be sent within policy, prioritize it where legitimate and safe, or finalize it before consuming more resources. It is not appropriate to retain it indefinitely merely because it has not yet received a final response.

The SMS specification contemplates retries after temporary conditions as well as a single-attempt mode. The choice should not be automatic for every case. Retrying may be reasonable when the information remains current and enough time is available; it may be harmful when content depends on a rapidly changing status.

• Calculate time remaining before queueing and before every retry.
• Avoid scheduling a retry whose expected execution falls after the utility deadline.
• Apply retries only for transient conditions and under an explicit policy for each use case.
• Consider a single attempt when the risk of late delivery outweighs the benefit of persisting.
• Stop retries when the operation is cancelled, an update replaces the message, or utility expires.

Interpret DLRs as transport signals, not proof of use

Delivery states are necessary for operations, but they must not be interpreted beyond their scope. The labels, confirmation source, and exact meaning of each state depend on the integration, provider, operator, and route. They should be interpreted according to the applicable technical and contractual documentation.

For example, some integrations use labels such as “queued,” “sent,” “delivered,” “undelivered,” or “failed.” In that taxonomy, “queued” may indicate that the request was accepted and is awaiting sending; “sent” may indicate acceptance by an upstream operator; and “delivered” may reflect a confirmation available within the transport chain. The scope and reliability of these signals vary by integration, operator, and route.

A delivered DLR does not prove that a person read, understood, or used the SMS. SMS has no equivalent read event that would make delivery proof of consumption. Nor should a delivered DLR be assumed to universally guarantee that the content was visible on the device or produced the expected action.

For this reason, the system must separate the external transport state from the business outcome. For an OTP, for example, the relevant events include at least reported delivery, the validation attempt, and acceptance or rejection of the secret. None should replace the others.

• Examples of integration states: “queued” may mean the request was accepted and is awaiting sending in the platform reporting the state.
• “Sent” may indicate acceptance by an upstream operator or provider, depending on the documented semantics of the integration.
• “Delivered” may represent a delivery confirmation available from the transport chain; it does not mean the message was read or used.
• “Undelivered” or “failed” may indicate non-delivery or inability to send; retain the available reason according to the integration.
• Business outcome: an independent status, such as code accepted, operation completed, alert acknowledged, or action not performed.

When utility expires, finalize the operation with an explicit reason

A pending message whose utility has expired should not remain ambiguously queued or be classified only by an external technical state. The platform needs an internal final state that explains the decision, such as “suppressed due to utility expiry,” together with the time and rule that triggered it.

The next action depends on the traffic type. For OTPs or recovery, suppress the pending message and do not extend the life of the secret. For an alert that remains relevant, generate a current update instead of persisting with the original text. For a consented campaign, avoid automatically resending content whose opportunity has already ended.

If the platform has already handed the message to a provider or the network, it may not be able to guarantee an effective cancellation. That is why suppression before sending is the main control. After handoff, record the known state, preserve the uncertainty, and prevent a later DLR from retroactively changing the business decision.

• Cancel: if the integration and work state still allow withdrawal before sending.
• Suppress: finalize in the platform’s own queue due to expired utility, without sending it to the next hop.
• Reissue: create a new communication only if the use case still justifies it and with updated content.
• Escalate: investigate backlogs, unusual retries, inconsistent DLRs, or repeated expirations by destination, route, or provider.

Record the minimum data needed to audit every decision

The policy is verifiable only if every message leaves enough chronology to reconstruct what was decided and why. Delivery callbacks are asynchronous; therefore, the arrival order of a DLR must not replace timestamps for creation, acceptance, sending, and expiry.

Use a stable correlation identifier to link the business operation with every transport attempt. Keep the internal identifier, provider identifiers where available, and attempt identifiers separate. This makes it possible to analyze duplicates, retries, suppressions, and late events without confusing distinct operations.

For operational auditing, use records with integrity controls, change traceability, defined retention, and restricted access. Avoid storing more personal content than necessary, and apply applicable privacy, data protection, retention, correction, and deletion requirements. What matters is being able to demonstrate the applied policy, the sequence of states, and the reason for the final decision.

• Operation correlation identifier and use-case type.
• Internal message identifier, provider identifiers, and identifiers for each attempt where available.
• Creation, acceptance, queue entry and exit, sending, and receipt time for every DLR.
• Configured technical expiry, content expiry, and utility deadline.
• Reported technical status, internal final status, and timestamp for every transition.
• Retry, cancellation, or suppression decision, including its reason and the applied rule.
• Business outcome where applicable, without inferring it from a DLR.