Sender-ID Registration: Required vs Recommended vs Absent — Which Market to Launch First

Quick answer: Most operators burn launch time on the wrong markets. They spend a week pre-registering a sender ID for France and Germany, where registration is recommended and the real risk is a quiet filter on unregistered traffic, then get blocked on day one in Singapore and India, where registration is required and the send gate hard-holds A2P traffic with no approved entry. This comparison ranks the ten markets Devotel Orbit customers send into most by the tradeoff that actually matters for a rollout: registration effort weighed against deliverability impact, with the per-market error code, the matching regulator page, and the one first action that moves the needle per market.

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 problem: the matrix is operator's-eye, but the trigger distribution differs by market

The country-requirements matrix is written from the operator's side: one row per country × channel, with a registration field set to none, recommended, or required. Read it cold and every required market looks equally blocking and every recommended market looks equally optional. That framing hides the tradeoff a rollout plan actually makes.

The tradeoff is between two axes that the matrix stores as one field:

• Registration effort — how much lead time and how many artifacts a required market demands before an approved entry exists. Singapore wants one SGNIC sender registration. India wants three DLT artifact types (Headers, content templates, consent templates) through a multi-week portal sequence. The US wants a 10DLC brand plus a campaign plus per-carrier vetting. Same required level, very different effort.
• Deliverability impact — what happens when you send without the registration. In a required market the send gate hard-holds the traffic and you see a 422 with a regional sender-registration error code. In a recommended market the send dispatches, but unregistered alphanumeric traffic is progressively filtered or relabelled by operators, so delivery degrades over days instead of failing up front.

Where operators burn time is on the low-impact side of the second axis: they pre-register senders for recommended markets where the send would have gone through anyway, while under-budgeting the required markets where the gate blocks on the first send. The ranking below inverts that habit — it sorts the ten markets by the product of registration effort and deliverability impact, so the markets where a missed registration actually stalls a launch sit at the top.

Ranked: ten markets by registration effort × deliverability impact

Each row carries the registration level, the send-gate error code that fires when the gate blocks (read from the compliance send-gate error codes catalog), the matching regulator page on the docs site, and the single highest-yield first action — the one step that moves a stalled launch furthest per market.

1. India — `required`, highest effort. Three DLT artifact types through the TRAI portal (Headers, content templates, consent templates); multi-week onboarding. Gate code: MESSAGING_IN_DLT_TEMPLATE_REQUIRED / …_CONTENT_MISMATCH (422) when a send carries no dlt_template_id or drifts from the registered content. Regulator page: DLT India onboarding. First action: start the Header registration first — it gates the template and consent registrations, and nothing sends until all three are approved.

1. United States — `required`, via 10DLC. Brand (legal entity) plus campaign (use case) plus per-carrier vetting; throughput granted per tier. Unregistered A2P long-code traffic is blocked. Gate code: SENDER_ID_NOT_REGISTERED (422) on the alphanumeric side; TFV_… / 10DLC campaign posture codes on the toll-free side. Regulator page: 10DLC registration guide. First action: register the brand against tax records first — a brand mismatch kills every campaign under it, and the campaign vetting waits on a clean brand.

1. Singapore — `required`, enforced at send time. SGNIC sender-ID registration must be approved before send; the gate holds unregistered traffic at send time. Gate code: MESSAGING_SG_SENDER_NOT_REGISTERED (422) — the SG variant of the regional sender-registration probe. Regulator page: PDPA Singapore and Thailand. First action: file the SGNIC sender registration during onboarding, not after the first blocked send — the hold is hard, and there is no warning path.

1. Saudi Arabia — `required`, CITC registration. An alphanumeric sender demands an approved CITC country-registration entry; numeric senders skip the probe (carriers provision them at purchase). Gate code: MESSAGING_SA_SENDER_NOT_REGISTERED (422). Regulator page: Saudi Arabia CST sender rules. First action: register the alphanumeric sender with the CITC entry before you plan the volume — the gate holds alphabetic traffic only, so a numeric long code is the fast workaround while the alphanumeric registration is pending.

