Spanish phone number format: +34, mobile prefixes, validation and calling rules

Spanish phone numbers have nine digits after the country code +34, and there is no trunk 0. Mobile numbers start with 6 or 7 (71 to 74), and landlines start with 8 or 9, so a mobile in E.164 looks like +34 6XX XXX XXX. The first digits don't show the current network, because numbers can be ported in one working day. Since 17 October 2026, sales calls from companies covered by the Customer Service Act must come from numbers starting with 400.

This guide is part of our phone numbers by country series. The tables are generated from libphonenumber's metadata, our MNP atlas and our public catalog. Example numbers are masked with X, or are the example numbers published in libphonenumber. We read the laws, ministerial orders and resolutions in the Official State Gazette (BOE), and documents from the telecoms regulator (CNMC), the Ministry for Digital Transformation and the data protection agency (AEPD), on 2026-11-03. This is a summary, not legal advice.

What does a Spanish phone number look like?

Every Spanish number is nine digits long. The national numbering plan, an annex to Royal Decree 2296/2004, writes the national number as NXYABMCDU, nine digits where N is the first one dialled (RD 2296/2004, annex, section 4.1). Short codes such as 112 are the exception. There is no trunk prefix: you dial the same nine digits inside Spain and put +34 or 0034 in front from abroad.

Store only the E.164 form, +34 and nine digits, with no spaces. Spaniards usually write mobiles in groups of three (612 345 678) and landlines as 91 123 45 67 or 912 34 56 78. Forms also collect 0034…, 34… without a plus, and (+34). A numbering-plan library with the default region ES handles all of these, as the test below shows.

What does the first digit mean?

The plan gives each first digit a purpose. The table combines the 2004 plan with the resolutions that changed it later:

Sources: RD 2296/2004, 2010 resolution, 400 resolution, 2026 M2M resolution.

Which prefixes are mobile numbers?

For each 2-digit block, the generator counted every 9-digit number that libphonenumber's mobile pattern for ES accepts:

All of 60 to 69 and 71 to 74 are mobile, as the plan says. Two rows differ from the regulator's documents. libphonenumber accepts the whole 78 block as mobile, while the 2010 resolution lists 75 to 79 as reserved, and we found no later attribution of 78 in the BOE. It also accepts a few small sub-blocks in 590, 969 and 973 as mobile. Treat those as rare edge cases. Don't hard-code them, and keep the library updated.

Can you tell the operator from a 6 or 7 prefix?

No. The CNMC assigns mobile numbers to operators in blocks and publishes who holds each block in its numbering register, which is also an open dataset (datos.gob.es). That register names the original holder only. Spain ports more than 400,000 mobile numbers a month (see below), so a block tells you very little about where a number is today. We don't publish a prefix-to-operator table for Spain for that reason.

By lines, the market is concentrated: in June 2026, Movistar, Vodafone and MASORANGE held 85.5% of Spain's 63.24 million mobile lines, and 98.1% with DIGI (CNMC, June 2026). Many virtual operators (MVNOs) run on those networks. A live lookup returns the current network code (MCC-MNC), which is the reliable answer.

How do I validate a Spanish number in code?

Use a libphonenumber port with full metadata and the default region ES, then keep only mobiles. Spain has no trunk prefix, so the usual 0 problems don't arise.

Python (pip install phonenumbers):

import phonenumbers


def normalize_es(raw: str) -> str | None:
    """E.164 for a Spanish mobile number (6XX or 7XX), or None."""
    try:
        n = phonenumbers.parse(raw, "ES")
    except phonenumbers.NumberParseException:
        return None
    if (not phonenumbers.is_valid_number(n) or phonenumbers.region_code_for_number(n) != "ES"
            or phonenumbers.number_type(n) != phonenumbers.PhoneNumberType.MOBILE):
        return None
    return phonenumbers.format_number(n, phonenumbers.PhoneNumberFormat.E164)


for raw in ["612 34 56 78", "+34 612 345 678", "0034 612345678", "34612345678", "(+34) 612-34-56-78",
            "61234567", "810 12 34 56", "800 12 34 56", "701 23 45 67"]:
    print(f"{raw!r:22} -> {normalize_es(raw)}")

