Outbound SMS Regulation in Spain 2026

1. Executive summary for 2026

Spain’s outbound SMS compliance framework now has two layers that must be treated together. The first layer is the existing commercial-communications regime: consent, opt-out rights, advertising-exclusion lists, and data-protection duties. The second layer is the telecommunications anti-spoofing regime introduced by Order TDF/149/2025, which requires operators and messaging providers to validate the origin identifier used in SMS, MMS, and RCS traffic.

For companies using alphanumeric sender IDs, the decisive operational change is the CNMC Alias Registry. The Registry links each alias to a legitimate holder and to the registered originating provider or providers authorized to send messages with that alias. Once the Registry is fully deployed, messages with an unregistered alias, or with a registered alias sent through an unauthorized provider, should be expected to be blocked before reaching Spanish recipients.

Final deployment date: for operational planning, this guide treats September 15, 2026 as the final deployment date for the Alias Registry environment. Companies should not wait for that date to act. They should identify aliases, validate legitimate rights, appoint providers, prepare documentation, and test routing before production enforcement becomes unavoidable.

This document is written for enterprises, public bodies, aggregators, SMS resellers, SaaS platforms, and foreign companies that send A2P or commercial messages to Spanish numbers.

2. Scope: messages, recipients, and parties affected

The rules discussed in this guide are relevant whenever a message is addressed to a recipient with a Spanish number and uses either a numeric sender identifier or an alphanumeric alias. They apply to commercial campaigns, transactional notifications, authentication codes, security alerts, appointment reminders, logistics notices, public-administration messages, and equivalent A2P communications.

The Alias Registry specifically covers SMS, MMS, and RCS messages using an alphanumeric sender ID. The commercial-communications rules apply when the message has promotional or advertising content, regardless of whether the sender is numeric or alphanumeric.

The affected parties include:

• companies and public authorities that use aliases as sender identifiers;
• brand owners and corporate groups that want consistent sender names across providers;
• registered originating providers, including operators, aggregators, and resellers with technical capacity;
• transit providers and termination providers in the messaging chain;
• SaaS, CRM, ERP, marketing, authentication, and customer-communication platforms that send messages on behalf of clients;
• foreign companies sending messages to Spanish numbers.

Messages addressed to non-Spanish numbers are not governed by the Spanish Alias Registry merely because the sender is Spanish. Those messages must be evaluated under the destination country’s rules.

3. Commercial SMS rules: consent, opt-out, and exclusion lists

For promotional SMS, the starting point remains the Spanish regime for commercial communications sent by electronic means. As a general rule, promotional SMS may only be sent when the recipient has requested or expressly authorized them. A limited exception exists for existing customers when the sender lawfully obtained the contact data and the message concerns the sender’s own products or services similar to those already contracted.

Every commercial SMS should include or provide access to a simple and free opt-out mechanism. Once the recipient objects or withdraws consent, the sender must stop promotional SMS to that number for the relevant purpose.

Data-protection rules also apply because a mobile number linked to an individual is personal data. The sender must be able to justify the legal basis for processing, provide transparent information, respect data minimization, preserve consent evidence where consent is used, and document suppression or opt-out actions.

Before promotional campaigns, senders should screen recipient lists against applicable advertising-exclusion mechanisms, including the Robinson List and any other valid exclusion system relevant to the campaign. A number included in an exclusion list should not be contacted for advertising unless the sender can rely on a valid exception, such as a current customer relationship or specific later consent.

These legal-marketing requirements are independent from the Alias Registry. A message can have valid consent and still be blocked if the sender ID does not comply with the telecommunications rules. Conversely, a registered alias does not authorize unsolicited marketing.

4. Numeric sender identifiers and CLI rules already in force

Order TDF/149/2025 reinforced controls over the sender identifier shown in communications. For SMS with numeric sender IDs, the relevant compliance question is whether the number is valid, assigned, and legitimately used in the context of the message.

Operators must block messages with an empty, invalid, or anomalous sender identifier. This includes numbers that do not follow the national numbering plan format and numbers that have not been assigned to an operator or end user. A Spanish-looking number that is not actually assigned should not be used as a sender ID.

International traffic requires special care. SMS originated outside Spain that appear to come from Spanish numbering must be validated as legitimate. The anti-spoofing logic is intended to prevent foreign routes from being used to simulate local Spanish origin. Genuine roaming cases are treated differently, but ordinary A2P traffic from abroad should not use a fake Spanish sender number.

The practical rule for companies is simple: do not improvise numeric sender IDs. Use numbers that are assigned, documented, and technically compatible with the provider’s routing model. When an alias is preferred, use the Alias Registry process rather than an unauthorized numeric workaround.

5. 2026 calendar and September 15 final deployment

