Domain or DNS hijacked: how to take your domain back

Updated November 2026

If your website or mail suddenly goes somewhere else, someone may have changed your DNS records, your name servers or the domain’s owner. Speed matters: the longer the attacker holds the domain, the more mail they can read and the more certificates they can get. Contact your registrar first, then secure every account that can change DNS.

Do this first.

Contact your registrar’s support and abuse team now, by phone if they offer it. Say the domain was changed without permission and ask them to freeze it.
Try to log in to the registrar and DNS host accounts. If you still can, change the passwords, turn on two-factor authentication and remove unknown users and API keys.
Save evidence: screenshots, whois and dig output with dates, and every email from the registrar.
Tell your users not to log in or send sensitive mail to the domain until it is fixed.

Signs of a hijack

The site shows someone else’s content, a phishing page or a parked page, but your server has not changed.
Mail stops arriving, or arrives at a server you do not run (changed MX records).
The registrar sent emails about a password reset, a contact change or a transfer you did not request.
whois shows a different registrar, registrant or name servers.
Certificate transparency logs show certificates for your domain that you did not order.

Some outages look similar but are not attacks: an expired domain, an unpaid DNS plan, or a colleague’s change. Check the expiry date and your own change records quickly before you escalate, but do not wait long.

Step 1: find out what changed

There are three levels. Each needs a different fix.

Records changed at your DNS host: The name servers are still yours, but A, MX or TXT records point elsewhere. Someone got into your DNS host or hosting panel account.
Name servers changed at the registrar: The domain now uses the attacker’s DNS servers. Someone got into your registrar account.
Domain transferred or owner changed: The domain is at another registrar or under another name. This is the most serious case.

# Registrar, status codes, dates and name servers
whois example.com | grep -i -E 'registrar:|status|name server|updated|expir'

# Delegation as the parent zone (.com, .org ...) sees it
dig +trace example.com NS

# What your own DNS servers answer
dig @ns1.your-dns-host.example example.com A +short
dig @ns1.your-dns-host.example example.com MX +short

# What the public sees
dig example.com A +short
dig example.com MX +short

ICANN Lookup (lookup.icann.org) shows the same registration data in a browser. If the delegation from +trace lists name servers you do not recognize, the change was made at the registrar.

Step 2: get the registrar on your side

ICANN’s advice is to contact the registrar immediately: if you wait, the domain can be transferred again and again, which makes recovery harder. Find your registrar with ICANN Lookup or the whois output. For an unauthorized transfer, contact the registrar the domain was moved away from.

The registrar will ask you to prove you are the rightful holder. ICANN suggests gathering:

Registration records and registrar emails (renewal notices, change notices) showing you as the holder.
Invoices, receipts, and bank or card statements for the domain.
Server or web logs and archives that link the domain to your content.
Business records that name the domain, such as contracts or tax filings.

If the domain moved to another registrar, the registrar may be able to start a case under the Transfer Dispute Resolution Policy. If the registrars do not help, you can file an Unauthorized Transfer Complaint with ICANN. ICANN cannot force a registrar to give the domain back, and it does not investigate crimes. For that, talk to a lawyer and to the police. The UDRP and URS procedures only apply to trademark cases.

Step 3: secure the accounts

Reset the password of the email account that receives registrar mail first. Attackers often get in through it.
Reset the registrar, DNS host, CDN and hosting panel passwords; use a password manager.
Turn on two-factor authentication everywhere, preferably with an app or security key rather than SMS.
Remove unknown users, API tokens, SSH keys and forwarding rules.
Restore the correct name servers and records from your own notes or zone file backup.

Treat this as a credentials breach: see Leaked credentials.

Step 4: check DNSSEC

DNSSEC adds digital signatures to DNS data. A validating resolver checks that answers really came from your zone and were not changed on the way, and returns an error if they do not validate. The parent zone (for example .com) holds a DS record that links to your zone’s key; this is the chain of trust.

# Is there a DS record at the parent?
dig example.com DS +short

# Validate the answer (delv ships with BIND tools: bind9-dnsutils / bind-utils)
delv example.com A

DNSSEC protects against forged answers, but not against someone who controls your registrar account: they can change the name servers and remove or replace the DS record. After a hijack, check that the DS record matches the key your DNS host shows. If the attacker added a DS record of their own and you restore your name servers, validating resolvers will reject your zone until the DS record is corrected at the registrar.

Step 5: look for rogue certificates

Publicly trusted certificates are recorded in certificate transparency (CT) logs; Chrome and Safari reject certificates that are not logged. While attackers controlled your DNS, they could get valid certificates for your domain. Search the logs with crt.sh:

curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
  | jq -r '.[] | [.not_before, .issuer_name, .name_value] | @tsv' | sort | tail -n 30

Any certificate issued during the hijack that you did not order should be revoked. For Let’s Encrypt certificates, prove control of the names again (any ACME client does this), download the certificate from crt.sh and run:

sudo certbot revoke --cert-path /path/to/downloaded-cert.pem

For other certificate authorities, use the problem reporting contact on their website. Then add a CAA record so that only the CAs you use may issue for your domain, for example example.com. CAA 0 issue "letsencrypt.org".

Work from the top of the chain (registrar) down to the records and certificates.

Step 6: lock it down

Registrar lock. Ask for clientTransferProhibited (blocks transfers), and where offered clientUpdateProhibited and clientDeleteProhibited. These show as status codes in whois.
Registry lock. Some registries offer a lock set at registry level (serverUpdateProhibited, serverTransferProhibited, serverDeleteProhibited). It adds protection beyond the registrar lock, because removing it needs action at the registry as well as the registrar. Ask your registrar whether it is available for your domain and what it costs.
Contacts. Keep registrant and admin email addresses current, on a different domain than the one they protect.
Renewal. Turn on auto-renew and note the expiry date.
Monitoring. Alert on changes to NS, MX and A records and on new certificates in CT logs.

Confirm it is fixed

dig +trace shows your name servers, and public answers match your zone.
whois shows your registrar, your details and the lock status codes.
delv validates (if you use DNSSEC).
No unknown certificates remain unrevoked on crt.sh.
Mail flows normally and no unknown MX or forwarding remains.

When to get help

If the domain was transferred to another registrar or owner, or if customer data or mail was exposed, involve a lawyer and an incident response firm, and check your legal duties in Personal data breach. If the attacker put a phishing site on your domain, see Phishing on your server.