JavaScript (npm install libphonenumber-js):

import { parsePhoneNumberFromString } from "libphonenumber-js/max";

/** "612 …", "+34 6…", "0034 …" or "34…" → E.164 for a Spanish mobile, or null. */
export function normalizeEs(raw) {
  const phone = parsePhoneNumberFromString(String(raw), "ES");
  return phone?.isValid() && phone.country === "ES" && phone.getType() === "MOBILE" ? phone.number : null;
}

for (const raw of ["612 34 56 78", "+34 612 345 678", "0034 612345678", "34612345678", "(+34) 612-34-56-78",
  "61234567", "810 12 34 56", "800 12 34 56", "701 23 45 67"]) {
  console.log(JSON.stringify(raw).padEnd(22), "->", normalizeEs(raw));
}

The inputs are libphonenumber's own example numbers for Spain (mobile 612 34 56 78, fixed line 810 12 34 56, freephone 800 12 34 56, personal number 701 23 45 67), not real subscribers. We ran both on 2026-11-03 (Python 3.12 with phonenumbers 9.0.40, Node.js 24 with libphonenumber-js 1.13.13). Both printed the same answers:

'612 34 56 78'         -> +34612345678
'+34 612 345 678'      -> +34612345678
'0034 612345678'       -> +34612345678
'34612345678'          -> +34612345678
'(+34) 612-34-56-78'   -> +34612345678
'61234567'             -> None
'810 12 34 56'         -> None
'800 12 34 56'         -> None
'701 23 45 67'         -> None

(The JavaScript version prints null instead of None and uses double quotes.) The fourth line shows that 34612345678, without a plus, is still read as Spanish: eleven digits can't be a national number, so the library strips 34 as the country code. The last line is a 70 personal number. It looks like a mobile but isn't one. The shape regex column below tests the pattern most tutorials give, after spaces, dashes and brackets are removed:

Rows 8 and 10 are the ones to remember. Row 8, 50, has the shape of a Spanish number and passes the regex, but no range starts there. Row 10 is a 70 personal number, which passes a "starts with 6 or 7" check but is not a mobile line, so an OTP sent to it may never arrive. Our post on why an E.164 regex is not enough shows the same problem in other countries, and our Python and JavaScript guides cover more cases.

400 numbers, M2M numbers and caller ID

Two newer ranges need a decision in your code:

• 400 numbers are valid in libphonenumber 9.0.40 but typed FIXED_LINE. They are outgoing-only numbers for commercial calls, and calls to them are not allowed (400 resolution). If one shows up as a customer's contact number on a sign-up form, it's a data error: reject it or ask again.
• M2M numbers move to the 59 range with 13 digits. Since 1 July 2026, new machine-to-machine services must use it. Existing M2M services on mobile numbers have until 1 January 2031 to move, a date that may change with the 2G and 3G shutdown plans (2026 M2M resolution). libphonenumber doesn't accept 13-digit 59 numbers yet. They aren't phones, so a MOBILE check correctly leaves them out.

Does number portability change the carrier?

Yes, and often. The telecoms regulator of the time (the CMT, now part of the CNMC) approved the technical rules for mobile porting on 8 June 2000. A resolution of 16 November 2000 required mobile operators to offer porting before 25 November 2000 (CMT resolution DT 2006/502, background). In July 2011 the CMT required porting in one working day for mobile customers before 1 June 2012 (CMT resolution DT 2009/1660).

The current rule is article 70 of the General Telecommunications Act, Ley 11/2022 (Ley 11/2022):

• One working day. A ported number must be activated within one working day of the date agreed with the customer, and loss of service during the switch may not exceed one working day (70.3).
• The new operator runs the process. The donor and recipient must cooperate, and no one may be switched without explicit consent (70.5).
• One month after cancelling. A customer who ends a contract keeps the right to port the number for at least one month (70.2).
• Prepaid credit back. The old operator refunds unused prepaid credit on request (70.7).

Porting is common. The CNMC counted 599,196 mobile ports in March 2026, up 12.7% on a year earlier (CNMC, March 2026), and 498,234 in June 2026, up 7.9% (CNMC, June 2026). That is close to 1% of all mobile lines in a single month.

The Spain row of our MNP atlas:

The atlas row cites the EU rule. The Spanish rule behind it is article 70.3 of Ley 11/2022, and the launch deadline was 25 November 2000. Our MNP atlas compares Spain with other countries, and our guide on how to check if a phone number is ported shows the lookup. For routing and pricing, check the current network per number, as our SMS routing with MNP and HLR use case explains.

What are the rules for sales calls, SMS and caller ID?

Spain changed these rules several times between 2023 and 2026. These points summarise the texts as we read them on 2026-11-03. Not legal advice; ask counsel how they apply to you.

Sales calls need consent or legitimate interest (LGT art. 66)

Article 66.1.b of Ley 11/2022 gives people the right not to receive unwanted commercial calls unless they agreed beforehand, or the call has another legal basis under article 6.1 of the GDPR. It took effect one year after the law was published, on 29 June 2023 (Ley 11/2022, art. 66 and transitional provision). Automated calls without a human need prior consent in every case (66.1.a).

The AEPD's Circular 1/2023 says how it reads that rule (Circular 1/2023):

• Two possible bases. Consent, or legitimate interest under article 6.1.f GDPR. The contract basis doesn't apply to sales calls.
• A presumption for existing customers. Legitimate interest is presumed when the conditions of LSSI article 21.2 are met: a prior contract, lawfully collected contact details, similar products of your own, and an easy, free way to object. That presumption doesn't cover passing data to other group companies.
• No random numbers. Sales calls to randomly generated numbers without prior consent are not allowed.
• Check the opt-out lists first (article 4 of the circular, pointing to LOPDGDD article 23).

Sales calls must come from 400 numbers

The Customer Service Act, Ley 10/2025 of 26 December, entered into force on 28 December 2025. Article 16.3 says a company's phone customer service must have its own number code, separate from the code used for phone sales (Ley 10/2025). It applies to providers of basic services (water, gas and electricity, passenger transport, post, electronic communications and financial services) and to other consumer-facing companies with at least 250 staff, more than €50 million turnover or more than €43 million on the balance sheet, alone or as a group (article 2). Companies have twelve months from entry into force to adapt their customer service, and smaller energy and phone retailers get a longer transition for some duties.

Two resolutions of 14 April 2026, published on 16 April, put this into practice:

• Sales calls: 400. The code 400 is attributed to commercial calls. The range is outgoing only, and calls to 400 numbers are prohibited. Six months after the resolution took effect, sales calls may only be made from the 400 range. Operators may offer customers, on request, the option to cut off commercial calls from 400 numbers (400 resolution). The resolution took effect on 17 April 2026, so the deadline was 17 October 2026, which is the date the consumer authorities announced (Consumo Responde).
• Customer service: short codes, 800/900 or geographic numbers (customer-service resolution).

The ministry's announcement says operators will block commercial calls that don't come from the assigned numbers, and that people can report sales calls from other ranges (Ministry, 16 April 2026). Article 16.4 of Ley 10/2025 lets operators block calls from numbers suspected of making sales calls without the specific code, once the Secretary of State has authorised their detection criteria.

Spoofed caller IDs and mobile numbers in call centres

Orden TDF/149/2025 of 12 February, in force since 7 March 2025, is the anti-spoofing rule (Orden TDF/149/2025):

• Invalid caller IDs are blocked. Operators must block calls and SMS that show an empty caller ID, a Spanish number that isn't attributed or assigned, or one in the wrong format (articles 4 and 6).
• Spanish numbers from abroad are blocked. Calls and SMS arriving over international links that show a Spanish number are blocked unless the number is roaming. Where roaming can't be checked, the caller ID may be hidden or marked as unverified (articles 5 and 7.1, due within three months of entry into force).
• No mobile numbers for customer service or unsolicited sales calls (article 9, effective three months after entry into force). The order allowed 800 and 900 numbers for both, so people could call back for free (article 10). For sales calls covered by Ley 10/2025, the 400 rule now applies on top.

The ministry said in April 2026 that operators had blocked 192 million fraudulent calls and 17 million fraudulent SMS since March 2025 (Ministry, 16 April 2026).

SMS sender names must be registered with the CNMC