The 2026 operational calendar should be managed as a deployment program, not as a one-day legal event. The earlier regulatory milestone for alias controls must be read together with the practical Registry deployment timetable. For production planning, the date that matters most in this guide is September 15, 2026, the final deployment date specified for the Alias Registry rollout.

Companies that rely on OTP, banking, logistics, healthcare, or public-service notifications should prioritize testing. In these use cases, blocking is not only a compliance issue; it can directly affect authentication, delivery, appointment attendance, or user security.

6. What counts as an alias

An alias is an alphanumeric string used in the sender-identification field of an SMS, MMS, or RCS message. It tells the recipient who appears to be sending the message, but it is not a telephone number and normally cannot be used by the recipient as a reply destination.

Examples include a bank name, a retail brand, a public-agency abbreviation, a logistics brand, an authentication-service name, or a platform name used to send verification codes. The risk addressed by the Registry is that, without validation, a fraudulent sender could use a recognizable brand as the sender ID and mislead the user.

The Registry does not convert the alias into a numbering resource. It is a validation and authorization mechanism for sender identity in the messaging chain.

7. Who must register an alias

The alias should be registered by, or on behalf of, the entity that legitimately holds the right to use it. This holder may be a company, a public authority, a professional, a foundation, or an equivalent entity acting in the market.

Registration may be requested by:

• the alias holder;
• a legal representative of the holder;
• a registered originating provider acting on behalf of the holder;
• a third party authorized by the holder;
• an authorized representative, especially for foreign companies whose legal representatives cannot use a valid Spanish digital certificate.

When the request is submitted by a provider or third party, the holder or its representative must approve the action. This prevents a platform, agency, or provider from appropriating a brand alias without the holder’s consent.

There is no practical compliance advantage in registering only the “main” brand name if campaigns actually use variations. Case, spacing, punctuation, and spelling variations can be treated as different aliases. Each operational sender form should be reviewed and registered if it will be used.

8. Legitimate link between the alias and the holder

The holder must be able to justify that the alias is legitimately linked to it. The link can normally be based on one of the following:

• a registered trademark;
• a registered trade name;
• the corporate name;
• an internet domain;
• a name registered in a national or international public registry;
• legitimate and habitual professional or commercial use when no formal registry evidence exists.

The Registry process may rely on a responsible declaration, but the holder should retain supporting evidence. Depending on the alias, this may include trademark certificates, commercial-registry documents, domain-ownership records, corporate documentation, contracts, group authorizations, or proof of habitual use.

If several entities claim the same alias, priority should be assessed by reference to stronger rights such as trademarks and trade names, then domain or corporate-name evidence, and finally filing priority where no better right exists. A company that discovers that another entity has registered an alias to which it has a better right should be prepared to request CNMC intervention.

9. Format rules for SMS and MMS aliases

For SMS and MMS, the alias should be prepared according to the technical format accepted by the Registry and by messaging networks. The most important operational rules are:

• minimum length: 3 characters;
• maximum length: 11 characters;
• letters, digits, spaces, ñ, Ñ, ç, and Ç may be used where allowed;
• the special characters @, &, -, _, ., and + may be used where allowed;
• consecutive spaces should not be used;
• spaces at the beginning or end should not be used;
• accented characters should not be used;
• aliases made up only of numbers should not be used.

Aliases that are generic, confusing, offensive, misleading, or likely to impersonate a third party can be rejected or later challenged. Examples of risky aliases include generic terms such as Bank, Message, Urgent, or Security when they do not clearly identify the actual sender.

10. RCS sender aliases

RCS is included in the Alias Registry framework, but it has its own identity and brand-presentation characteristics. An RCS alias should clearly identify the holder and should not be designed in a way that creates confusion with another company, public authority, or service.

For RCS, the compliance analysis should include not only the text of the sender name but also the wider brand profile presented to users. The alias, brand name, verification status, logo, color, and message context should be consistent with the holder’s legitimate rights and with the registered information.

Companies using both SMS and RCS should align their alias portfolio. A name used safely in one channel may still require separate operational validation in the other.

11. Data required for alias registration

Before starting registration, the holder and provider should prepare a complete data package. At minimum, the file should include:

• the requested alias exactly as it will be used;
• whether the alias will be used for SMS/MMS, RCS, or both;
• the type of legitimate link and a description of that link;
• the holder’s corporate or personal identification data;
• tax identification or foreign equivalent;
• registered office or business address;
• legal representative or authorized representative details;
• the registered originating provider or providers authorized to send traffic;
• any third parties that manage or operate the alias on behalf of the holder;
• intended activation date;
• end-of-use date, if the alias is temporary;
• responsible declaration or supporting evidence of legitimate linkage.

