Domain Hijacked? How to Recover a Stolen or Transferred Domain

Your website shows someone else’s page, a parking page or nothing at all. Email stopped arriving. When you log in to your registrar, the domain is either gone from your account or its nameservers have been changed to ones you have never seen. Perhaps you found a “transfer completed” email in your inbox from days ago. That is a domain hijack: someone got control of the domain’s registration, or of the account that manages it, and changed where it points or who holds it.

This is stressful, because the domain carries both your website and your email, and the person who controls it can intercept password reset emails for every other service you use. It is also recoverable in many cases, especially if you act quickly and keep good records. This guide walks you through confirming what happened, stopping further damage, and escalating through the registrar, the transfer dispute process and ICANN. It is practical guidance, not legal advice. If the domain is very valuable or a criminal is extorting you, involve a lawyer early.

What is happening

A domain has three layers, and a hijacker can attack any of them.

Layer	What it controls	What a hijack looks like
Registration (at the registry, through a registrar)	Who holds the domain, which registrar manages it, and which nameservers are authoritative.	The domain was transferred to another registrar, or the registrant contact was changed to someone else.
Registrar account	The login you use to renew, unlock, change nameservers and get the transfer code (EPP or auth code).	Someone logged in as you, usually after taking over the email account that receives password resets.
DNS hosting	The records themselves: A, MX, TXT and so on.	Nameservers still look right, but records were edited at your DNS host, often MX records to steal email.

The most common route in is not a clever attack on the registrar. It is a compromised email account (reused or phished password, no two-factor), a phished registrar login, a former staff member or contractor who still has access, or a fake “domain verification” email that captured the login. Less often, a registrar or reseller is socially engineered into making the change.

Some situations look like a hijack but are not:

• The domain expired. RDAP shows a status such as redemptionPeriod or pendingDelete, or the registrar has pointed it at a renewal page. Follow the expired domain guide instead. If it expired, was deleted and someone else registered it, that is a lost domain rather than a stolen one; the dispute options are different and covered below.
• Someone you work with changed it. A designer, IT person or colleague moved DNS to Cloudflare or a new host and did not tell you. Ask around before you escalate. If a former designer holds the domain and will not hand it back, read getting your domain and logins back from a former web designer.
• Only the website is wrong. If the nameservers and registrar are unchanged and the site shows spam, the hosting or WordPress was hacked, not the domain. Start with WordPress site hacked: the first hour.

Step 1: Confirm what changed, and save the evidence

Before you call anyone, find out exactly which layer changed. You will be asked for this evidence, and some of it may disappear as the situation develops.

Run an RDAP lookup

RDAP is the modern replacement for WHOIS. Our domain lookup tool runs it for you and shows the registrar, the dates, the status codes and the nameservers. Take a screenshot, note the time, and save the output.

If you prefer the command line, run this on your own computer (Terminal on macOS or Linux, PowerShell on Windows, where you type curl.exe instead of curl):

curl -sL https://rdap.org/domain/example.com > rdap-example.com.json

Replace example.com with your domain. -s hides the progress meter, -L follows the redirect from rdap.org to the registry that runs your domain’s extension, and > saves the reply to a file you can attach to emails. Open it in any text editor. The fields that matter:

• Registrar name (in the entities section with the role registrar). If this is not your registrar, the domain was transferred.
• Events: last changed, transfer and expiration dates. A transfer event in the last few days dates the theft.
• Status: for example client transfer prohibited (lock on), pending transfer (a transfer is in progress right now) or server hold (the registry has suspended it).
• Nameservers: compare them with what you, your host or your DNS provider expect.

Most registrant names and emails are now redacted for privacy, so do not expect RDAP to tell you who took it. It tells you where it is and what changed, which is what the registrars need.

Check the live DNS

dig +short NS example.com
dig +short A example.com
dig +short MX example.com

Run these on your own computer (on Windows, use nslookup -type=NS example.com or our DNS lookup tool). +short prints only the answers. Compare the nameservers, the website IP address and the mail servers with what they should be. If the nameservers are unchanged but the A or MX records are wrong, the attacker is in your DNS host account rather than your registrar account, and Step 3 applies to that account.

A pending transfer is the best news you can get, because it may still be stopped. If RDAP shows pending transfer, skip ahead to Step 3 and contact your current registrar immediately.

Keep a written timeline

