Recovery is a chain-of-custody argument
Nobody at ICANN can give your domain back. ICANN writes policy for the contracted parties — the registries that operate top-level domains and the registrars that sell and manage names — and those parties operate the database. Recovery therefore consists of convincing, or compelling, whichever party currently controls the record to change it back.
That means the work is evidentiary before it is procedural. Whoever you are asking has an account holder in front of them who appears, on their systems, to be the legitimate registrant. You are asking them to override their own customer. What moves them is a documented, dated chain: what the record said before, what changed, when, through which mechanism, and why the change was not authorized.
SSAC's SAC007, published on 12 July 2005 and still the reference taxonomy for hijacking, describes recoveries turning on exactly this. HZ.com, transferred without the owner's consent from AITdomains to QNIC/Directi in February 2005, was recovered after the owner noticed the change through a WHOIS query and produced documentation. The pattern has not changed in twenty years.
Route one: the registrar simply reverses it
The best outcome never becomes a dispute at all. Where the account was compromised but the name never left the registrar, the registrar restores the registrant and contact data, re-applies clientTransferProhibited — the EPP status flag that blocks outbound transfers until it is removed, EPP being the Extensible Provisioning Protocol registrars use to talk to registries — and secures the account.
Where a transfer is pending rather than complete, the Transfer Policy provides levers with short handles. A registrar may deny a transfer on grounds including evidence of fraud, a dispute over the registrant's identity, and express written objection by the authorized transfer contact. It must deny a transfer where there are UDRP proceedings, a court order, TDRP proceedings, a URS suspension, or a 60-day Change of Registrant lock in effect.
These are real, but they are perishable. The Registrar of Record has 24 hours to respond to a transfer request; the registry responds within five calendar days; and if the Registrar of Record stays silent the transfer is approved by default after five days. A denial ground you invoke on day seven is a denial ground you did not invoke.
Route two: TEAC escalation between registrars
Once the name is at another registrar, progress depends on two companies talking to each other. The Transfer Policy provides the channel: every accredited registrar maintains a Transfer Emergency Action Contact (TEAC), a contact for urgent transfer problems carrying a four-hour response requirement — the fastest escalation path in the entire policy framework.
Registrants routinely fail to use it because it is not theirs to use. The TEAC is registrar-to-registrar. The practical move is to ask your losing registrar, explicitly and by name, to escalate through its TEAC to the gaining registrar's TEAC, and to record the ticket reference when it does.
SAC007's Recommendation 4 asked registrars to make emergency support contact information available to other registrars, resellers and registry operators. perl.com's account of its own 2021 recovery described the effect in ordinary language: once everyone who needed to talk to each other had good contact information, the process mostly took care of itself. That is not a small observation. A large share of failed recoveries are contact-routing failures wearing the costume of a legal problem.
Route three: the TDRP
The Registrar Transfer Dispute Resolution Policy is the formal ICANN route for a transfer that violated the Transfer Policy. It was updated on 21 February 2024, with contracted parties permitted to implement from 21 August 2024 and required to implement by 21 August 2025.
Its shape constrains what it can do for you. The parties are registrars — a Losing Registrar alleging a fraudulent transfer, or a Gaining Registrar contesting an improper denial — so a registrant cannot file. Panel remedies are limited to approving the transfer or denying it, potentially ordering the return of already-transferred domains. There is no damages award and no mechanism aimed at a subsequent purchaser.
The filing deadline is twelve months after the alleged violation of the Transfer Policy, running from the transfer completion date or from the date a NACK — a transfer denial by the losing registrar — was received, depending on the complaint type. Complaints may go to an approved dispute-resolution provider or, for a registry-level dispute, to the registry operator itself. ICANN publishes the policy text.
Route four: courts, and the procedure that is not the answer
Where a name has been sold onward, where the current holder will not cooperate, or where no registrar will act, what remains is litigation. That is a matter for counsel qualified in the relevant jurisdiction, and nothing here is legal advice. The structural point is simply that registry and registrar systems act on court orders in a way they do not act on correspondence — and the Transfer Policy itself lists a court order among the grounds on which a registrar must deny a transfer, which makes an order useful defensively as well as offensively.
The procedure that is not the answer is UDRP. The Uniform Domain-Name Dispute-Resolution Policy addresses trademark abuse: names registered and used in bad faith to exploit someone else's mark. Its applicability to theft cases is disputed, and the mismatch is structural rather than tactical. A thief holding your exact name is not usually cybersquatting on a confusingly similar one. Assuming UDRP is the remedy is one of the most common and most costly errors in this area.
Why onward transfer is the hard case
Laundering is the standard second act of a domain theft, and it works. perl.com was compromised around September 2020, transferred from Network Solutions to BizCN in December with nameservers left unchanged so nothing appeared broken, moved onward to Key Systems, and listed for sale on Afternic at $190,000 while still stolen. The nameserver change was finally detected on 27 January 2021 by DNS monitoring — months after the compromise — and the name was recovered in early February.
Two lessons sit inside that timeline. The first is that leaving the DNS intact defeats the detection method most registrants actually rely on, which is noticing that the website stopped working. The second is that each hop adds a party who says they bought in good faith, and the argument changes from reversing one bad transaction into unwinding a chain of them.
The perverse detail is that ICANN's own locks can serve the thief. perl.com's account suggests the attackers updated contact information and renewed at the same time, timing the change against the 60-day transfer lock. Controls designed to slow an unauthorized transfer can equally slow the return.
The locks, and how they cut both ways
Four windows from the Transfer Policy shape nearly every recovery.
- 60 days from initial registration — a transfer may be denied within 60 days of the name being created.
- 60 days after a transfer — a name transferred within the last 60 days cannot be transferred again, with limited exceptions.
- 60-day Change of Registrant lock — the registrar must impose a 60-day inter-registrar transfer lock following a change to the registrant's identifying details, though an opt-out is available beforehand where the registrar offers one. Taking that opt-out for convenience removes a control that would otherwise stall a thief for two months; it is a bad trade on any name you care about.
- Five calendar days — a registrar without self-service must supply the AuthInfo code and remove
clientTransferProhibitedwithin five calendar days of a request, which is also how long a thief needs to wait.
These are under revision. ICANN's Public Comment Summary Report of 2 July 2025 on the Transfer Policy Review Working Group's Final Report records 47 policy recommendations, including reducing the 60-day post-creation and post-transfer restrictions to 30 days and eliminating the 60-day post-Change-of-Registrant restriction. Board adoption and implementation dates are listed as TBD, so treat the current rules as operative until they are not.
What a successful recovery actually looks like
Strip out the drama and the successful cases share a shape. Someone detects the change quickly, usually through monitoring rather than through a broken website. The registration record as it stood before the change is captured and preserved. The losing registrar accepts that this is a fraud matter rather than a customer dispute, and escalates through a named emergency channel with a four-hour obligation attached. Documentation of prior ownership is produced on request rather than assembled from scratch. Where necessary, a formal dispute is filed well inside the twelve-month window, or counsel obtains an order.
panix.com, transferred without authorization from Dotster to Melbourne IT via a reseller on 14 January 2005, remains the canonical case precisely because the harm was immediate and visible: the nameserver change caused loss of service for thousands of a New York provider's customers, which forced fast attention. HZ.com was recovered the following month on documentation. perl.com was recovered within weeks of detection, sixteen years later, by the same essential method.
The variable that changed the outcome in each was not the policy. It was how quickly someone noticed, and how well they could prove what the record used to say.