Step-by-step: enforce a UDRP decision a registrar will not i… (.com 2)

Step-by-step: enforce a UDRP decision a registrar will not i… (.com 2). UDRP and ccTLD domain recovery and defense across .com. Email the firm to assess your c…

You won. A WIPO panel ordered the transfer of the .com that infringes your brand. The registrar has gone silent – no lock confirmation, no transfer, no timeline. Thirty calendar days have elapsed and the domain still points at the cybersquatter's page. What happens next depends entirely on whether you know the mechanics of ICANN's implementation chain and where, exactly, that chain is breaking.

To enforce a UDRP decision a registrar will not implement for a .com domain, you must first identify the specific failure point – a lapsed accreditation, an unresponsive registrar, a disputed lock, or a gaining-registrar refusal – and then escalate through ICANN's Contractual Compliance process, file a second complaint with a different provider if the domain has moved, or pursue a US federal court action under anticybersquatting law if administrative channels have failed. The UDRP grants no power of contempt; the panel's decision is an instruction to the registrar, not a court order. Your enforcement lever is ICANN's registrar contract, and when that lever also fails, the federal courthouse is the next stop.

This guide walks each step in sequence, names the trap each one hides, and maps the decision points where a court route overtakes the administrative path.

Why Registrars Fail to Implement UDRP Decisions

A panel decision is binding on the registrar under its ICANN Registrar Accreditation Agreement, but it is not self-executing. Three patterns account for nearly every enforcement failure we see in practice.

First, the registrar's compliance team may simply be unresponsive – large volume, small staff, a support-ticket system that routes .com transfer orders to a queue measured in weeks. Second, the losing registrant may have transferred the domain to a different registrar within the UDRP's standard 10-business-day lock window, a maneuver sometimes called a "cyberflight." Third, the registrar may itself have lost ICANN accreditation, been acquired, or merged into a successor entity that disavows the instruction. Each pattern requires a different response. Treating them all as a simple follow-up email wastes the time that matters most.

A fourth pattern – rarer but legally significant – is that the losing registrant has filed a court action in its local jurisdiction to enjoin the transfer. Under the UDRP, a registrant may do exactly that: Paragraph 4(k) of the Policy explicitly preserves the registrant's right to seek court relief, and the registrar is entitled to await that order before acting. That scenario converts your enforcement problem from a compliance matter into active litigation, and the steps below diverge sharply at that point.

Step 1 – Confirm the Transfer Lock and Check the Implementation Window

The first action after receiving a favorable decision is to verify that the domain has been placed under registrar lock. Under standard UDRP procedure, the registrar is required to lock the domain once a complaint is filed, preventing transfer or deletion during the proceeding. After a decision is issued, the registrar must hold the lock for 10 business days to allow the losing registrant to seek court relief. Only after that window closes should the transfer to you proceed.

The trap in this step: many complainants count 10 calendar days, not business days, and conclude the registrar is already late. Confirm the decision date, count business days excluding US federal holidays, and check the current WHOIS or RDDS record. If the domain has already moved to a new registrar – the most dangerous sign – go directly to Step 3.

Check the ICANN Registrar List to confirm the registrar's current accreditation status. An accreditation termination does not void the order, but it changes who is now responsible for executing it. ICANN typically assigns the domains of a terminated registrar to an emergency registrar. Identify that emergency registrar before any further communication.

Step 2 – Send a Formal Implementation Demand in Writing

Once the 10-business-day window has closed, send a written implementation demand directly to the registrar's abuse and compliance contacts – not merely its general support queue. The demand should: identify the domain, the WIPO case number and date of decision, the date the lock window expired, and the specific instruction to transfer the domain to your designated registrar account. Copy ICANN Contractual Compliance at contractualcompliance@icann.org.

Give the registrar a firm response deadline – typically five business days – stated in the letter. That deadline is not a courtesy; it is the predicate for the ICANN complaint that follows. Keep screenshots or timestamps of every support ticket, every email, and every chat transcript. In our experience handling enforcement matters in 2025, registrar silence breaks in roughly two thirds of cases at this stage, once the registrant's compliance team realizes the correspondence will be filed with ICANN.

The trap here: sending the demand only through the registrar's consumer support portal. That channel has no contractual compliance obligation attached. Use email addresses listed in the registrar's ICANN profile, and send via a traceable method that logs delivery.

If you have already sent an implementation demand and received no response, we can assess the next enforcement step. Contact info@cognomenlaw.com to weigh ICANN escalation against a court action for your case.

Step 3 – File an ICANN Contractual Compliance Complaint

ICANN's Contractual Compliance team enforces the Registrar Accreditation Agreement, which requires the registrar to implement a valid UDRP decision. A complaint filed through ICANN's online compliance portal triggers a formal review: ICANN contacts the registrar, logs the failure, and can ultimately move toward accreditation sanctions if the registrar continues to ignore the obligation.

To file effectively, include: a copy of the panel decision, evidence that the implementation window has expired, your written demand and the registrar's non-response, and a clear statement of the remedy you seek (domain transfer, not just acknowledgment). ICANN compliance responses vary in speed. In straightforward cases the registrar acts within days of ICANN contact. Where accreditation issues exist, the process can take considerably longer.

The trap: treating the ICANN complaint as a guarantee. ICANN is not a court and cannot award you the domain by order. Its leverage is contractual – the threat of sanctions or accreditation review. If the registrar has ceased operations or is in a merger without a clear successor, the ICANN complaint may produce no practical result, and you will need Step 5.

Step 4 – What If the Domain Has Been Transferred (Cyberflight)?