Where several aliases belong to the same holder, general holder information can be reused, but each alias should have its own exact sender form, link justification, provider authorization, and operational status.

12. Registration flow and holder authorization

The standard registration flow is expected to operate through the CNMC electronic office and the Alias Registry management procedure. The applicant identifies itself with a valid digital certificate, submits holder and alias data, selects or identifies the registered originating provider, adds third parties where relevant, and submits the responsible declaration or supporting documentation.

If the action is not performed directly by the holder, the holder or its representative must approve it. The same approval logic should apply to material changes, such as adding a provider, changing third-party operators, modifying alias data, reactivating an alias, or cancelling an alias.

From an operational perspective, companies should assign internal ownership of the process. The legal team may hold the evidence, the marketing team may know the brands, the IT team may know the actual sender IDs, and the messaging provider may control the routes. Registration fails or becomes incomplete when these views are not reconciled.

13. Registered originating providers and authorized third parties

Each alias must have at least one registered originating provider authorized by the holder. This provider is the first registered provider in the messaging chain that is authorized to send and transmit traffic using the alias.

A holder may authorize more than one originating provider. This is important for redundancy, multi-country platforms, group brands, banking authentication, campaign segmentation, or migration from one SMS provider to another. If the Registry lists only one authorized provider, traffic using the same alias from a different provider should be expected to fail validation.

The third-party concept is separate. A third party may manage or exploit the alias operationally on behalf of the holder without being the registered originating provider. Examples include CRM platforms, marketing agencies, SaaS applications, group subsidiaries, franchises, and authentication-service platforms. These parties should be identified and authorized where the Registry process requires it, but the holder remains responsible for legitimate use of the alias.

14. Provider obligations and blocking logic

Provider obligations differ according to the provider’s role in the chain: origination, transit, or termination. The common principle is that the Registry becomes the source of truth for deciding whether a message with an alias may circulate.

A registered originating provider must block or reject messages when the alias is unregistered, inactive, not linked to the holder, not authorized for that provider, or sent by an unauthorized third party. It should also send alias traffic only to other registered providers that can lawfully continue the chain.

A transit provider must block messages with unregistered aliases, messages received from unregistered providers, or messages that cannot continue through a chain of registered providers. Transit is not a neutral pass-through role when the traffic carries a regulated alias.

A termination provider must block alias traffic that fails Registry validation, including unregistered aliases, traffic received from unregistered providers, and foreign-company aliases arriving through international interfaces where no applicable exception exists.

Every allow/block decision should be traceable. A compliant system should record at least the alias, recipient country, previous provider, next provider, registered status, authorization status, route, timestamp, and blocking reason where applicable.

15. International traffic, roaming, and alias replacement

International A2P traffic is one of the main risk areas. A message received from abroad with a Spanish alias should be blocked unless an international roaming exception applies. A foreign-company alias that is unregistered and addressed to a Spanish number should also be blocked when it enters through an international interface, unless the mobile operator can validate the relevant roaming situation.

Where a roaming exception applies and the recipient subscriber is roaming, the termination logic may allow delivery with the alias replaced by NO VALIDADO. This prevents the alias from being presented as a validated Spanish Registry identity while avoiding unnecessary disruption to legitimate roaming traffic.

Companies should not design Spanish traffic around the roaming exception. For ordinary A2P and commercial traffic to Spanish numbers, the correct route is registration of the alias and use of a registered provider chain.

16. Foreign companies sending SMS to Spain

Foreign companies are not exempt from the Spanish alias rules merely because they are incorporated outside Spain. If they send SMS, MMS, or RCS messages with aliases to customers with Spanish numbers, and the recipients are within the regulated scope, the alias should be registered or otherwise recognized through an applicable future mechanism.

The foreign company must prove a legitimate link with the alias, comply with the format rules, designate at least one registered originating provider, identify representatives and third parties where applicable, and use a transmission chain made up of registered providers.

Where the foreign company’s legal representatives cannot obtain or use a valid digital certificate for Spain, the company may need to act through an authorized representative with a valid certificate. The authorization should be properly signed and retained, and the representative should be able to approve Registry actions on behalf of the foreign holder.

From a marketing-law perspective, foreign companies must also respect the consent, opt-out, and exclusion-list requirements when they target users in Spain with promotional SMS. Registration of the alias solves sender-identity validation; it does not solve marketing consent.

17. Technical implementation for SMS platforms, APIs, and SMPP

SMS platforms should treat sender IDs as controlled assets, not as free text fields. A user, client, or sub-account should not be able to enter any arbitrary Spanish alias and send traffic without validation.

Recommended platform controls include:

