The per-country answer, as a matrix
Sender-ID pre-registration is not one global obligation — it is a per-country, per-channel matrix, and Devotel Orbit ships the whole matrix as a live reference you can read before you commit to a market. A destination that routes your brand name cleanly in one country can fail-close on the next, and the only safe moment to learn which category it sits in is before the launch, not after the first blocked send.
The rule a carrier enforces is set by its local regulator: Ofcom in the UK, AGCOM in Italy, CST in Saudi Arabia, TDRA in the UAE, TRAI in India. No platform can flatten those regimes into one form, and none should promise you they can — what a platform owes you is a complete, current map of the differences and a filing desk that reaches each regulator. That map is exactly what this article walks through. The KYC and sender-ID registration guide covers the identity documents behind the filings; this one is the read order: find your market, check its posture, file, then watch the status.
Why registration rules differ country by country
Three pressures produce the divergence:
- Different regulators, different objects. Some regimes register a company (US 10DLC brand + campaign), some register a sender name (the Gulf markets), some register message templates too (India DLT). The object you file — entity, header, template — depends on which authority answers for that sender class.
- Different sender classes. The UK, France, Spain, Italy, and most of the EU accept alphabetic sender IDs; Brazil and India accept only registered headers or templates; several markets treat numeric long codes as carrier-provisioned and exempt from the alphabetic check entirely.
- Different enforcement. A few regulators police the sender registry on every send, others treat registration as a reliability signal that improves filtering. The same
required/recommendedlabel can mean "blocked at send-time" or "delivers but gets relabeled" in different countries.
The lesson is simple: any vendor who tells you "sender registration is handled" is either flattening per-country regimes into one form (which is wrong) or is not covering the markets your roadmap touches. Read the matrix, not the brochure.
Read the matrix live — GET /compliance/country-rules
The authoritative source for your planning call is a single reference endpoint: GET /api/v1/compliance/country-rules. Any authenticated user can call it; it returns, per country and per channel (sms, rcs, whatsapp, voice, email, viber), the accepted sender types and a registration field with three values:
| Value | Meaning | Planning posture |
|---|---|---|
none | The destination accepts senders with no registration. | Launch as soon as the country and channel are enabled on your account. |
recommended | Sending works unregistered, but unregistered traffic is filtered or relabelled more often. | Launch now; queue registration as a reliability task, not a blocker. |
required | The send-time gate blocks all A2P traffic to the destination until a registration for that country reaches approved. | Registration is on the critical path; some markets take weeks. |
Call it once per channel — the same country can answer to a different regulator per channel — and filter by region to narrow the scan. The public docs hub carries the same matrix in browsable form at the per-country rules index; treat any static table (including this one) as a snapshot and the endpoint as the source of truth.
If you build your country picker in a console or onboarding flow, that picker should call the endpoint and surface the registration value per country — so a market that requires pre-registration shows its lead time before your roadmap locks to it. The sender-ID country matrix guide treats the choosing matrix step by step.
Fail-closed, not filtered — the required gate
Two behavior classes matter at send-time:
- In a
noneorrecommendedcountry, an unregistered alphabetic sender still sends; it just risks filtering, relabeling, or a worse spam score on the carrier's side. That trade-off is yours to manage. - In a
requiredcountry, the gate fails closed. The send is rejected with a422and a market-specific code — for exampleMESSAGING_SA_SENDER_NOT_REGISTEREDorMESSAGING_AE_SENDER_NOT_REGISTERED— and nothing reaches the carrier at all.
The gate checks alphabetic senders only. Numeric long codes route through carrier provisioning, so the check never blocks a number the carrier itself provisioned. To clear the gate, file the registration for that country and wait for the carrier's approved status; until then, the blocked send is the correct behavior.
Sample regimes — read the row, then file
Registration levels change at the regulator, so start from the live row. Below is the current planning snapshot for four common required regimes — the shape of an alphabetical sender filing, the regulator that answers, and the trap each one lays for a first-time filer:
| Country | Regulator | What is registered | Common first-time failure |
|---|---|---|---|
Italy (IT) | AGCOM sender registry | Alphabetic sender ID (3-character minimum) | Filing an under-3-character sender that carriers refuse |
Saudi Arabia (SA) | CST (formerly CITC) | Sender name plus the KYC-backed entity behind it | Registering the brand without the sender name attached |
United Arab Emirates (AE) | TDRA (formerly TRA) | Sender name with uploaded KYC documents on file | Skipping the document step before the registration step |
India (IN) | TRAI DLT ledger | Entity + header + content template, matched by template ID | Registering the sender but not the content templates |
Each of these has a dedicated, deeper page in the docs hub — Italy AGCOM, Saudi CST, UAE TDRA, and India DLT — and the table above is deliberately a map, not a replacement for them.
How to file — /compliance/sender-id-registration
Filings go through the sender-ID registration surface: Settings → Sender IDs in the dashboard, or POST /api/v1/compliance/sender-id-registrations from the API. The call references documents already in your tenant library by doc_… ID — never files attached inline — and returns a tracking status you poll until the carrier or regulator grants approved:
- Upload the KYC documents the country expects (the KYC and sender-ID registration guide covers document types, roles, and renewal).
- Submit the registration with the document references, per country, per sender.
- Watch status until
approved; arejectedfiling shows the carrier's reason so you can re-file.
Step-by-step contracts, statuses, and the full field lists are in the sender-ID registration reference; the sequence in a multi-market rollout is laid out in the sender-ID registration by market guide. Inbound-only markets (where a numeric long code replaces an alphabetic sender) bypass this flow entirely — the carrier provisions the number, not the sender name.
Tenant-owned posture — where Orbit's boundary stops
This article is a map, not legal advice. The split of responsibility is deliberate and public:
- Orbit keeps the matrix live. The endpoint, the per-country pages, and the send gates are maintained so each row reflects the current regulator position.
- You own the filings. You choose the markets, submit truthful documents, and keep them current as your business details change.
- Final approval sits with the carrier or regulator in every country — never with the platform. Orbit never invents, auto-approves, or auto-renews a registration, and a
registrationvalue on the endpoint is a planning signal, not a delivery guarantee. - Coverage is per tenant. A country listed by the endpoint is not necessarily enabled on your account; the map shows what a market requires, not whether it is open for you yet.
If a market reads required and your account has no approved registration for it, that block is the gate working as designed — not a defect. File, then launch.
Frequently asked questions
Which countries force pre-registration before the first send?
The required markets that surprise operators most are Italy (AGCOM), Saudi Arabia (CST), the United Arab Emirates (TDRA), and India (TRAI DLT with content templates). The United Kingdom, Brazil, and the United States (as 10DLC brand + campaign) are also required. Always read the live registration field from the country-rules endpoint at choose-time — static tables go stale.
What does the send-time gate do on a required country?
It fails closed: the send is rejected with a 422 and a market-specific code, and nothing reaches the carrier. The gate applies to alphabetic sender IDs; numeric long codes route through carrier provisioning, so the check never blocks a carrier-provisioned number. A none or recommended country still sends unregistered traffic, with filtering and relabeling risk on top.
Where do I read the full per-country matrix?
Either query GET /api/v1/compliance/country-rules (the live source of truth — filter by region, call once per channel) or browse the per-country rules index in the docs hub. Deep-dive pages per regime — Italy AGCOM, Saudi CST, UAE TDRA, India DLT — sit behind that index.
How do I file a sender-ID registration?
Submit from Settings → Sender IDs or call POST /api/v1/compliance/sender-id-registrations with the document IDs (doc_…) already in your tenant library, per country and per sender. Track the status until the carrier or regulator grants approved; a rejection shows the reason so you can re-file. The sender-ID registration reference documents every field and status.
Do inbound-only numeric routes need registration too?
No. The gate checks alphabetic sender IDs only; a numeric long code that inbound traffic shares with outbound flows routes through carrier provisioning, and a required-country registration is unnecessary for purely inbound use. The moment you introduce an alphabetic sender the check applies; provision numbers where they help, register names where they are needed.
Sources and further reading
- Per-country rules index: the full country matrix with dedicated pages per regime and official-law links.
- Sender-ID registration: the filing API's fields, statuses, and document references.
- Sender-ID country matrix guide: the choose-time reading of
none / recommended / required. - KYC and sender-ID registration: the identity layer behind every filing, from document library through approved profile.
- CPaaS compliance topics: the companion telecom-regulation explainer (TCPA, 10DLC, STIR/SHAKEN, opt-out).