Recovery is possible, and the odds fall every day
A domain name is not property in the way a car is property. It is an entry in a registry database, and control of that entry moves through a chain of commercial parties: the registry (the operator of the top-level domain itself, such as Verisign for .com), the registrar (the company you buy and manage the name through), and sometimes a reseller selling under someone else's accreditation. Recovery means persuading, or compelling, the right party in that chain to put the entry back.
That framing explains almost everything about how recovery actually goes. There is no single authority you appeal to. There is a policy layer at ICANN, a contractual layer between registrars, and a legal layer above both — and each has its own clock. ICANN's Registrar Transfer Dispute Resolution Policy allows a dispute to be filed up to twelve months after the alleged violation of the Transfer Policy, so a formal remedy exists for a good while. But in my experience the practical window is far shorter than the policy window, because what closes a recovery is rarely the deadline. It is the third onward transfer, the sale to a claimed good-faith purchaser, and the registrant who spent six weeks emailing a support queue instead of escalating.
First, work out what was actually taken
Before anything else, separate two losses that look identical from the outside and are almost nothing alike underneath.
Theft of resolution means your DNS was changed — the A record that maps a hostname to an IP address, the MX record that tells other mail servers where to deliver your email, or the NS records (the delegation) that name which servers answer for your domain. The registration is still in your name. Gandi's July 2017 incident was this kind: attackers obtained Gandi's credentials for a technical partner's web portal and changed NS, MX and SPF records for 751 domains across 34 ccTLD and geographic TLDs between 08:04 and 09:44 UTC, and Gandi had everything reverted by 13:50 UTC the same day. Hours, not months.
Theft of registration means the record itself moved — a new registrant, a new account, or an inter-registrar transfer executed with your AuthInfo code (the password-like string that authorizes moving a domain between registrars). This is the hard case. perl.com was compromised around September 2020, transferred from Network Solutions to BizCN that December, moved onward to Key Systems, and listed for sale on Afternic at $190,000 while it was still stolen.
Diagnose this in the first hour. Every route that follows depends on the answer.
Route one: the registrar reverses it
The fastest recoveries never become disputes. If the name has not left the registrar — the account was compromised but the domain is still there — the registrar can restore the contact data, re-apply clientTransferProhibited (the EPP status flag that blocks outbound transfers until it is removed), and lock the account. EPP, the Extensible Provisioning Protocol, is the machine protocol registrars use to talk to registries; those status strings are what you see in a WHOIS or RDAP record.
If the name is mid-transfer, the Transfer Policy gives you leverage that expires quickly. The Registrar of Record must respond to a transfer request within 24 hours, the registry responds within five calendar days, and — this is the part registrants never believe — if the Registrar of Record simply does not respond, the transfer is approved by default after five days. Silence completes the theft. Express written objection by the authorized transfer contact is an explicit ground on which a registrar may deny a transfer, but only if it arrives before the clock runs out.
Route two: registrar-to-registrar escalation
Once the name has moved to another registrar, you are no longer a customer of the party that holds it. You are a stranger asking a company in another jurisdiction to take a valuable asset away from its paying account holder. This is where most self-directed recoveries stall.
The Transfer Policy anticipates it. Every accredited registrar maintains a Transfer Emergency Action Contact (TEAC) — a channel for urgent transfer problems, carrying a four-hour response obligation. The TEAC is registrar-to-registrar. You cannot use it yourself; you get your losing registrar to use it on your behalf, which is why the single most useful sentence in a first call is a request to escalate to the TEAC rather than to open a ticket.
SSAC's 2005 report SAC007, still the reference taxonomy for hijacking, recommended that registrars make emergency support contact information available to other registrars, resellers and registry operators, precisely because incidents fail on contact routing rather than on merit. perl.com's own account of its recovery said the same thing in plainer words: once everyone who needed to talk to each other had good contact information, the process mostly took care of itself.
Route three: the TDRP
The Registrar Transfer Dispute Resolution Policy (TDRP) is ICANN's purpose-built adjudication route for a transfer that should not have happened. It was updated on 21 February 2024, and contracted parties may implement the updated text from 21 August 2024 and must implement it no later than 21 August 2025.
Two things about it surprise almost everyone. First, you cannot file it. The parties are registrars: a Losing Registrar alleging a fraudulent transfer, or a Gaining Registrar contesting an improper denial. Your route runs through the registrar you lost the name from, which means your first job is convincing a company that already failed you to act as your advocate. Second, the remedies are narrow. A panel may approve the transfer or deny it, potentially ordering the return of already-transferred domains. It cannot award damages, cancel a sale, or reach a subsequent purchaser directly.
The filing deadline is twelve months after the alleged violation, running from the transfer completion date or the NACK receipt date depending on the complaint type. A NACK is a transfer denial — the losing registrar refusing the request. The policy text is published by ICANN.
Route four: the courts, and what UDRP will not do
Where a name has been sold onward, where the holder is uncooperative, or where the registrar declines to act, the remaining route is judicial. That is a matter for counsel qualified in the relevant jurisdiction, and this page does not attempt to advise on it. What is worth recording is the structural reason it comes up: registry and registrar systems respond to court orders in a way they do not respond to a well-argued email.
The recurring error is reaching for the wrong procedure. The Uniform Domain-Name Dispute-Resolution Policy (UDRP) is a trademark-abuse procedure. It asks whether a registrant registered and used a name in bad faith to exploit someone else's mark. Its applicability to outright theft is disputed, and it is a poor fit by design — a stolen domain is usually your own name being held by a thief, not a confusingly similar name registered to trade on your goodwill. Filing UDRP on a theft is not merely a detour. It burns weeks of a twelve-month TDRP window.
The other recovery: names lost to expiration
Not every lost domain was stolen. Many were simply not renewed, and the recovery path there is mechanical rather than adversarial — a fixed sequence of grace periods, each with a published length, after which the option disappears.
For .com, the Auto-Renew Grace Period runs 45 calendar days after expiration; the Redemption Grace Period (RGP) runs 30 calendar days after the registrar deletes the name, during which only the previous registrant can restore it, for a fee well above a normal renewal; and Pending Delete runs five calendar days during which nothing at all can be done. Those durations come from the .com registry agreement, not from the protocol: RFC 3915, which defines the grace-period status names, says explicitly that the duration of each grace period is a matter of registry operational policy that it does not address. Other TLDs differ, and ccTLDs sit outside ICANN consensus policy entirely.
The mistakes are boring and lethal. A renewal notice sent to a stale address. A card on file belonging to someone who left. A domain registered in a developer's name.
What actually forecloses recovery
The failure modes are consistent enough to list.
- Not noticing. perl.com sat hijacked from around September until a DNS-monitoring alert on 27 January. Detection, not policy, is the binding constraint.
- Using an email address at the domain itself as the registrant or administrative contact. perl.com's write-up names it directly: when you use the registered domain for your email contact, no one can contact you when that domain no longer handles your mail.
- Letting the contact-email domain expire. SAC007 documents attackers watching for exactly that, registering the lapsed domain, and receiving the confirmation mail for the target.
- Ignoring registrar notifications about contact changes or pending transfers.
- Onward sale. Each successive transfer adds a party claiming to have bought in good faith, and the argument shifts from "reverse this" to "unwind a chain."
- Letting the twelve-month TDRP clock expire.
The controls that decide the outcome before anything happens
Recovery is largely determined by decisions made months earlier. Multi-factor authentication on the registrar account, the DNS account and the email account behind them — CISA's Emergency Directive 19-01 requires it for federal agencies and notes that SMS-based MFA is not recommended. clientTransferProhibited kept on by default. Contact email on an unrelated, independently hosted domain. Treating the AuthInfo code as a short-lived secret: RFC 9154 says it should only be set when a transfer is in process, and unset values must be stored as NULL.
Above all, registry lock where it is offered. Verisign's Registry Lock Service covers .com, .net, .cc and .name, sets the registry-level statuses serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited, and requires that an authorized individual at the registrar be contacted by phone and supply a security phrase before the name is unlocked. That out-of-band step is what defeats account compromise, because the attacker inside your control panel cannot lift it. It is inconvenient by design, and the inconvenience is the product.
One trade-off worth stating plainly: WHOIS privacy on a portfolio you may one day need to prove ownership of is a real cost, not a free win. Redacted records make your own historical evidence thinner at the moment you need it most.