• per-client sender ID whitelists;
• mapping between alias, holder, authorized provider, third party, and route;
• automatic rejection of unregistered or inactive aliases for Spanish traffic;
• local cache of Registry data with controlled refresh intervals;
• route selection that avoids unregistered providers for regulated alias traffic;
• separate handling of numeric CLI and alphanumeric alias validation;
• blocking-reason codes exposed to operations and support teams;
• audit logs sufficient for CNMC, provider, or customer investigations.

For SMPP and API products, the sender parameter should be validated before accepting the message into the queue. Rejecting an invalid alias at submission time is operationally better than accepting traffic and discovering later that it is blocked downstream.

18. Checklist for companies and public bodies using aliases

• Inventory every sender ID used for Spanish traffic.
• Separate numeric senders from alphanumeric aliases.
• Identify the exact alias form, including case, spaces, punctuation, and variants.
• Confirm whether each alias is used for SMS/MMS, RCS, or both.
• Collect evidence of legitimate linkage: trademark, trade name, domain, corporate name, registry evidence, or habitual use.
• Decide which legal representative or authorized representative will approve Registry actions.
• Identify every SMS provider, aggregator, platform, and route that may originate the alias.
• Ensure each required originating provider is registered and authorized.
• Identify third parties that manage campaigns or send traffic on the holder’s behalf.
• Prepare opt-out, consent, and exclusion-list evidence for promotional traffic.
• Complete registration and testing before September 15, 2026.

19. Checklist for operators, aggregators, and SMS resellers

• Register as a provider where required for participation in alias traffic.
• Implement Registry-data access and authentication.
• Maintain an updated local view of active aliases and registered providers.
• Map each customer account to its authorized aliases.
• Block unregistered, inactive, unauthorized, or mismatched aliases.
• Ensure alias traffic is sent only to registered downstream providers.
• Implement separate checks for international interfaces and roaming exceptions.
• Generate blocking statistics and preserve traceability data.
• Provide customers with clear rejection reasons during testing and production.
• Complete integration, route testing, and operational support procedures before September 15, 2026.

20. Practical examples

Retail chain using a brand alias

A Spanish retailer sends promotional SMS using the alias BrandShop. It must have consent or a valid customer-relationship basis for marketing, screen exclusion lists where required, register the alias, and ensure its SMS provider is listed as an authorized registered originating provider.

Bank sending OTP and fraud alerts

A bank sends authentication codes using a short brand name. Even if the messages are transactional rather than promotional, the alias must be registered. If the bank uses two providers for redundancy, both should be authorized for the alias to avoid blocking during failover.

Foreign e-commerce platform

A company outside Spain sends offers to Spanish users using its global brand as sender. It must respect Spanish marketing requirements, register the alias for Spanish traffic, use a registered provider chain, and avoid simulating Spanish numeric origin through unauthorized international routes.

SaaS platform sending on behalf of customers

A CRM or authentication platform lets enterprise clients choose sender IDs. The platform should not permit arbitrary aliases for Spain. It should map each client to validated aliases, require evidence of holder authorization, and route traffic only through providers authorized for that alias.

21. Compliance matrix

22. Frequently asked questions

Does registering an alias authorize marketing SMS?

No. Alias registration only addresses sender-identity validation. Promotional SMS still require a valid legal basis, opt-out management, and exclusion-list screening where applicable.

Does every brand variation need separate review?

Yes. The exact sender form matters. Changes in case, spaces, punctuation, or abbreviations may be treated as different aliases and should be reviewed before use.

Can a foreign company register an alias?

Yes, if it needs to send alias-based messages to Spanish numbers. It may need an authorized representative with a valid certificate for Spain and must use registered providers.

What happens if a provider is not authorized for my alias?

Traffic may be blocked even if the alias itself is registered. The Registry validates both the alias and the provider chain.

What is the key deadline?

For deployment planning, use September 15, 2026 as the final deployment date for the Alias Registry environment and complete registration, authorization, routing, and testing before then.

23. Conclusion

The Spanish SMS market is moving from a trust-based sender-ID model to a verified sender-ID model. For years, alphanumeric aliases improved brand recognition but also created a major spoofing vector. The CNMC Alias Registry is designed to close that gap by linking aliases to legitimate holders and authorized provider chains.

Compliance in 2026 therefore requires more than legal consent language. Companies must align legal rights, brand ownership, provider contracts, API configuration, routing, and operational logging. The organizations that prepare early will reduce blocking risk, protect users from impersonation, and preserve the reliability of SMS, MMS, and RCS as business communication channels in Spain.

24. Copyright notice

This report belongs to 402T LABS, SLU and is prepared for publication at https://sidroute.com/outbound-sms-regulation-spain-2026.html.

All rights reserved. Total or partial reproduction is prohibited without express authorization.