Start a document now with times (and time zone), what you saw, who you contacted and what they said. Save every relevant email with full headers, especially any “transfer requested”, “transfer approved”, “contact details changed” or “password changed” message from your registrar. These are often the strongest evidence that the change was not you.

Step 2: Lock down the email account first

If the attacker controls the mailbox where your registrar sends resets, every fix you make can be undone with one more reset. Secure that mailbox before you touch the registrar.

1. From a device you trust, change the mailbox password to a new, unique one.
2. Sign out all other sessions. Google accounts and Microsoft 365 both have a “sign out everywhere” option in their security settings.
3. Turn on two-factor authentication, preferably an authenticator app or security key rather than SMS.
4. Check for forwarding rules, filters that delete or archive registrar mail, and recovery email addresses or phone numbers you do not recognize. Attackers add these to stay hidden. Our guide to an email account that has been hacked lists where to look in each provider.
5. If the mailbox is on the hijacked domain itself (for example you@example.com) and MX now points elsewhere, you may not be able to receive mail there at all. Give the registrar a different address that you control, such as a personal Gmail or Outlook account, and say why.

Then do the same for your password manager, your hosting account and any account that uses the same password. Assume anything sharing a password with the compromised account is also exposed.

Step 3: Contact your registrar, in writing, today

Your registrar (the “registrar of record” before the theft, sometimes called the losing registrar) is the party that can act fastest. Look for a page called abuse, security, domain disputes or transfer disputes, or use the support ticket system. A ticket gives you a reference number and a written record.

If you can still log in

• Change the account password, turn on two-factor, and remove any users, API keys or authorized contacts you did not add.
• If a transfer is pending, look for a transfer approval or rejection screen. Many registrars let the registrant reject an outgoing transfer during the pending period, which under the current ICANN Transfer Policy is typically up to five days before the registry completes it automatically.
• Put the nameservers back to the correct values and turn the registrar lock (transfer lock) on.
• Check the registrant contact details and correct them if they were changed. Be aware that changing the registrant’s name, organization or email can trigger a transfer lock at many registrars; in this situation that lock works in your favor.

If you are locked out

Use the registrar’s account recovery process. Expect to prove who you are: registrars commonly ask for photo ID, the payment card or invoice used for the domain, the account number, and for a business, documents that match the organization named on the registration. Ask specifically for the account to be frozen while they investigate.

What to send

Keep it short and factual. Include:

• the domain name and your account number or customer ID;
• what changed and when (the RDAP output and DNS results from Step 1);
• a clear statement that you did not authorize the change or transfer;
• evidence that you are the registrant: invoices, renewal receipts, past registrar emails, and business records that match;
• a request to restore the previous nameservers, reverse or dispute the transfer, and place the domain on hold until it is resolved;
• a safe contact address that is not on the affected domain.

If the domain moved to another registrar

Your old registrar can contact the new (gaining) registrar directly and ask for the transfer to be reversed. Registrars can agree to undo a fraudulent transfer between themselves. You can also open a ticket with the gaining registrar’s abuse team, identified in the RDAP output, and report that a domain was transferred into their system without the registrant’s consent. Ask both sides to stop any further transfer or change while they talk. A hijacker often moves a stolen domain quickly to put distance between it and you, so speed matters.

Step 4: Know the formal escalation routes

If the registrars do not resolve it, there are formal processes. Which one applies depends on what happened.

Route	Use it when	Who files	Notes
Transfer Dispute Resolution Policy (TDRP)	The domain was transferred between registrars in breach of the ICANN Transfer Policy, for example without valid authorization.	A registrar, not the registrant. You ask your old registrar to file.	Must be filed within 12 months of the alleged violation, with an ICANN approved dispute provider. Applies to generic domains such as .com, .net and .org.
ICANN Contractual Compliance complaint	An ICANN accredited registrar is not responding, will not give you the transfer code, or is not following its obligations.	You, through ICANN’s online complaint forms.	ICANN does not decide who owns a domain or reverse transfers itself, but it can require a registrar to follow the policies.
Uniform Domain Name Dispute Resolution Policy (UDRP)	Someone holds a domain matching your trademark in bad faith, for example a domain you let expire that was registered by someone else to exploit your name.	The trademark holder, with an approved provider such as WIPO.	You must prove three things: the domain is identical or confusingly similar to your mark, the holder has no legitimate interest, and it was registered and used in bad faith. Remedies are transfer or cancellation. Fees apply.
Courts and police	Theft, extortion, fraud, or high value.	You, usually through a lawyer.	A court order binds the registrar. Report fraud to the police or the national cybercrime reporting service in your country; your government’s official website names the right one.

