Domain Name Theft

What is actually stolen

Domain name theft is the loss of control of a registered domain to someone else in a way that looks permanent. The registration record itself moves — into a thief's account, or to a thief's registrar (the company you buy and manage a domain through) — so the original registrant no longer appears as the owner and can no longer manage the name. The site may still load. Mail may still flow for weeks. What has changed is the answer to the only question that finally matters: who the registry (the operator of the top-level domain itself, such as Verisign for .com) believes owns it.

Underneath the word theft there is a technical distinction that decides almost everything about how the next month goes. Theft of the registration means the registrant record or the sponsoring registrar changed — an EPP transfer, where EPP is the Extensible Provisioning Protocol, the machine protocol registrars use to talk to registries. Theft of resolution means only the nameservers or DNS records changed, and the registration record is untouched. Gandi's July 2017 incident was the second kind: 751 domains across 34 country-code and geographic top-level domains had nameservers, MX and SPF records changed through a compromised technical-partner portal login, with no change of registrant at all. The difference is not academic. A resolution-layer takeover is reversed by whoever still controls the account; a registration-layer theft has to be unwound through registrars and registries.

How the registration actually moves

ICANN's Security and Stability Advisory Committee documented the mechanics twenty years ago in SAC007, Domain Name Hijacking: Incidents, Threats, Risks, and Remedial Actions (12 July 2005), and the taxonomy has aged well. The recurring mechanisms:

• Registrar-account credential compromise. The thief logs into the registrant's account with a phished, reused or stolen password, changes the contact email, removes the lock and pushes the name out. SAC007 records attacks built on credential theft targeting public WHOIS information.
• Social engineering of registrar support staff. SAC007 describes an attacker who was able to socially engineer a first-tier customer support agent into making a change to an administrative contact email account. The 2021 perl.com theft was attributed, in the maintainers' own account, to a social engineering attack on the registrar involving phony documents.
• An expired administrative-contact domain. The attacker watches for the domain used in the admin-contact email address to expire, registers it, and simply receives the authentication and confirmation mail sent for the target domain.
• Weaponizing ICANN's own locks. The perl.com account describes attackers who appear to have updated contact information and renewed at the same time, timing the sequence against the 60-day transfer lock.
• Laundering. The name is transferred onward between registrars and listed for sale, manufacturing a good-faith-purchaser argument.

Note what is absent: none of this is a protocol flaw. Every one is an authorization failure at a human or account boundary. What you do in the first few hours decides most of what follows; the steps that preserve evidence and the steps that destroy it look very similar from the inside.

The contact email is the real target

Almost every documented theft runs through the registrant's email rather than through the domain itself. The registrar account resets by email. The Form of Authorization — the standard confirmation a gaining registrar must obtain before a transfer completes — arrives by email. Contact-change notices arrive by email. Control the mailbox and you control the name.

Which is why using an email address at the domain itself as the registrant or admin contact is a bad idea, and I will state that flatly rather than hedge it. The perl.com write-up puts the failure mode precisely: when you use the registered domain for your email contact, no one can contact you when that domain no longer handles your mail. The theft severs your own notification channel as a side effect of succeeding. SAC007's expired-contact-domain pattern is the same weakness in slower motion.

The corollary is unglamorous: registrant and administrative contact email should live on a separate, independently hosted domain, and that address should be checked by a human who knows what a transfer notice looks like.

The clocks that govern everything

Domain theft is a deadline problem more than a technical one. Under the ICANN Transfer Policy, these are the intervals that decide outcomes:

• 4 hours — the response requirement for the Transfer Emergency Action Contact (TEAC), a registrar's urgent registrar-to-registrar channel for exactly this situation.
• 24 hours — the Registrar of Record's response requirement on a pending transfer.
• 5 calendar days — the registry's response window, and the point at which a silent Registrar of Record produces default approval. A transfer can complete because nobody objected.
• 5 calendar days — the window in which a registrar without self-service must supply the AuthInfo code (the password-like string that authorizes moving a domain to another registrar) and remove clientTransferProhibited, the EPP status flag that blocks outbound transfers.
• 60 days — a transfer may be denied within 60 days of initial registration; a name transferred within the last 60 days cannot be transferred again; and a registrar must impose a 60-day inter-registrar transfer lock following a Change of Registrant, which is a change to the registered owner's identifying details.
• 12 months — the deadline to file under the Registrar Transfer Dispute Resolution Policy.