Under article 8 of Orden TDF/149/2025, companies and public bodies that send SMS, MMS or RCS with an alphanumeric sender name (an "alias") must register it with the CNMC before use. Operators must block messages with unregistered aliases, or from messaging providers not authorised for that alias. The CNMC created the registry by circular in March 2026: holders must show a link to a brand, trade name, company name or domain, and messages from foreign companies not registered in Spain are blocked unless the recipient is roaming (CNMC, 27 March 2026). Blocking was first due on 7 June 2026. Orden TDF/558/2026 moved it to 15 September 2026 to finish the bulk upload of existing aliases (Orden TDF/558/2026; CNMC, 5 June 2026).

This covers one-time passcodes too. If your OTP texts to Spanish numbers show a brand name, make sure that name and your SMS provider are in the registry, or the messages will be blocked.

Marketing SMS, WhatsApp and e-mail need consent (LSSI art. 21)

Article 21.1 of the LSSI (Ley 34/2002) bans advertising by e-mail "or equivalent electronic means" unless the recipient asked for it or expressly agreed to it beforehand (LSSI). The AEPD treats SMS and WhatsApp messages as such means (AEPD, unwanted advertising). The one exception (21.2) is for existing customers: if you lawfully got their contact details through a contract, you may market your own products similar to those they bought. Even then you must offer a simple, free way to opt out, both when you collect the details and in every message.

Lista Robinson and other opt-out lists

Article 23.4 of the LOPDGDD (Ley Orgánica 3/2018) requires anyone planning direct marketing to check first the advertising opt-out systems that may affect them, and to remove people who objected. Checking the systems listed by the data protection authority is enough. The check isn't needed for people who consented to receive your messages (LOPDGDD). The main system is Lista Robinson, run by the digital economy association Adigital. It is free for consumers and covers phone calls, SMS/MMS, e-mail and post. A new sign-up can take up to two months to take full effect (Lista Robinson).

Prepaid SIMs are identity-checked

Operators that sell prepaid SIMs must record the buyer's name, nationality and ID document number, or the company name and tax ID for businesses, under the additional provision of Ley 25/2007 (Ley 25/2007). That identity stays with the operator. A lookup never returns it, and numbers still get reused once lines are cancelled, so re-check old lists before you send OTPs. Our post on number recycling and list decay explains how.

Which messaging apps and channels reach people?

SMS reaches every active mobile, but in Spain it now passes through the alias registry and the anti-spoofing filters described above. For WhatsApp, Meta prices Spain as its own market on the WhatsApp Business Platform rate card, and its list of rate updates shows a higher marketing rate for Spain from 1 July 2026 (Meta pricing, read on 2026-11-03). Our WhatsApp Business API pricing post covers how the rate card works.

We found no official source that measures messaging-app use in Spain in a way we can verify, so we don't quote shares. Measure your own opted-in customers instead: check which apps they are registered on, route each person to the channel they use, and keep SMS as the fallback. Our channel-by-country guide shows the method.

How do I check WhatsApp registration for a Spanish customer list?

Normalise every row with normalize_es() first, then run one check per number. A check tells you whether a number is registered at the time of the check. It can't tell you whether the person wants your messages:

For lists, use a bulk job and upload the CSV with default_country=ES, so numbers written as 612 34 56 78 are read as Spanish. WhatsApp checks get the bulk price only for groups of at least 132 numbers from the same country in one job, so collect a day's Spanish numbers into one job rather than many small ones. POST /v1/jobs/estimate is free and shows the maximum cost before anything runs; see current prices. Our bulk WhatsApp number check post walks through the flow.

What changed recently?

The rows for ES and +34 in our numbering-plan changes dataset, built from libphonenumber's release notes:

Latest numbering-plan updates for ES: 2026-08-13 (v9.0.37), 2026-07-02 (v9.0.34), 2025-10-09 (v9.0.16), 2020-06-03 (v8.12.5), 2019-02-06 (v8.10.5).

Spain's validation metadata changes rarely: five numbering updates since 2019, two of them in 2026 (July and August), against sixteen carrier-data updates in the same period. The rules changed much faster than the digits. In 2026 alone came the M2M move to the 59 range (from 1 July), SMS alias blocking (15 September) and 400 numbers for sales calls (17 October).

