
What Is Domain Hijacking, and How Do You Prevent It?
Your domain name is the root of trust for almost everything your business does online. Your website, your email, your password reset links, your SSL certificates, and your customers' bookmarks all depend on it. If someone else gains control of the registration, they control all of that at once, and getting it back can take weeks. That is domain hijacking, and it is one of the most damaging and least prepared-for incidents a site owner can face. This article covers how domain hijacking happens, what attackers do once they have a domain, and a full prevention and recovery playbook. If you are fuzzy on who controls what, start with the difference between a domain registrar and a DNS host, because hijacking is fundamentally an attack on the registrar side.
What Is Domain Hijacking?
Domain hijacking is the unauthorized takeover of a domain name registration. The attacker gains control of the domain itself, usually by taking over the account at the registrar, transferring the domain to a registrar they control, or changing the registrant contact so the domain legally appears to be theirs.
It is worth separating this from a related term. DNS hijacking is about redirecting DNS answers, for example by tampering with a resolver, a router, or the records in a zone. Domain hijacking goes one level higher: the attacker controls the registration, so they can change the name servers, the contacts, and even who legally holds the domain. DNS hijacking can be a consequence of domain hijacking, but domain hijacking is the bigger loss because it can persist even after you fix your DNS.
How Domain Hijacking Happens
Attackers rarely break cryptography to steal domains. They go after people, accounts, and processes.
1. Registrar Account Compromise
The most common route is simply logging in as you. Attackers get the password through phishing pages that imitate registrar login screens, credential stuffing with passwords leaked from other sites, or malware that steals saved browser credentials. If the account has no multi-factor authentication, a password is all they need.
2. Taking Over the Registrant Email
The email address on your registrar account is the master key, because password resets go there. Attackers target it in several ways:
- Compromising the mailbox with phishing or reused passwords.
- Exploiting an expired email domain. If your registrar account uses
admin@old-agency-example.comand that domain lapses, anyone can register it, set up a mailbox, and request a password reset. - Circular dependency. If the account email is on the same domain being protected, an attacker who briefly controls the domain's MX records can intercept reset emails for the registrar account itself.
3. Social Engineering the Registrar
Some hijackings involve no technical compromise at all. Attackers call or chat with registrar support, impersonate the owner with convincing details gathered from public sources, and talk an agent into changing the account email, resetting MFA, or releasing a transfer authorization code.
4. Unauthorized Transfers
Once an attacker has the account, or the transfer authorization code, they can move the domain to a registrar where you have no account. That makes recovery much harder, because your original registrar no longer controls it and the gaining registrar has no relationship with you.
5. Expiration and Drop Catching
Not every loss is a hijack in the criminal sense, but the result is the same. A domain that is not renewed goes through grace and redemption periods and is eventually released. Automated drop-catching services register valuable expiring names the moment they become available. Expired payment cards, outdated billing contacts, and renewal emails sent to a mailbox nobody reads are the usual causes.
6. Insider and Vendor Risk
Domains are often registered by a former employee, a web agency, or a contractor in their own account. When that relationship ends badly, or simply ends, you may discover that you never controlled the domain in the first place.
What Attackers Do With a Hijacked Domain
Once they control the registration, attackers can:
- Change the name servers to their own and serve any DNS records they want. See what an NS record is for how delegation works and why this is so powerful.
- Intercept email by publishing their own MX records, which lets them receive password resets for every service tied to your domain.
- Issue valid SSL certificates. Certificate authorities validate control of the domain, and the attacker now has it, so browsers will show a padlock on their phishing site.
- Ransom the domain back to you, or sell it.
- Damage your reputation with malware, spam, or defacement served from your brand.
The speed matters. An attacker with access to your account can change name servers in seconds, and the change can be visible worldwide within the TTL of your delegation at the TLD.
The Domain Hijacking Prevention Playbook
Treat this as a checklist. Each layer covers a different attack route.
Lock Down the Registrar Account
- Use a registrar that takes security seriously. Look for hardware security key support, account-level audit logs, role-based access, and registry lock availability.
- Enable strong multi-factor authentication. Prefer hardware security keys or passkeys over SMS, which is vulnerable to SIM swapping.
- Use a unique, long password stored in a password manager.
- Remove stale users and give team members their own accounts with the minimum permissions they need, instead of sharing one login.
- Set a support PIN or verbal password if your registrar offers one, to make social engineering harder.
Protect the Account Email
- Use a dedicated address for the registrar account, protected with its own MFA.
- Host it on a different domain from the one being protected, so a DNS change on the protected domain cannot intercept reset emails.
- Make sure that email domain is also renewed and locked. Many hijackings start with a forgotten domain used only for contact addresses.
Lock the Domain Itself
- Turn on registrar lock (the
clientTransferProhibitedfamily of EPP statuses) so transfers and changes are blocked until you unlock them. The details of every status code and how to verify them are in what registrar lock is and why you should enable it. - Use registry lock for critical domains. Registry lock is enforced at the TLD registry and requires out-of-band verification to remove, so a compromised registrar account alone is not enough.
- Keep the transfer authorization code secret. Never paste it into tickets or chat, and request a new one if it has been exposed.
Prevent Expiration
- Enable auto-renew and keep a valid payment method on file.
- Register critical domains for several years at a time.
- Calendar the expiry dates for your whole portfolio, independently of the registrar's reminders.
Harden What Sits on Top of the Domain
- Enable DNSSEC. It does not stop someone with registrar access from changing your name servers, but it prevents many lower-level DNS tampering attacks. See DNSSEC and whether you should enable it.
- Publish CAA records to limit which certificate authorities can issue for your domain. An attacker who changes the name servers can override this, but it blocks attackers who can only add records. See what a CAA record is.
- Monitor Certificate Transparency logs for certificates issued for your domain that you did not request.
Keep an Inventory
Maintain a list of every domain you own, which registrar it is at, which account holds it, the account email, the expiry date, and the lock status. Domains you forgot about are the ones that get lost.
How to Monitor for Signs of a Hijack
Detection speed determines how much damage a hijacker can do. Monitor the registration and delegation data, not just whether your website is up.
Check the Registration Status with RDAP
RDAP is the structured, JSON-based successor to WHOIS. The public bootstrap service at rdap.org redirects to the right registry server for most TLDs:
curl -sL https://rdap.org/domain/example.com \
| jq '{status: .status, nameservers: [.nameservers[].ldhName], events: .events}'
This prints the domain's current status codes, its delegated name servers, and events such as the last changed and expiration dates. A sudden change in name servers, or a missing transfer-prohibited status, is a red flag.
Check the Delegation at the TLD
Your DNS host's dashboard shows what you want to be published. The TLD servers show what is actually delegated. Ask a .com TLD server directly, without recursion:
dig NS example.com @a.gtld-servers.net +norecurse
The authority section of the response lists the name servers the registry is currently handing out. If they are not yours, the domain has been changed at the registrar level. For other TLDs, find the right servers with dig NS org +short or the equivalent for your TLD.
Automate an Alert
This Python script, using the dnspython library, compares the live name server set against the one you expect and exits with an error if they differ, which makes it easy to run from cron or a monitoring system:
import sys
import dns.resolver
EXPECTED = {
"example.com": {"ns1.example-dns.net.", "ns2.example-dns.net."},
}
failed = False
for domain, expected_ns in EXPECTED.items():
try:
answer = dns.resolver.resolve(domain, "NS")
live_ns = {rr.target.to_text().lower() for rr in answer}
except Exception as exc:
print(f"[ERROR] {domain}: lookup failed: {exc}")
failed = True
continue
if live_ns != expected_ns:
print(f"[ALERT] {domain}: expected {sorted(expected_ns)}, got {sorted(live_ns)}")
failed = True
else:
print(f"[OK] {domain}")
sys.exit(1 if failed else 0)
Install the dependency with pip install dnspython, fill in your domains and name servers, and schedule it every few minutes. Pair it with alerts on registrar account logins and on the RDAP status codes, and you will usually know about a hijack within minutes rather than days. For broader DNS monitoring ideas, see how to monitor DNS uptime and performance.
What to Do If Your Domain Is Hijacked
Act fast, and in this order:
- Contact your registrar's abuse or security team immediately. Use the phone if possible. Ask them to freeze the domain and the account.
- Secure the email account tied to the registrar and reset its password and MFA.
- If the domain was transferred away, your original registrar can open a dispute with the gaining registrar. For gTLDs, ICANN's Transfer Dispute Resolution Policy provides a formal process when registrars cannot resolve it between themselves.
- Gather evidence: registration history, invoices, screenshots of the account, and RDAP or WHOIS records from before the change.
- Warn your users and staff that email and the website may be compromised, and do not trust password reset emails sent during the incident.
- Revoke certificates issued during the hijack and rotate credentials for any service that sends reset links to your domain.
- File a complaint with ICANN if the registrar is unresponsive, and involve law enforcement for significant losses.
Afterwards, go back through the prevention playbook and close whichever gap was used.
Domain Hijacking FAQ
Domain hijacking is the takeover of the domain registration itself, usually through the registrar. DNS hijacking redirects DNS answers without necessarily changing who owns the domain, for example by tampering with a resolver or router. Domain hijacking is broader because the attacker can change everything, including the name servers.
Often, yes, especially if you act quickly and have evidence of ownership. Recovery is easiest when the domain is still at your registrar. If it was transferred to another registrar, the dispute process can take days or weeks.
It blocks unauthorized transfers and, depending on the statuses used, updates and deletions. But anyone who logs into your registrar account can usually turn it off, so it must be paired with strong account security. Registry lock adds a stronger, out-of-band layer.
No. An attacker who controls the registration can change the name servers and remove or replace your DNSSEC records at the registry. DNSSEC protects against forged DNS answers, not against someone with legitimate registrar access.
If the account email is on the domain being protected, an attacker who gains temporary control of that domain's DNS can receive the registrar's password reset emails and lock you out permanently. Keeping it on a separate, well-protected domain breaks that loop.
Technically no, because nobody broke in. In practice the result is similar: someone else ends up owning the domain. Auto-renew, multi-year registration, and an up-to-date payment method prevent it.
Log into the registrar account that holds it and check the registrant contact. If an agency, developer, or former employee registered it in their own account, ask them to move it into an account your organization controls.
Yes. Small businesses are often easier targets because they use shared logins, no MFA, and personal email addresses on registrar accounts. The basic protections are free and take less than an hour to set up.
Conclusion
Domain hijacking is rarely a sophisticated hack. It is usually a stolen password, a forgotten email domain, a persuasive phone call, or a renewal nobody noticed. That is good news, because each of those has a straightforward fix: strong MFA on the registrar account, a protected account email on a separate domain, registrar and registry locks, auto-renew, and monitoring that tells you the moment your delegation changes.
Spend an hour working through the playbook for every domain you depend on, starting with the ones that carry your email. Write down where each domain lives and who can access it. The organizations that recover quickly from domain incidents are the ones that knew exactly what they owned and noticed the change within minutes.
Here are some useful references for going deeper on domain security:
- ICANN: Transfer Policy — the rules governing inter-registrar domain transfers for gTLDs.
- ICANN: EPP Status Codes — explains each domain status code shown in WHOIS and RDAP.
- RFC 9083: JSON Responses for the Registration Data Access Protocol (RDAP) — the RDAP response format used in the monitoring examples.
- Cloudflare Learning Center: DNS security — background on DNS-layer attacks and how they relate to domain security.
- dnspython Documentation: dnspython — the Python DNS library used in the monitoring script.


