GCC SMS Sender IDs: UAE TDRA and Saudi CST

1. UAE: TDRA marketing-message requirements

• Get and retain evidence of prior consent for marketing SMS. TDRA expects clear opt-in/opt-out mechanisms and action against messages sent without prior consent.
• Every marketing message needs a clear, free opt-out method. Do not obstruct or discourage an unsubscribe request; suppress future marketing to that recipient.
• TDRA's consumer controls use AD- as the marker for marketing texts that recipients can block. Ask your provider for the currently approved marketing sender format on each operator route; the marker does not replace sender registration.
• Keep service messages (such as OTPs and account alerts) separate from promotions. Do not disguise an advertisement as a service notification to bypass marketing controls.

2. Saudi Arabia: CST sender-name registration

CST (formerly CITC) regulates SMS and spam messages. Its bulk SMS sender-name process is carried out through service providers and the operator registration system. Do not send production A2P traffic until the sender name is approved for the exact route and traffic category.

1. Start a sender request in the selected CPaaS console or with its support team, and state whether traffic is transactional or promotional.
2. Prepare the documents that provider requests. They can include commercial registration, a signed delegation/authorization letter, proof of the relationship between the sender name and business, and provider-specific forms.
3. Confirm the exact approved sender spelling, message templates, URL/link rules, operator coverage, and any route restrictions in writing. These details are not interchangeable between providers.
4. Test delivery and opt-out behavior on the intended Saudi networks before launch. Re-check registration and route status when changing providers or sender names.

Provider documentation may mention sender-name suffixes, message windows, fees, or response targets. Treat those as provider/route instructions unless confirmed in the current CST regulation; do not hard-code them as universal rules.

3. Whitelist with your CPaaS provider

Registration is provider- and operator-specific. Common steps are to select the country and traffic type, request the sender name, submit business/authorization documents and representative message samples, then wait for approval before using that sender on the route. Ask whether a local business entity, consent records, or separate transactional and promotional registrations are required. No approval timeline or sender format is guaranteed by this guide.

Check the current onboarding page for your provider and destination:

• Twilio (UAE): UAE sender ID registration
• Twilio (KSA): Saudi sender ID registration
• Unifonic (UAE): UAE sender ID requirements
• Unifonic (KSA): Saudi sender ID requirements
• Infobip (UAE): UAE LOA guidelines
• Infobip (KSA): Saudi LOA guidelines

Provider availability changes. When checked on 4 November 2026, Twilio's UAE registration page reported a hold on new alphanumeric sender ID registrations. Confirm current status in your account before choosing a route.

4. Make opt-out instructions usable

• For UAE promotions, provide a free, clear method in every marketing message and record the opt-out immediately.
• Do not assume STOP works everywhere. Alphanumeric sender IDs may be one-way; use a provider-approved reply route or another free method that is actually available to recipients.
• Localize the instruction, test the full journey on the live route, and make sure opt-outs suppress marketing across all your sending systems. Do not treat delivery receipts as consent.

Example copy only: replace each placeholder with an enabled, free opt-out method supplied or approved for your route. Never send the placeholders literally.

// Replace these with the free opt-out instructions confirmed for your
// provider, sender type, and operator route before sending.
const english = `KHALEEJI: Your offer is ready. ${unsubscribeInstruction}`
const arabic = `خليجي: عرضك جاهز. ${unsubscribeInstructionArabic}`

5. Validate the destination before sending

Call Phone Validation from your server, then use its E.164 result after your own consent, suppression, approved-sender, and content checks. Keep your API key on the server. Validation does not perform any of those compliance checks.

const url = new URL("/api/v1/phone/validate", "https://khaleejiapi.dev")
url.searchParams.set("phone", submittedPhone)
 
const response = await fetch(url, {
  headers: {
    Authorization: "Bearer " + process.env.KHALEEJI_API_KEY,
  },
})
if (!response.ok) throw new Error("Phone validation failed")
 
const { data } = await response.json()
if (
  data.valid !== true ||
  data.type !== "mobile" ||
  !["AE", "SA"].includes(data.country.code)
) {
  throw new Error("Unsupported SMS destination")
}
 
// Use data.formats.e164 as the destination only after your application
// has separately checked consent, suppression, content, and sender approval.

See the Phone Validation API reference and SMS toll-fraud prevention guide.

Regulatory references

• TDRA — Marketing Short Message Service
• TDRA — Unsolicited Electronic Communications Regulatory Policy
• TDRA — SMS spam and the AD- marketing-message control
• CST — Regulations for Curbing SPAM Messages and Calls
• CST — Regulations of the Provision of the Short Messaging Service
• CST — Bulk SMS sender-name registration announcement

Do not assume one unsubscribe keyword works across every route. Confirm the current requirement and opt-out mechanism with your provider and regulator before launch.