1. United Arab Emirates — `required`, TDRA registration. Same shape as Saudi: an alphanumeric sender needs an approved TDRA entry; numeric senders are provisioned at purchase. Gate code: MESSAGING_AE_SENDER_NOT_REGISTERED (422). Regulator page: UAE TDRA sender rules. First action: register the alphanumeric sender with the TDRA entry, and plan the launch against the alphanumeric approval lead time rather than against a numeric long code you could send today.

1. Brazil — `required` for sustained SMS (Anatel), WhatsApp separate. Anatel filters unregistered alphanumeric A2P heavily; for sustained volume, registration is effectively required. WhatsApp to Brazilian recipients answers to Meta's WABA rules, not Anatel — read the per-channel row. Gate code: MESSAGING_BR_SENDER_NOT_REGISTERED (422) on the SMS side. Regulator page: LGPD Brazil. First action: register the Anatel alphanumeric sender for the SMS channel, and stand up the WABA separately for the WhatsApp channel — one registration does not cover both.

1. France — `recommended`, real risk is quiet hours and content. Alphanumeric senders work day one; unregistered traffic is filtered over time. The constraint that stalls first sends there is content and timing (GDPR prior opt-in, the 20:00–08:00 window, Sundays and public holidays) and the opt-out keyword in French (STOP au 36111). Gate code: QUIET_HOURS_BLOCKED (422) when the window fires — not a registration code. Regulator page: France marketing SMS rules. First action: set the quiet-hours window and the French opt-out keyword before the first send — the sender registration can follow the launch without blocking it.

1. Germany — `recommended`, light registration, spam filtering. Alphanumeric senders work; German operators apply spam filtering that makes unregistered traffic less reliable over time. Content follows GDPR prior opt-in and a German opt-out keyword. Gate code: none specific to registration — the risk is progressive filter degradation, not a hard hold. Regulator page: Germany UWG / BNetzA. First action: register the sender when you commit to a sustained program — for a test send or a short campaign, send first and register for stability once volume is real.

