Step-by-step: escalate a registrar lock to secure a .es domain

Step-by-step: escalate a registrar lock to secure a .es domain. UDRP and ccTLD domain recovery and defense across .es. Email the firm to assess your case.

A .es domain disappears from your account overnight. The registrar's automated system shows a status change you did not authorize, and the site that ran on that name is now pointing somewhere else. The clock is already running. Every hour of unauthorized use deepens the harm, and registrar support queues do not move at the speed of a hijacking.

Escalating a registrar lock to secure a .es domain means working through Red.es – Spain's national registry – and the current sponsoring registrar simultaneously, documenting the compromise, and triggering the procedural levers that can freeze the name before an unauthorized transfer completes. The governing body for .es is Red.es, which operates its own dispute and lock procedures distinct from the UDRP. Acting within the first 24 to 48 hours is the single most consequential decision in the entire process.

This guide walks each step in sequence, flags the trap hidden in each one, and explains when to cross from the registrar track to the Spanish courts.

Why .es escalation differs from a UDRP recovery route

The UDRP does not apply to .es. Red.es administers the .es namespace under Spanish national rules, and its dispute procedure – the PEAC procedure – operates on a separate legal basis from ICANN's uniform policy. That distinction changes everything about tactics.

Under the UDRP, a complainant argues that a domain was registered and used in bad faith by a third party who registered it deliberately. A registrar-lock escalation for .es is a different claim: you are asserting that you are, and have been, the rightful registrant, and that an unauthorized event – account compromise, social-engineering of the registrar, or fraudulent transfer documentation – displaced you. The question is not bad faith by a third-party registrant; it is unauthorized displacement of the true registrant.

That framing matters for evidence. A UDRP complainant demonstrates trademark rights and bad faith. A lock-escalation claimant demonstrates identity, continuous control, and the specific moment of breach. Both require a clean evidence trail; neither forgives delay.

Red.es publishes its current registrar accreditation rules and dispute procedures in Spanish. Any English-language summary – including this one – should be verified against the current published text, because national ccTLD rules are updated without the international notice that ICANN policy changes receive. We regularly advise registrants to confirm the current Red.es procedure directly before filing anything.

For an assessment of your .es recovery situation, contact info@cognomenlaw.com.

Step 1: Freeze the name before anything else moves

The first step is a registrar lock request – submitted in writing, not by phone – to the current sponsoring registrar within hours of discovering the unauthorized change. Verbal escalations leave no record. Every submission must carry a timestamp, a reference number if the registrar provides one, and a clear statement that you do not consent to any transfer, deletion, or DNS modification pending resolution.

The trap in this step: registrars sometimes treat a lock request as a general support ticket and route it through a standard queue. That queue can take days. The correct framing is an explicit abuse or security escalation, not a support query. The words "unauthorized transfer" and "account compromise" trigger a different workflow at most ICANN-accredited registrars – and .es registrars typically hold ICANN accreditation alongside their Red.es authorization.

Simultaneously, contact Red.es. The registry has its own channel for reporting unauthorized registrar actions. A direct registry report, independent of the registrar escalation, creates a second record and can prompt Red.es to place a server-side hold on the name. A server-side hold is more resilient than a registrar-level lock because it sits above the registrar's own systems.

Document every contact: the date, the time, the method, the reference number, and the name of any agent you reach. Screenshot the current WHOIS/RDDS output for the name before it changes further. That screenshot, timestamped, is evidence. It shows the state of the record at the moment you acted.

Step 2: Assemble the evidence of compromise

A lock request without supporting evidence stalls quickly. The registrar and Red.es both need to satisfy themselves that the person demanding the freeze is the true prior registrant – and that a legitimate change did not occur. Preparing that evidence file is the second step, and it must happen in parallel with Step 1, not after it.

The core evidence set for a .es registrar-lock escalation typically includes the following categories.

