Quick answer: The question "must you register a sender ID before you send" has a per-country, per-channel answer, not a platform-wide one. France lets you send a dynamic alphanumeric sender with registration recommended; Singapore blocks unregistered sender IDs at send time; India routes every sender ID ("Header") and template through the TRAI DLT portal; the United States blocks unregistered A2P long codes and funnels you into 10DLC brand-and-campaign vetting. This playbook walks the three registration levels, the five-step launch checklist, a deep dive on the markets Devotel Orbit customers launch into most, the two special regimes (India DLT, US 10DLC), and the documents regulators ask for, then points at the live per-country rules endpoint so you read today's answer, not this page's, before you send.
Everything below frames registration as tenant-owned controls you set up, not as legal advice and not as a delivery guarantee. Final approval is granted by the regulator or carrier in each country, and coverage is enabled per tenant: a country listed here is not necessarily enabled on your account.
The three registration levels
Orbit's send-time gate reads one field per country × channel: registration. It is one of three values, and it decides what happens when you try to send:
| Level | What it means | What the gate does |
|---|---|---|
none | No sender-ID registration is required. | Sends freely once the country and channel are enabled on your account. |
recommended | Registration is not mandatory, but unregistered traffic is more likely to be filtered or relabelled. | Sends, but flags the risk; registering keeps delivery stable. |
required | You must have an approved sender-ID registration before sending. | Holds A2P traffic to that country until an approved entry exists. |
The same country can sit at different levels per channel: WhatsApp in Brazil answers to Meta's WABA rules while SMS there answers to Anatel. So the first question to answer for every launch is: which level is this country at, for the channel I am sending? The levels are documented field by field in the country requirements page, and the gate that enforces them is described in the send gates page.
The five-step launch checklist
Run this per destination. It follows the same five steps Orbit's own onboarding walks:
- Look up the rules. Call the country-rules reference for the destination and channel and read
sender_types,registration, andcontent_restrictions. - Pick an accepted sender type. Choose a sender identity that country accepts: an alphanumeric sender ID, a long code, a short code, or a channel-native sender (WABA / RCS agent).
- Register if required. If the level is
required(or you judgerecommendedworth doing), upload your documents and submit the sender ID for approval. Plan lead time; some markets take days to weeks. - Check content restrictions. Confirm your use case is allowed and add the required opt-out keyword if the country calls for one. See Restricted & Prohibited Industries.
- Launch. Once the country is enabled, the sender type is accepted, and any required registration is approved, start sending.
Steps 1 and 3 are the two a launch plan most often skips, and step 3 is the one that bites back hardest: a required country with no approved entry holds traffic at send time. The checklist above is compressed from the country requirements page; run it against the live data, not this summary.
The markets Orbit customers launch into, walked one by one
Below are the destinations this playbook is asked about most. For each: the sender types the market accepts, the registration level, and the one constraint that most often stalls a first send. Treat it as a planning walk-through; the live answer always comes from the country-rules reference.
France: recommended, with one real constraint, quiet hours
France accepts alphanumeric sender IDs and long codes, and registration is recommended, not required. The constraint that stalls first sends there is content and timing, not the sender: marketing SMS requires prior opt-in under GDPR, and sends are barred in the 20:00–08:00 window and on Sundays and public holidays. Opt-out must be offered in French (STOP au 36111). Register the sender for consistency, and respect the time window, or your traffic is filtered by the gate regardless of what the sender ID says.
Germany: alphanumeric senders work, registration light
Germany accepts alphanumeric sender IDs, and registration there is recommended in the same sense as France: you can send a dynamic alphanumeric sender day one, but German operators apply spam filtering that makes unregistered traffic less reliable over time. Two-way (a routable long code) is supported. Content restrictions follow GDPR, prior opt-in for marketing, and an opt-out keyword in German is expected. Register the sender if you plan a sustained program; send freely to test.
Brazil: Anatel for SMS, Meta for WhatsApp
Brazil is the canonical example of separate rows per channel. SMS there answers to Anatel, accepting long codes and alphanumeric senders; registration for alphanumeric senders is effectively required for sustained A2P, and unregistered alphanumeric traffic is routinely filtered. WhatsApp to Brazilian recipients answers to Meta's WABA rules: display-name review, template categories, quality rating. The sender in that row is a registered WABA, not a sender ID. Read the per-channel row, not just the country.
Singapore: required, enforced at send time
Singapore is a required market: SGNIC (the Singapore Network Information Centre) sender-ID registration has to be approved before you send, and the gate holds unregistered traffic at send time. The rules changed from advisory to enforced. The SGNIC enforcement entry explains the registration flow, and the send-time hold is what "required" means in practice. Plan the registration into onboarding, not after the first blocked send.
India: required, through TRAI DLT, not the generic flow
India runs its own dedicated regime: every sender ID (called a Header), every content template, and every consent template registers through the TRAI DLT portal. The generic sender-ID flow does not apply. This is the single most demanding registration regime on the list, and it is a hard required market: send without an approved DLT entry and traffic is held. The DLT-India onboarding guide walks the portal sequence end to end.
United Kingdom: alphanumeric senders, registration recommended
The UK accepts dynamic alphanumeric sender IDs with registration recommended, and (as in France and Germany) unregistered alphanumeric traffic is increasingly filtered by UK operators as anti-smishing controls tighten. Prior opt-in under PECR and GDPR applies to marketing, and a STOP keyword is expected. Two-way long codes are supported. Register to keep the sender stable; the market is not required today, so plan registration into your schedule rather than assuming you are blocked from day one.
United States: required, via 10DLC brand-and-campaign vetting
US A2P SMS on long codes is a hard required market in a different regime: 10DLC. You register a brand (the legal entity) and a campaign (the use case), and throughput is granted per tier as a per-day, per-number cap. Unregistered A2P long-code traffic is blocked. The special regimes section below covers it in more depth; the full flow is the 10DLC registration guide. Do not conflate the US with "long codes work"; unregistered, they do not.
Canada: long codes accepted, registration recommended for A2P
Canada accepts long codes and alphanumeric senders, and registration is recommended rather than required for most A2P traffic. Canadian carriers apply their own filtering to alphanumeric and unregistered long-code traffic, and CASL (Canada's Anti-Spam Legislation) imposes consent and identification requirements on commercial messages. Two-way long codes are the reliable sender; for sustained A2P volume, register.
The wider APAC picture: Japan, Indonesia, Vietnam, Philippines, Australia, China, and the channel-native regimes
The markets above are the headline destinations, but APAC as a region is where per-channel, per-country matters most. A few patterns recur:
- Japan, Indonesia, Vietnam, Philippines, Australia accept alphanumeric sender IDs, with registration levels that vary by market from recommended (Australia, for example) to required in specific operator cases. Read the per-country row rather than assuming the region.
- China mainland asks a different question: not "which sender type" but "which channel." WeChat Official Account registration is its own onboarding path, and SMS long codes and international sender IDs face heavy filtering. The APAC app-first channels are walked in the APAC messaging channels guide.
- WABA / RCS agent as the sender. Across the region, the channel-native sender (a registered WhatsApp Business Account, a verified RCS agent) often replaces the sender-ID question entirely. The channel row decides, not the country row alone.
Use the country-rules reference per destination. The APAC block above is a summary of which markets pull which sender-type defaults; the live row is the answer at send time.
Where the complexity actually sits
If you placed these markets on a scatter of lead time against number of regimes touched, India (the DLT portal, three artifact types) and the US (brand, campaign, per-carrier vetting) would sit at the top of the regime axis. Singapore sits highest on the enforcement axis: required, held at send time. France, Germany, and the UK sit low on regime count but carry quiet-hours and filter risk that affects delivery stability. Brazil and APAC demand you read the per-channel row rather than the country row alone. None of that fits on one number line, which is exactly why the checklist above works per destination instead of trying to rank markets globally.
The special regimes: India DLT and US 10DLC, walked
These two markets bypass the generic sender-ID flow with their own registration regimes. Both are required, and both are the most common launch blockers in practice.
India, TRAI DLT. You register three artifact types through the DLT portal: Headers (the sender IDs), content templates, and consent templates. A send cites a registered Header and a registered template; anything else is held. Plan this as multi-week onboarding, not a day-one launch step. The DLT-India onboarding guide is the flow; treat it as a separate regime from the generic sender-ID registration.
United States, 10DLC. You register a brand (the legal entity, matched against tax records) and a campaign (the use case, with sample messages that match what you actually send). Approval comes in two places: at the CSP level and per carrier. A campaign can read APPROVED at the CSP level while one carrier still shows REVIEW, and per-carrier throughput follows the tier. The four rejection reasons that actually kill campaigns (entity-name mismatch, mismatched sample messages, missing opt-out language, political verticals without a Campaign Verify token) are the 10DLC rejection field note. The full registration flow is the 10DLC guide.
The documents regulators ask for
Where a market requires (or recommends) registration, you submit supporting documents once and reference them by their doc_… IDs when you register the sender ID. The exact set varies, but most regulators ask for some combination of:
- Proof of business registration: certificate of incorporation, business license, or equivalent.
- Use-case description: what you send (transactional, OTP, marketing) and to whom.
- Brand ownership or authorization: proof you are entitled to the sender ID or brand name you are registering.
- Local tax or regulator ID: for markets that key registration to a national identifier.
Read the target market's sender_rules and content_restrictions for the specifics, and attach the matching documents when you submit the registration. The walk-through is the sender-ID registration guide.
Read the live answer before you launch
This page is a playbook, not the data. The country-by-country rules live behind a read-only reference any authenticated user can call: GET /compliance/country-rules, filtered by channel and optionally by region, returning per-country rows with sender_types, registration, sender_rules, content_restrictions, stop_requirement, two_way, dlr_support, and a default_tps ceiling. The schema and field meanings are the country requirements page; the full request/response contract is the compliance API reference. Call it for the destination and channel, then run the five steps above.
Two more things to keep honest as you plan:
- Tenant-owned, not legal advice. Registration controls are configured per tenant by you; final approval is granted by the regulator or carrier, and the legal interpretation of a market's rules stays with you and your counsel. Orbit gives you the surfaces to run it (the gate, the registration flow, the country-rules reference), not a compliance posture.
- Coverage is per tenant. A country appearing in the reference is data, not enablement. Confirm the destination is enabled on your account before you plan around it.
Frequently asked questions
Is a "recommended" registration level a real risk, or a formality?
A real delivery-stability risk. In markets at recommended (France, Germany, UK, Canada, and many APAC destinations), unregistered alphanumeric traffic sends today but is progressively filtered or relabelled by operators. Register to keep long-running programs stable.
How long should I plan for registration lead time?
It ranges from same-day (dynamic alphanumeric senders in none or recommended markets) to multi-week (India DLT portal sequence; US 10DLC vetting on a first brand). Size the launch schedule against the regime, not the country name.
Do "required" markets actually block my send, or is it a warning?
They block. On a required level (Singapore, India, US long codes, and any per-channel required market), A2P traffic with no approved registration is held at send time. The gate behavior is described in the send gates page.
Does one registration cover SMS and WhatsApp to the same country?
No. The rules are per country × channel. A WABA-approved sender for WhatsApp does not satisfy an SMS sender-ID registration, and an approved SMS sender ID does not satisfy Meta's WABA display-name review. Read the per-channel row.
Is this legal advice?
No. This is a tenant-owned onboarding playbook pointing at per-market reference data; the legal interpretation of a country's rules stays with you and your counsel. Final approval is granted by the regulator or carrier, not by Orbit.
Run the five steps against the live country-rules reference, and the playbook above stays a planning tool instead of a stale map. The levels are hard gates where they are hard; the rest is a repeatable loop.
Published 1 September 2026.