What can MobileValidate check for Spanish numbers?

Generated from our public catalog:

Catalog data as of 2026-11-03.

* bulk jobs only. The live list is at GET /v1/services.

A lookup returns network and registration facts. It never returns a subscriber's name, DNI or other ID number, or address, and we don't offer "number details" searches.

For Spanish numbers, start with an MNP lookup, which tells you whether a number has been ported and gives its current network code. Add a live network status (HLR) check when you also need to know whether the number is reachable right now, for example before sending an OTP. Both answer unknown when there is no conclusive result, and unknown is free.

How to start without paying:

• Free test key. Get a test key: it never touches a real network and returns fixed answers for reserved test numbers, so you can build every branch first (test mode).
• Five real checks. Every live account can run 5 phone numbers and 5 e-mail addresses through the real-time checks for free on the dashboard's Try it page.
• Free estimate. POST /v1/jobs/estimate shows the maximum cost of a bulk file before anything runs.

To get a live account, request access. Viber and Zalo checks are bulk-only for now, as the asterisks in the table show. Prices are on the pricing page, which also lists the top-up bonuses on larger balances.

Here is a practical flow for a customer list: normalise with normalize_es(), then one real-time lookup gives porting status, the current network code (MCC-MNC) and WhatsApp registration. It uses the public sandbox key mv_test_publicSandboxn9ZgneuhR1B9CRfKG3fulym and our test values. The sandbox accepts only those UK drama numbers, so the example uses them. With a live key, pass the output of normalize_es().

import os

import requests  # pip install requests

API = "https://api.mobilevalidate.com/v1/lookup"
KEY = os.environ["MOBILEVALIDATE_API_KEY"]


def route(numbers: list[str]) -> dict[str, dict]:
    """Porting status, current network code and WhatsApp registration. None means we don't know."""
    r = requests.post(API, headers={"Authorization": f"Bearer {KEY}"}, timeout=15,
                      json={"numbers": numbers, "checks": ["mnp", "whatsapp"], "wait": 5})
    r.raise_for_status()
    out = {}
    for row in r.json()["results"]:
        mnp, wa = row["checks"]["number.mnp"], row["checks"]["whatsapp.registered"]
        attrs = (mnp["attributes"] or {}) if mnp["status"] == "completed" else {}
        out[row["e164"]] = {
            "porting": attrs.get("porting"),
            "mcc_mnc": attrs.get("mcc_mnc"),
            "whatsapp": wa["registered"] if wa["status"] == "completed" else None,
        }
    return out


for number, info in route(["+447700900001", "+447700900002", "+447700900005"]).items():
    print(number, info)

What it printed with the sandbox key on 2026-11-03:

+447700900001 {'porting': 'not_ported', 'mcc_mnc': '23415', 'whatsapp': True}
+447700900002 {'porting': 'not_ported', 'mcc_mnc': '23415', 'whatsapp': False}
+447700900005 {'porting': None, 'mcc_mnc': None, 'whatsapp': None}

The last test value answers unsupported_country for both checks, so everything is None. Keep None apart from False: None means we don't know, and it's never billed. Requests with 20 or more consecutive numbers are refused (403 suspected_enumeration), and our acceptable use policy forbids finding recipients for unsolicited messages. People can object through our opt-out form. See WhatsApp number check, MNP lookup and HLR lookup for the fields.

What are the key takeaways?

• Spanish numbers are +34 plus nine digits, with no trunk 0. Mobiles start with 6 or 71–74; landlines start with 8 or 9. Store the E.164 form.
• 70 is personal numbering, not mobile, and 400 is outgoing-only for sales calls. Filter both out of contact fields with a numbering-plan library, not a "starts with 6 or 7" regex.
• The prefix shows only the original block holder. Porting takes one working day, and around half a million mobile numbers change network every month.
• Sales calls need consent or legitimate interest, a check against Lista Robinson and, for companies covered by Ley 10/2025, a 400 caller ID since 17 October 2026.
• Marketing SMS and WhatsApp need prior consent under LSSI article 21. Since 15 September 2026, sender names, OTP senders included, must be registered with the CNMC.

Network, regulator and company names are used descriptively. MobileValidate is not affiliated with any of them.