• Original registration records: the confirmation email from the original registration, any renewal invoices, and historical WHOIS data showing your identity as registrant across successive periods.
• Billing continuity: payment records – credit card statements, bank transfers, or registrar account transaction logs – showing that you paid registration and renewal fees. A payment trail is powerful evidence that the economic relationship with the registrar has always been yours.
• Account access history: login logs, two-factor authentication records, and any anomaly alerts from the registrar's own systems showing an access event you did not initiate.
• Identity documentation: passport or national ID consistent with the registrant details on record at the time of registration. Where the registrant is an entity rather than an individual, corporate registration documents and authorized signatory records.
• Communications showing the breach: any phishing emails, social-engineering messages, or suspicious password-reset requests that preceded the unauthorized action. These demonstrate the vector of compromise and defeat any argument that you consented to a change.

The trap in this step: registrants often submit a single piece of evidence – typically the original registration email – and consider it sufficient. Registrars and Red.es weigh the totality. A well-documented file resolves faster and with less back-and-forth than a thin submission that prompts repeated requests for supplemental materials.

Step 3: Escalate within the registrar's internal chain

If the initial abuse or security escalation does not produce a written hold confirmation within 24 hours, the escalation must move up the registrar's internal hierarchy. First-line support agents typically lack authority to freeze a domain name unilaterally. The Compliance, Legal, or Abuse team does.

A written escalation to the registrar's compliance contact – available from the registrar's WHOIS record or website – should state: the domain name; the registrant of record as of a specific prior date; the nature of the unauthorized change; the request for an immediate server-side lock pending resolution; and an invitation to treat the email as a formal notice of disputed ownership. Copy the message to Red.es at the same time.

The trap: many .es registrants assume the registrar is a neutral technical party with no legal exposure. That is not quite right. A registrar that facilitates or fails to halt a fraudulent transfer may face liability under Spanish law. Framing the escalation as a legal notice – not just a support request – changes how it is handled internally.

Where the registrar is based outside Spain, an additional layer applies. ICANN-accredited registrars are subject to ICANN's Registrar Accreditation Agreement, which imposes obligations around responding to abuse notifications. A parallel report to ICANN's Compliance function adds pressure and creates a dated record of the registrar's response time. We have used this parallel channel to accelerate registrar responses in situations where internal escalation had stalled.

Step 4: Engage Red.es formally

Red.es is the competent authority for the .es namespace. A formal written complaint to Red.es – in Spanish, referencing the specific domain, the registrant of record, and the nature of the unauthorized change – opens the registry-level track. This track is separate from, and can run concurrently with, the registrar escalation.

Red.es has the technical ability to place a registry-level lock on a domain, preventing any modification including DNS changes and inter-registrar transfers. That lock, once confirmed, is the strongest available protection short of a court order. It is not automatic; it requires a substantiated request.

The formal Red.es complaint should attach the evidence file assembled in Step 2. Include a clear chronology: when the domain was first registered, when you last had uncontested control, when the unauthorized change occurred, and what steps you have already taken. A timeline document – one page, bullet points, dated entries – helps an agency reviewer understand the situation without having to reconstruct it from scattered attachments.

The trap in this step: submissions to Red.es in English may be processed more slowly or returned for translation. Spain's administrative procedures default to Spanish. A submission in Spanish, even if imperfect, signals engagement with the correct procedural channel. Where in-country support is needed, we work with local counsel in Spain for formal administrative filings.

To weigh the registrar-track and the Red.es formal complaint for your specific .es situation, email info@cognomenlaw.com.

How do you know when to cross from the registrar track to the Spanish courts?

The registrar and Red.es tracks resolve a significant proportion of .es domain-compromise cases – but not all. Three conditions typically signal that a court route is necessary.

First, where the unauthorized transferee is actively resisting the return of the domain and is using it commercially, the economic harm accumulates daily. Red.es's administrative procedure is not designed to move at the speed of active infringement. A court application for interim relief – a precautionary measure under Spanish civil procedure – can freeze both the domain and associated services while the substantive dispute is resolved. We coordinate that application with local litigation counsel in Spain.

