What it looks like from inside
Domain theft rarely announces itself as theft. The website stops loading, or begins loading something else. Email stops arriving, which usually goes unnoticed for an hour or two because nothing arriving looks the same as a quiet morning. Password resets for other services start failing. Somebody eventually checks the registrar account and finds they cannot log in, or logs in and finds the name is no longer there.
By that point the transfer has usually already completed. Registrar notification emails were sent to an address the attacker controlled, or to a mailbox on the domain itself, which stopped working at exactly the moment the notifications would have mattered. This is not incidental. Taking the mailbox first is the standard sequence, because the mailbox is where every confirmation goes.
Everything that follows is a function of speed and documentation. Recovery is not a technical problem to be solved cleverly; it is an evidentiary and procedural one, and the outcomes are decided by how quickly the right party received a request they could act on.
The first hours
In order, and in parallel where you have enough people.
- Preserve before anything else changes. Timestamped screenshots of the current state, full email headers from every registrar and platform notification, current registration records, the current DNS configuration, and the registrar account activity log if it is still reachable. This material starts disappearing on its own within days.
- Secure everything adjacent. The email accounts, the hosting account, the DNS provider, any other registrar accounts, and the password manager. Assume the same credentials are compromised everywhere and rotate them from a device you trust.
- Identify the losing registrar — the one that held the name before the transfer. A current lookup will show the gaining registrar; historical records and your own billing history show who held it before.
- Contact the losing registrar in writing, stating explicitly that the transfer was unauthorized and requesting an urgent reversal.
- Contact the gaining registrar with the same statement, so a further transfer or a sale is flagged before it happens.
- Notify counsel where the name is material to the business, because some of the remaining routes require a filing and filings take time to prepare properly.
Waiting to see whether it resolves itself is the one approach that reliably fails, and it is the most common first response.
The windows, and why they close
Several clocks start at once, and knowing them changes what you prioritize.
The reversal window at the losing registrar. A registrar that recognizes a transfer as unauthorized can act quickly, and its ability to do so is greatest in the days immediately after. This is the single fastest route available and it is the one most often missed because people spend the first day trying to work out what happened rather than reporting it.
The sixty-day transfer lock. Under ICANN's transfer policy a domain generally cannot be transferred again for sixty days after a change of registrar or registrant. That is a constraint on the attacker as much as on you, and it is a window in which the name is comparatively stationary. It is also why attackers frequently move to sell the name immediately rather than after — the sale can be agreed even while the transfer cannot yet complete.
The onward sale. The moment a name is sold to a third party who did not know its history, the matter becomes considerably harder, because there is now a party with a plausible claim to have acquired it in good faith. Getting the gaining registrar and any marketplace notified early is what prevents this.
Evidence retention. Hosting and content delivery logs are rotated on ordinary schedules measured in weeks. Registrar login records exist but are held by the registrar. Passive DNS and certificate observations are collected by third parties on their own timetables. If the material is not captured or formally requested early, some of it simply ceases to exist.
Proving the name was yours
Whoever decides — a registrar compliance team, a registry, a dispute panel or a court — needs a coherent ownership record presented so they do not have to assemble it themselves. Assume they will spend fifteen minutes on it, not an afternoon.
What establishes ownership: registration and renewal invoices with the name and dates visible; the registrar account history and the account's registered contact details; payment records tying the registration to your bank or card; use of the name in commerce, meaning invoices, contracts, marketing materials and correspondence over a period; trademark registrations where they exist; archived captures of the site as it operated under your control; and business filings or letterheads that reference the name.
Present it as a numbered exhibit list with a short covering narrative, in a single document. The most common reason a legitimate recovery request stalls is not that the evidence was weak. It is that it arrived as thirty attachments with no explanation and nobody had time to construct the story from them.
Reconstructing what happened
Ownership answers one question. The compliance team also needs to see that the transfer was unauthorized rather than disputed, and that is a separate reconstruction.
The materials are: historical registration records showing registrant and registrar before and after, with dates; DNS history showing when nameservers and mail records changed; the registrar's own notification emails with full headers intact, which frequently reveal where confirmations were actually delivered; hosting, mail and content delivery logs around the relevant period; evidence of the account compromise itself, such as unfamiliar login locations, a password reset you did not request, or a mobile carrier record showing a number was ported; and archived copies of the site before and after.
Build it as a timeline with timestamps in a single stated time zone. Note explicitly which entries are documented and which are inferred, because a request that overstates what it knows invites the compliance team to discount all of it. If the confirmation email went to an address that was created three days before the transfer, that single fact does more work than ten pages of argument.
The routes, in the order they should be tried
Registrar action
Fastest, cheapest and most often successful. The request should name the domain, state plainly that the transfer or registrant change was unauthorized, give the date it was detected, identify the losing and gaining registrars, attach the ownership exhibits and the timeline, and ask for a specific action rather than for help. Send it to the registrar's designated abuse or compliance address, keep it in writing, and follow up on a schedule.
Registry escalation
Where a registrar will not act or does not respond, the registry that operates the extension can. Registries maintain their own abuse and compliance channels and can place a name on hold, which stops it resolving and stops it moving while the matter is examined. That is not recovery, but it prevents the situation getting worse and it frequently produces engagement from a registrar that had been silent.
Transfer dispute resolution
ICANN's Transfer Dispute Resolution Policy exists specifically for transfers made without proper authorization. Its distinguishing feature is that it is filed by a registrar rather than by the registrant, which is precisely why it is underused — the people it would help have never heard of it and their registrar has no reason to mention it. Ask for it by name.
Why the UDRP is usually wrong here
The Uniform Domain-Name Dispute-Resolution Policy addresses registration and use in bad faith of a name confusingly similar to a trademark. A stolen domain was not registered in bad faith by the thief; it was registered legitimately by you and then taken, so the element the policy requires is missing. Filings that ignore this mismatch fail. The UDRP can fit where a mark is genuinely involved and the facts support it, but it is not the theft remedy people assume it is.
Court process
Where the routes above fail, litigation is what compels a registry to transfer a name back, including actions directed at the domain name itself rather than at a person who may be unidentifiable or beyond reach. It is slower and more expensive than everything above it, and it is sometimes the only thing that works.
When the name has already been sold
This is the situation that most often turns a recoverable matter into a litigated one, and there is still useful work to do.
Notify the marketplace or escrow service immediately and in writing. Transactions frequently sit in escrow for days, and a documented claim received before funds release changes what the intermediary is willing to do. Ask specifically for the transaction to be held pending resolution, and attach enough of the ownership record to make holding it the safer choice for them.
Where the sale has completed, the buyer's own diligence becomes the question. A purchaser who checked the name's history and bought through escrow stands in a considerably stronger position than one who bought a suddenly available premium name from an unknown seller at a price that made no sense. That asymmetry is worth documenting, because it is often what the eventual argument turns on. Meanwhile, keep monitoring: names taken this way frequently move again or resurface on another marketplace, and each event creates a new party to notify and a new record of the chain.
After recovery, and instead of it
Getting the name back is not the end. Restore in a deliberate order: confirm the registration is under an account you control with a clean contact address, apply locks before anything else, restore nameservers and DNS records from your own documented configuration rather than from whatever the attacker left, then restore mail routing, then the website. Check what was published on the name while it was gone, because content placed there is now attached to your record. Rotate every credential that touched the account, and review whether anything else was reached from the same mailbox.
I co-founded DNProtect with Rob Monster in 2020, building an automated version of the domain scoring algorithm I had developed, and served as its Director; DNProtect added stolen domain name recovery in 2021. By my own count — my figure, not an audited one — I have personally helped recover more than 500 stolen domain names. What that volume taught me is that these matters resolve on process rather than on cleverness. The recoveries that succeed are the ones where evidence was preserved early, the correct party was contacted first, and the request was specific enough that a compliance team could act without doing the investigation themselves.
Prevention is cheaper than all of it and it is mostly configuration: registry lock on the names the business cannot operate without, hardware-key two-factor authentication rather than text messages, an account email address hosted at a different domain, registration in the company's name rather than an individual's, and monitoring so an unauthorized change is noticed in hours. Stolen domain name recovery runs through DNAccess.