A2P 10DLC for Transactional SMS Apps

What A2P 10DLC controls

A2P 10DLC is the US framework for application-to-person traffic sent from local ten-digit long-code numbers. It is meant to give carriers more information about the business sending the message, the campaign use case, and the phone numbers associated with that campaign.

For transactional apps, this often includes OTPs, account notifications, delivery updates, customer care, and security alerts. The key operational point is simple: US long-code production traffic should not be treated like unregistered test traffic. Brand, campaign, number, template, consent, and throughput details have to line up.

10DLC is not only a form. It is a carrier-facing description of who is sending, why they are sending, and what recipients should expect.

The registration data you should prepare

Do not mix unrelated content under one vague campaign. A password reset code and a promotional coupon may both be SMS, but they have different user expectations and review risk. Transactional content should stay transactional.

Throughput and filtering are campaign outcomes

Registration does not make every number unlimited. Throughput can depend on brand vetting, campaign type, carrier rules, provider settings, and the number association process. Filtering also depends on whether traffic matches the registered use case and whether content looks abusive, misleading, or unexpected.

• Use one campaign for one coherent use case instead of bundling unrelated traffic.
• Keep template examples close to real production copy.
• Avoid link shorteners, misleading brand names, and promotional language in OTP or alert templates.
• Monitor error codes and delivery outcomes after launch, not just registration approval.
• Keep a fallback plan for critical flows while registration, vetting, number association, or throughput increases are pending.

How to model 10DLC inside your app

The application should know which campaign and sender identity were used for each outbound message. That does not mean exposing carrier registration internals to product code. It means storing enough metadata to make routing, support, and incident response explainable.

type SmsRouteDecision = {
  destinationCountry: 'US';
  useCase: 'otp' | 'account_notification' | 'customer_care' | 'delivery_notification';
  senderType: '10dlc' | 'toll_free' | 'short_code';
  registrationStatus: 'approved' | 'pending' | 'blocked' | 'fallback';
  campaignId?: string;
  senderIdentity: string;
  fallbackReason?: string;
};

When a delivery problem appears, this model lets support see whether the message used an approved 10DLC route, a fallback route, or a sender identity that should not have been used for that recipient.

A launch runbook for US transactional SMS

1. Map every US transactional message to a specific use case and campaign.
2. Prepare brand and campaign data before engineering calls the SMS API in production.
3. Associate numbers only after the campaign is approved and record the association status.
4. Test OTPs, alerts, and webhooks through the same sender identity planned for production.
5. Add alerts for failed, undelivered, filtered, throttled, and unknown outcomes by campaign.
6. Create a fallback user path for critical verification flows that cannot wait for SMS.