Second, where the registrar has ignored or delayed the escalation beyond a reasonable period and the domain is at risk of transfer to a further party, only a court order carries the authority to compel the registrar to act on a specific timetable. An ICANN Compliance report alone does not.

Third, where you also need compensation for losses caused by the unauthorized use – revenue diverted, customers deceived, reputational damage – only a court can award monetary relief. The registrar-lock track restores the domain; it cannot award damages.

In a matter handled in late 2024 (a .es brand domain, compromised through registrar account social engineering, autumn), we pursued both tracks simultaneously: a formal Red.es complaint within 48 hours of discovery and a precautionary-measure application to the competent Spanish court within five business days. The court measure was granted before the Red.es track concluded. The domain was returned to the rightful registrant roughly three weeks after compromise was confirmed, with no further unauthorized transfer in the interim.

The decision between tracks is not binary. Running both in parallel is standard practice in higher-stakes situations. The cost of the court route is substantially higher – court proceedings in Spain involve local litigation counsel, court fees, and process time that is measured in weeks rather than days – but where a delay means permanent loss of the name or ongoing commercial harm, the cost is proportionate.

What evidence actually decides the outcome?

Across the registrar, Red.es, and court routes, the evidence that consistently determines outcomes is the same: continuous, documented control over the domain from registration through the moment of compromise.

Panels and agencies do not give weight to claims of entitlement in the abstract. They weigh documents. The strongest position is one where the claimant can show, with dated records, that the economic and technical relationship with the domain has been unbroken: the original registration, every renewal, every DNS change made by the rightful registrant, and – crucially – the first moment of irregularity.

Two patterns tend to produce weak outcomes. The first is delay: a claimant who waited weeks to report a compromise will face questions about why, and the delay can suggest acquiescence. The second is a thin identity file. Where the registrant name on record does not clearly match the claimant's current identity – because a business changed name, because an individual used a variant – a supplemental explanation and supporting documentation are needed. Leaving that gap unexplained invites doubt.

In a .es case from spring 2025, we recovered a domain for a registrant whose original registration email was tied to an account that had since been decommissioned. The solution was not to abandon the claim but to build an alternative chain: corporate board resolutions, domain management authorizations, and billing records from the intervening years. The file was thicker than average. It worked because it was complete.

Cross-zone considerations: .es versus .com recovery in parallel

A business that operates under the same name across a .com and a .es is not unusual. When the .es is compromised, the .com may follow – or the same actor may already hold both. The recovery strategy depends on the zone.

For the .com, the UDRP applies. If the .com was registered by a third party who did not hold prior rights, a UDRP complaint before WIPO or the Forum is the fastest route, with a filing fee starting at USD 1,500 for a single-member panel and a typical decision timeline of about two months. For a .com that was stolen from the rightful owner rather than registered by a stranger, the theft-recovery route – registrar escalation plus, if necessary, US anticybersquatting litigation – applies instead.

For the .es, neither the UDRP nor the URS applies. Red.es and, where necessary, the Spanish courts govern. The two tracks – .com and .es – can run simultaneously and should, where both names are at issue. Evidence assembled for one proceeding is often directly usable in the other. We regularly manage parallel multi-zone recovery efforts from a single coordinated file.

The trap for brand owners: treating the two zones as separate problems handled by separate advisors, without a coordinated strategy. An unauthorized holder who receives a UDRP complaint on the .com may accelerate changes to the .es to entrench the position there. Coordination between the tracks removes that opportunity.

Related at COGNOMEN

• Court action and domain theft recovery across all zones and jurisdictions
• Reversing an unauthorized domain transfer in .ae and comparable ccTLD zones
• UDRP recovery where the disputed domain is confusingly similar to a Swiss trademark