Cyberflight – the deliberate transfer of a domain to a new registrar to restart the clock and disrupt enforcement – is the most disruptive enforcement scenario. Registrants who do this typically move the domain before or during the UDRP response period, exploiting the registrar-lock window. If you discover the domain has moved to a new registrar after your complaint was filed, that transfer itself may be a violation of the lock requirement.

Your options fork at this point. First, file a new UDRP complaint naming the current registrar and the current holder. If the holder is the same party as the original respondent, panels will treat the history of the earlier decision as strong evidence of bad faith – indeed, the prior decision is itself a bad-faith indicator under Paragraph 4(b). A second filing is not res judicata; the Policy does not bar sequential complaints against the same domain where circumstances have materially changed, such as a transfer intended to defeat enforcement.

Second, treat the unauthorized transfer during the lock period as evidence of domain theft and pursue the registrar-escalation route described in our guide to recovering a hijacked domain: recovering a hijacked domain across zones. The transfer may have been executed without your authorization, making the account-compromise framework directly applicable.

Third, and most powerful in cyberflight cases: a US federal court action. If the registrant or the domain's new registrar is within US jurisdiction – or if the registry (Verisign, for .com) can be served – an anticybersquatting action allows you to name the registry directly and obtain a court order compelling transfer without the registrar's cooperation. That is an outcome administrative channels cannot reach.

A prior UDRP decision strengthens a court filing significantly. If you are at this step, email info@cognomenlaw.com to assess whether a court action is the right next move.

Step 5 – When Does a Court Action Beat the Administrative Path?

US anticybersquatting litigation is the enforcement route of last resort and, in some scenarios, the fastest. The key advantage is that a federal court can issue a temporary restraining order (TRO) locking the domain immediately and then a final order compelling Verisign – the .com registry – to transfer the domain directly, bypassing the registrar entirely. No other mechanism reaches the registry layer.

Court action is the right choice in four situations: (1) the registrar has ceased operations or lost accreditation and no successor has assumed the implementation obligation; (2) the registrant has filed a court action in its own jurisdiction to block the transfer, making a competing court filing in a favorable jurisdiction essential; (3) cyberflight has occurred and the new registrar is unresponsive to ICANN escalation; (4) you need monetary damages alongside the transfer – the UDRP awards none.

The trade-off is cost and time. A court action is substantially more expensive than a UDRP filing, proceeds on court schedules rather than a two-month administrative clock, and requires engaging local litigation counsel in the relevant jurisdiction. The investment is justified when the domain has significant commercial value or when a competitor is actively using it to divert your customers.

In a recent matter (a .com enforcement deadlock, spring 2025), we coordinated a court filing after a registrar that had gone through an undisclosed merger refused to acknowledge the WIPO order. The court issued a TRO within days of filing, locking the domain before any further transfer could be attempted. The case resolved by consent order several weeks later, achieving transfer without a full trial.

For an overview of how the court route integrates with the administrative path, see our court-recovery services page.

Step 6 – Assemble and Preserve Your Evidence at Every Stage

An enforcement action – whether ICANN complaint or court filing – is only as strong as its evidentiary record. Every stage of your enforcement attempt should be documented with contemporaneous screenshots, timestamped emails, WHOIS or RDDS captures, and registrar ticket reference numbers. The record you build in Steps 1 through 4 is the factual basis for Steps 5 and beyond.

What specifically to capture: the panel decision and its date; the WHOIS record at the moment the decision issued; the WHOIS record at the expiry of the 10-business-day window; each communication sent to the registrar and each response (or non-response); the ICANN Contractual Compliance complaint acknowledgment; and any movement in the WHOIS record showing a registrar change or registrant-of-record change after the decision.

The trap: allowing WHOIS records to become stale before capture. Under ICANN's RDAP/RDDS policies, historical WHOIS data is not publicly archived in real time. If the registrant changes the registrant-of-record or the registrar changes the underlying data, that information may become difficult to reconstruct without a contemporaneous snapshot. Take and store screenshots at each step.

In a second matter we handled (a .com non-implementation, autumn 2024), the complainant had no record of the WHOIS state at decision date. That gap required us to obtain historical RDDS data from a third-party provider and submit an affidavit attesting to its accuracy. The court accepted it, but the additional effort added several weeks to the timeline. A simple screenshot at each step would have avoided it entirely.

What Evidence Decides the Outcome?

Whether the enforcement path is ICANN escalation, a second UDRP, or a court action, three categories of evidence are dispositive. The first is the panel decision itself, including the full reasoning. A decision that makes specific findings about bad-faith use – for example, a finding that the registrant registered the domain to sell it back to you or to disrupt your business – provides far stronger grounds for a court filing than a bare transfer order.

The second is evidence of the registrar's specific failure. "They didn't respond" is insufficient. Document the exact dates of your communications, the channels used, the registrar contacts addressed, and the exact nature of any response. If the registrar cited a pending court action by the registrant, obtain and preserve that filing. It changes the legal analysis entirely – the registrar's pause may be contractually justified, and your next move is in the jurisdiction where the registrant sued.

The third category is harm evidence: screenshots of the domain resolving to a competing site, customer-confusion incidents, intercepted correspondence, or revenue-diversion data. This evidence is not required to enforce the UDRP order, but it is central to any court action seeking damages and it raises the urgency of a TRO application.

For the underlying mechanics of confusing-similarity analysis that produced your UDRP decision, see our service page on confusingly similar trademark analysis in UDRP proceedings.

Related at COGNOMEN

• Court recovery services – anticybersquatting litigation and TRO applications across jurisdictions
• Guide: recovering a hijacked or stolen domain after unauthorized transfer
• UDRP confusingly similar trademark analysis – the first element, explained