1. Italy — `recommended`, AGCOM content rules. Alphanumeric senders send without a hard registration gate; the load-bearing rules are content and consent (GDPR plus AGCOM's marketing rules). Gate code: none registration-specific. Regulator page: Italy AGCOM sender rules. First action: confirm the consent and opt-out posture for Italian recipients before the first send — the sender registration is a stability step, not a launch gate.

1. Japan — `recommended`, APPi content posture. Alphanumeric senders send; the rules that matter are APPi's consent and content requirements. Gate code: none registration-specific. Regulator page: Japan APPi. First action: align the consent and content posture to APPi, then register the sender for delivery stability once the program is sustained.

The ranking above is effort × impact, not volume × population. A high-volume market at recommended (France, Germany) ranks below a lower-volume market at required (Singapore, UAE) because the required gate blocks the launch while the recommended market degrades delivery without halting it. Re-sort by your own volume once the gate posture is clear — the gate level is the constraint, the volume is the scale.

Reading the country rows out of GET /compliance/country-rules

The ranking above is a planning summary. The live answer lives behind a read-only reference any authenticated user can call: GET /api/v1/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, default_tps, and a last_synced_at provenance stamp. The schema and field meanings are the country requirements page; the full request/response contract is the compliance API reference.

To rank your own ten markets, pull the SMS rows and sort on the tradeoff above:

curl "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=sms" \
  -H "X-API-Key: dv_live_sk_..."

Read the registration field first — it is the single most important value on the row. A required market goes to the top of the launch plan regardless of volume; a recommended market sends today and registers for stability; an absent market (below) takes the fallback posture, not an invented rule. Then read sender_rules and content_restrictions for the per-market constraints that decide which sender type and what content the gate accepts.

The same country can sit at different levels per channel. Brazil SMS answers to Anatel while WhatsApp to Brazilian recipients answers to Meta's WABA rules; 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, not just the country row.

How China mainland and market-specific blobs fit

China mainland asks a different question from the sender-ID matrix: not "which sender type" but "which channel." SMS long codes and international alphanumeric sender IDs face heavy filtering, and the app-first channels (WeChat Official Account, and the regional app-first messaging surfaces walked in the APAC messaging channels guide) run their own onboarding paths that replace the sender-ID question entirely. The country-rules table carries a China mainland SMS row, but the row's sender_rules and content_restrictions capture the filtering posture, not a sender-ID registration level — and the reliable delivery path is the channel-native sender (a registered WeChat Official Account), not a sender ID.

The market-specific blobs are the same shape the regional gates take: each required market (Brazil Anatel, Saudi CITC, UAE TDRA, Singapore SGNIC) emits its own regional sender-registration error code (MESSAGING_BR_SENDER_NOT_REGISTERED, MESSAGING_SA_SENDER_NOT_REGISTERED, MESSAGING_AE_SENDER_NOT_REGISTERED, MESSAGING_SG_SENDER_NOT_REGISTERED) rather than a generic SENDER_ID_NOT_REGISTERED, so a blocked send names the regulator that demands the entry. India emits the DLT template codes (MESSAGING_IN_DLT_TEMPLATE_REQUIRED, …_CONTENT_MISMATCH) because its gate is template-level, not sender-level. The country-rule-feeds page documents how those rows stay current: six upstream feeds (MEF, GSMA, iconectiv, Meta, ITU WTID, Telnyx) refresh the structural fields — country name, calling code, region, sender types, registration level, source links — without ever overwriting the editorial columns your team writes. A feed can move a row's registration level upward (none → recommended → required) but never downward, so a registry going quiet about a country cannot silently downgrade a posture your team asserted as required. See the country-rule-feeds page for the feed map and the provenance stamp.

When a country is absent from the matrix — the fallback posture

Not every country has a row in the country-rules table. An absent row is data, not a green light, and the fallback posture is explicit: do not invent a country rule. When a destination has no row, the send gate does not hold the traffic on a sender-registration probe, but the absence of a row is not a regulatory determination — it means the per-country posture for that destination has not been curated, and the deliverability and legal posture for that traffic stays with you and your counsel.

The documented posture for an absent country is:

1. Do not infer `none`. A missing row is not a registration: none row. Treat the destination as unevaluated, not as registration-free.
2. Send at your own deliverability risk. Without a curated sender_types and sender_rules entry, the send dispatches but the carrier-level filtering and routing for that destination is uncharacterized — delivery may be unstable and is not covered by the gate's per-country posture.
3. Confirm the destination is enabled on your account. Coverage is per tenant; a country absent from the matrix may also be unenabled on your account, which is a separate block from the regulatory posture.
4. Request curation through the country-rules directory. The country-rules directory is the surface for requesting a new country row; the platform-ops team curates the row from the upstream feeds and the regulator source, and the registration level is set from the registry, not guessed.

The matrix grows as markets are curated; the fallback posture exists so an absent row is never read as permission. Read the live GET /compliance/country-rules response for the destination before you plan around it, and treat a missing row as a curation request, not a launch gate.

Frequently asked questions

Should I register a sender ID for every recommended market before launch?

No. In a recommended market (France, Germany, Italy, Japan, Canada, many APAC destinations), the send dispatches without registration; unregistered alphanumeric traffic is filtered over time, not blocked up front. Send first, register for stability once the program is sustained, and spend the launch lead time on the required markets where the gate hard-holds traffic.

How do I rank which required market to register first?

By registration effort, not by population. India (three DLT artifact types, multi-week) and the US (brand plus campaign plus per-carrier vetting) sit highest on effort; Singapore, Saudi, and the UAE sit lower on effort but hard-hold at send time. Rank the multi-week regimes first so the lead time runs in parallel with the rest of the rollout.

Does a required market block my send or just warn me?

It blocks. On a required level the send gate hard-holds A2P traffic with no approved registration and returns a 422 with the regional sender-registration error code (MESSAGING_SG_SENDER_NOT_REGISTERED, MESSAGING_IN_DLT_TEMPLATE_REQUIRED, etc.). There is no warning path. The gate behavior is described in the send-gate decision fork.

What about a country that is not in the matrix at all?

An absent row is not a none row and not a green light. It means the per-country posture has not been curated; the send gate does not hold on a registration probe, but the deliverability and legal posture stays with you and your counsel. Request curation through the country-rules directory rather than inferring a rule.

Is this legal advice?

No. This is a tenant-owned onboarding comparison 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.

Rank the markets by effort × impact, register the required ones into onboarding, send the recommended ones first and register for stability, and treat the absent ones as curation requests. The tradeoff above is the one a rollout plan actually makes; the live country-rules reference is the answer at send time.

Published 3 October 2026.