Messaging
Sender ID rules by country
See whether an alphanumeric sender ID is usable, must be pre-registered, or isn't used at all, country by country.
Free, no accountIn your browser
Only the countries with a sourced regulator or vendor page are listed. Leave it on every country for the full table.
Result
16 countries checked for alphanumeric sender ID rules
Pick a country above to see its rule on its own, or read the full table below - each row carries its own source and the day it was checked.
- Info
Checked 13 October 2026, not a live rule check
This is a dated reference built from each regulator's or vendor's own page, not a live check against the carrier sending today. Several of these rules changed their own enforcement dates during 2025-2026 while this table was being put together.
- Info
A national rule is already a simplification
Generic sender IDs such as INFO, SMS or NOTICE are prohibited as a standing rule on nearly every one of these vendor pages, and per-network exceptions exist inside some of these countries that a single national row cannot show.
| Country | Alpha sender ID | Rule | Pre-registration | URL in body | Source |
|---|---|---|---|---|---|
| United States (US) | Not supported | Alphanumeric sender ID is not supported at all; US A2P traffic uses 10DLC long codes, toll-free numbers or short codes instead. | Not applicable | Not documented | Vonage - checked 13 October 2026 |
| Canada (CA) | Not supported | Alphanumeric sender ID is not supported; SMS to Canada must come from a Canadian long virtual number, a registered 10DLC, a CA short code or a verified toll-free number. | Not applicable | Not documented | Vonage - checked 13 October 2026 |
| United Kingdom (GB) | Supported | Dynamic (unregistered) alphanumeric sender ID is still accepted, but a protected-brand sender ID must be validated against the MEF's SMS SenderID Protection Registry, and non-"+44" international numeric senders are blocked; the gambling-content guidance says to stick to one or two URL shorteners rather than rotating ones. | Required | Restricted | Vonage - checked 13 October 2026 |
| Ireland (IE) | Supported | Every sender ID sent to Irish numbers must be registered in ComReg's SMS Sender ID Registry: from 3 July 2025 an unregistered one is relabelled "Likely Scam", and from 3 October 2025 it is blocked outright. | Required | Not documented | ComReg - checked 13 October 2026 |
| France (FR) | Supported | French operators recommend an alpha sender ID for all networks; a sender ID with special characters now requires registration, and anything sent to the NRJ Mobile or Truephone networks is overwritten with a random short code regardless. | Required | Not documented | Vonage - checked 13 October 2026 |
| Germany (DE) | Supported | Alpha sender IDs are fully supported with no registration step; numeric sender IDs are not supported unless offered as a two-way service. | Not required | Not documented | Vonage - checked 13 October 2026 |
| Spain (ES) | Supported | Only aliases pre-registered in CNMC's Registro de alias may be used as an SMS, MMS or RCS sender name; CNMC's own announcement states the blocking obligation for unregistered aliases begins 7 June 2026, after a testing period that runs until 6 June 2026. | Required | Not documented | CNMC - checked 13 October 2026 |
| Italy (IT) | Supported | Alpha sender IDs are "fully supported for now"; a 2023 AGCOM rule that would bar an international brand from using an alpha sender ID to Italy, forcing a domestic long virtual number instead, has been postponed indefinitely. | Not required | Not documented | Vonage - checked 13 October 2026 |
| Netherlands (NL) | Supported | Alpha senders are generally supported with no registration step; numeric sender IDs generally are not supported unless offered as a two-way service. | Not required | Not documented | Vonage - checked 13 October 2026 |
| Australia (AU) | Supported | Alphanumeric and numeric sender IDs sent through a vendor have required registration (evidence of legitimate use) since 1 July 2023, or traffic is blocked; from 1 July 2026 every Australian telco must also check sender IDs against the ACMA's national register and over-stamp an unregistered one with "Unverified". | Required | Not documented | Vonage - checked 13 October 2026 |
| New Zealand (NZ) | Not supported | Alphanumeric sender ID is not supported for message delivery; only a procured short code is used, and the brand and content behind that short code must still be registered - registration is compulsory even though there is no alpha sender ID to register. | Required | Not documented | Vonage - checked 13 October 2026 |
| India (IN) | Not supported | Alphanumeric sender ID is not supported for traffic sent through this vendor to India; it is overwritten with a random short code, and domestic India SMS is not carried at all through this route, only international enterprise traffic. | Not applicable | Not documented | Vonage - checked 13 October 2026 |
| Singapore (SG) | Supported | Only sender IDs registered with the regulator are delivered as-is; unregistered ones are converted to "Likely-SCAM" until further notice, mandatory since 31 January 2023. | Required | Not documented | Vonage - checked 13 October 2026 |
| United Arab Emirates (AE) | Supported | Alpha sender IDs are case-sensitive and must contain the brand name; the TRA requires registration for all traffic, a registered marketing sender ID must carry an "AD-" prefix (11 characters maximum including it), and a dormant sender ID is deactivated after 6 months. | Required | Not documented | Vonage - checked 13 October 2026 |
| Saudi Arabia (SA) | Supported | A non-Saudi-based company needs alpha sender ID registration; registration is not offered through this route for a KSA-based company. | Required | Not documented | Twilio - checked 13 October 2026 |
| Brazil (BR) | Not supported | Alphanumeric sender ID is not supported; it is changed to a short code or a local number to ensure delivery, and the gambling-traffic guidance says to avoid public shortened-URL domains and prefer a private one, randomised for high-volume campaigns. | Not applicable | Restricted | Vonage - checked 13 October 2026 |
Checked 13 October 2026 per row, not live.
- This table covers the countries we have actually read a source for, not every country: it is a checked list, not a world list.
- South Africa, Nigeria, Mexico and Japan were deliberately left out of this pass: the only pages found for them were a search-result summary, not a page this tool could read in full, and a row read that way is not a sourced row.
What this is
This page answers sms sender id rules by country from a table built off each country's own regulator or the vendor actually sending the traffic there - not a live check, a dated reference with a source and a checked-on date beside every row.
An alphanumeric sender ID is a name - a brand, not a phone number - shown as who a text message came from. Whether one can be used at all, whether it has to be registered first, and whether a link in the body is restricted are three separate questions, and this table answers all three per country rather than assuming one answer covers every country a sender reaches.
"Not supported" and "not documented" read as the same thing from a distance and mean opposite things up close: the first is a source stating plainly that alpha sender ID is not offered, the second is a source that never addresses the question at all. Collapsing the two would have this table claim something no regulator or vendor actually said.
How to read the result
Choose a country to see its own rule, its registration requirement and who to register with, and whether a URL in the body is flagged - or leave the country on "All countries" to read every row at once. Every row names its own publisher and the day this tool checked it, right beside the rule rather than in a footnote.
Spain's row shows two dates rather than one: CNMC's own announcement names 7 June 2026 for blocking to begin, a vendor blog names 15 September 2026, and the two disagree. Neither is chosen here - both are shown, with who said each one.
Sender ID rules are the second of three checks that decide whether an SMS arrives; see sending an SMS that arrives for the segment pricing check before it and the A2P throughput check after.
Common mistakes
What goes wrong most often, and how to tell.
- Treating "generic sender IDs are prohibited" as a per-country quirkIt is a standing rule on nearly every one of the vendor pages behind this table, not a one-off restriction in one country: a sender ID like INFO, SMS or NOTICE is rejected almost everywhere, independent of the country-specific rule in this table.
- Reading a national row as the whole truth for every network in that countryA single row per country is already a simplification: the sources behind this table carve out exceptions by carrier inside some countries, which one national rule cannot show. Confirm with your vendor for the specific network you are sending to.
- Assuming a country missing from this table has no restrictionThis table only lists the countries a source was actually read for in full. A country not listed here has not been checked by this tool at all, which is a different thing from a source saying there is no restriction.
Questions
What people ask about this tool.
- No. Every row is a dated reference read from a regulator's or vendor's own page on the date shown, not a request made to a carrier right now. Rules changed enforcement dates more than once while this table was being built, so confirm with the vendor sending your traffic before you launch.
- Because its own regulator, CNMC, and a vendor blog, Esendex, name different dates for when blocking unregistered aliases begins - 7 June 2026 from CNMC, 15 September 2026 from Esendex. Rather than pick one, this table shows both with who said each.
- It means the source behind that row never addresses the question at all - not that there is confirmed to be no restriction. Treating the two as the same thing would have this table claim a fact nobody actually published.
- Because the only pages found for them in this pass were a search-result summary of a vendor page, not a page this tool could actually read in full - and a row read only that way is not a sourced row. They were left out rather than guessed at.
Use it from the API
The same check, as one request.