The 4-hour and 12-month figures sit at opposite ends of the same problem: how fast the system moves when someone escalates correctly, and how long you have before it stops listening.

Who can actually ask for the domain back

Here is the part that surprises registrants and, in my experience, surprises retaining attorneys more. The Registrar Transfer Dispute Resolution Policy (TDRP), updated 21 February 2024, is a dispute between registrars. The parties are a losing registrar alleging a transfer in violation of the policy, or a gaining registrar contesting an improper denial. The registrant is not a party. A dispute must be filed no later than twelve months after the alleged violation, and the panel's remedies are narrow: approve the transfer, or deny it, potentially ordering the return of already-transferred domains.

So the registrant's practical route runs through the losing registrar — persuading it that a transfer it processed was fraudulent, and asking it to escalate through TEAC and, where warranted, to file. That is a very different task from filling in a complaint form, and it is why documentation of prior ownership matters so much at the moment of loss.

It is also why the reflex to file a UDRP is usually wrong. The Uniform Domain-Name Dispute-Resolution Policy is a trademark-abuse procedure; its applicability to outright theft is disputed. A stolen domain with no trademark story behind it does not become a UDRP case because a UDRP is the procedure you have heard of. Where litigation is the realistic path, that is counsel's call.

Why every week makes it worse

A remedy existing for twelve months does not mean the odds hold steady for twelve months. They do not. Each onward transfer and each purported sale adds a party who says they bought the name in good faith, and another registrar — possibly in another jurisdiction — whose cooperation you now need.

perl.com is the instructive record. Compromised around September 2020, transferred from Network Solutions to BizCN in December, then onward to Key Systems, with nameservers left unchanged so that nothing visibly broke. The nameserver change that finally exposed it was detected on 27 January 2021 and the domain was recovered in early February. While stolen, it was listed for sale on a major aftermarket with a six-figure asking price.

Detection took months; recovery, once the right people at each registrar were talking, took days. That ratio is the lesson: the expensive part of a domain theft is rarely the procedure.

What actually prevents it

The controls that hold up are the boring ones, and they are cheap relative to what they protect:

• Multi-factor authentication on the registrar account, and not by SMS. CISA's Emergency Directive 19-01 requires agencies to implement multi-factor authentication for all accounts on systems that can change DNS records, and notes explicitly that SMS-based MFA is not recommended.
• Registrar lock left on by default. clientTransferProhibited costs nothing and stops the single most common completion step. SAC007's first recommendation is that registries ensure Registrar-Lock and EPP authInfo are implemented to specification.
• Contact email on an unrelated, independently hosted domain, for the reasons above.
• Treating the AuthInfo code as a short-lived secret. RFC 9154 is explicit that authorization information should only be set when a transfer is in process, that the registrar must inform the registrant of its time-to-live when it is provided, and that unset values must be stored as a NULL value.
• Certificate Transparency monitoring. CT logs are public, append-only records of every TLS certificate issued, searchable by domain; watching them catches an attacker who has obtained a certificate for your name.
• Independent DNS and WHOIS change monitoring, run outside the registrar account that could itself be compromised.

Two failure modes recur regardless of controls: ignoring registrar notification email about contact changes, and waiting past the twelve-month filing window because the matter felt like it was still being handled.

A policy in motion

The 60-day locks described above are under active revision. ICANN's Public Comment Summary Report on the Transfer Policy Review Working Group Final Report, dated 2 July 2025, records that the Final Report included 47 policy recommendations, that the working group recommended reducing the 60-day post-creation and post-transfer restrictions to 30 days, and that it also recommended eliminating the 60-day post-Change-of-Registrant transfer restriction.

Process status, per ICANN's own project page: Final Report submitted 5 February 2025, GNSO Council adoption 12 March 2025, Council report to the Board 10 April 2025. The Board resolution and the implementation details are both still listed as TBD.

So the honest position is this: the direction of travel is clear, the effective date is not, and the 60-day rules remain in force until the Board acts. Plan against the current text.

Frequently Asked Questions