Country code domains (.uk, .ca, .au, .de and so on) follow their own registry’s rules, not ICANN’s Transfer Policy or TDRP. Contact the registrar first, then the registry itself: many country registries have their own complaint and dispute processes, such as Nominet’s Dispute Resolution Service for .uk.

The domain lifecycle and transfer cheat sheet summarizes the locks, status codes and dispute routes in one table.

Step 5: Limit the damage while you wait

Recovery can take days or longer. In the meantime, assume the attacker can receive email sent to your domain and can get certificates issued for it.

• Tell people. Warn customers and suppliers, through channels that do not depend on the domain (social media, a phone script for staff, a notice from a personal email address), not to trust emails or payment instructions from your domain until further notice.
• Move password resets. For banking, payment processors, hosting, Google, Microsoft, social media and any service registered with an address on the domain, change the login email to one you control elsewhere. Otherwise the attacker can reset those passwords too.
• Watch for certificates. Certificates issued for your domain appear in public Certificate Transparency logs. Our subdomain finder searches those logs; a new certificate from an issuer you do not use is a sign the attacker is running a site on your name.
• Payment and ad accounts. If the domain is used for a store, tell your payment provider. If you run ads, pause them so you are not paying to send traffic to the attacker.
• Keep the hosting. Do not cancel your hosting or delete the site. When DNS is restored, you want everything to come back exactly as it was.

Step 6: After you get it back

When the registrar restores the domain to your account, do these before you relax:

1. Confirm with RDAP that the registrar, registrant details and nameservers are correct, and that client transfer prohibited is showing.
2. Check the DNS zone record by record against a known good copy: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC and verification records) and CAA. If you have no copy, our guide on setting DNS records for a website and email at different providers explains what each should be.
3. Check DNSSEC. If the attacker changed nameservers, an old DS record can make the domain fail to resolve for validating resolvers. Run dig +short DS example.com and compare with what your DNS host shows on its DNSSEC screen.
4. Rotate every password and API key that was sent to or reset through the domain’s email during the incident.
5. Remove any verification records the attacker added (for example a TXT record that verifies the domain in their Google or Microsoft account), and check Google Search Console and your email provider’s admin console for owners you did not add.
6. Write up what happened and how they got in. If it was a compromised email password, that is the thing to fix permanently.

Prevent it happening again

• Two-factor on the registrar account and on its reset email. This alone stops most hijacks.
• Registrar lock on. The status clientTransferProhibited blocks transfers until someone logged in to your account removes it.
• Registry lock for critical domains. Some registrars offer registry lock, which sets server level statuses (serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited) that can only be removed through a manual, out of band verification. It usually costs extra and is not available for every extension, so ask your registrar about availability and price.
• A registrant email off the domain. If your domain breaks, you still receive the registrar’s warnings and approval requests.
• Keep the contact details accurate. Registrars accredited under ICANN’s 2013 agreement must verify the registrant’s email or phone number after registration, transfer or a contact change, and may suspend a domain if verification is not completed in time. A real verification email is a good thing; just verify it by logging in to the registrar directly, not by clicking a link, because fake verification emails are a common phishing lure. See our guide to scary website emails.
• Keep the domain in the business’s own account. Not a designer’s reseller account, not a former employee’s personal account. When you take over a site, follow the inherited site takeover playbook.
• Monitor it. A weekly RDAP and NS check, or an alert from a monitoring service, catches changes before your customers do.

If none of that worked

If your registrar refuses to act or does not reply within a few business days, file an ICANN Contractual Compliance complaint about the registrar and ask your registrar in writing to file a TDRP complaint. If the domain carries significant revenue or a trademark, speak to a lawyer who handles domain disputes; they can send formal demands to both registrars and, if needed, seek a court order. Keep adding to your timeline: dates, ticket numbers and copies of every reply.

When you send a request to any registrar or to ICANN, include the domain, the RDAP output from before and after the change (if you have an older copy, from a past invoice, screenshot or monitoring alert, include it), the date you noticed, the transfer or change emails with headers, and proof that you are the registrant. For related problems, see transferring a domain to a new registrar without downtime, DNS changes not showing up and the locked out or lost access triage page.