For most online businesses the domain is the single most valuable asset. It is the address customers know, the identity your email depends on, and the thing every link ever built to you points at. Lose it and you lose the site, the mail, and the accumulated search authority in one go.
It is also, routinely, the least protected thing the business owns. People run two-factor authentication on their bank and their CRM, and leave the registrar account on a password from 2019.
Domain theft is not a DNS attack. Almost every case starts with access to the registrar account, and the defences are correspondingly boring — which is why they get skipped.
How domains are actually taken
Registrar account compromise is the overwhelming majority. Reused password, credentials from an unrelated breach, or a phishing page that looks like your registrar's login. Once inside, the attacker changes nameservers, transfers the domain elsewhere, or both.
Email account compromise is the same attack one step back. Control of the mailbox used for the registrar account means password resets, and it means intercepting the transfer confirmations that were supposed to warn you.
Social engineering the registrar. A convincing support request to recover an account "after losing access to email". Larger registrars have hardened against this, smaller resellers vary.
Expiry. Not theft, but the same outcome and far more common. The domain lapses and someone else registers it. Covered in what happens when a domain expires.
Registrant email drift. The contact address on the domain is at a company someone left, or a domain that itself expired. Nobody receives the renewal and transfer notices, and the first sign of trouble is the site going down.
Notice what is absent from that list: DNS spoofing, protocol attacks, anything requiring skill. The attack is against the account.
The defences, in order of value
Turn on the registrar lock
The clientTransferProhibited status tells the registry to refuse transfer requests for this domain. It is free, takes a few seconds, and it is the single most effective control available to you.
With it set, an attacker inside your registrar account still has to remove the lock before transferring — which is another step, and one that generates a notification.
Check the current state by running your domain through the WHOIS Lookup and reading the Transfer lock result. If it says unlocked, fix that now; the setting is in the domain's page at your registrar, usually called "domain lock" or "transfer lock". The only reason to have it off is an in-progress transfer you initiated.
While you are there, clientDeleteProhibited and clientUpdateProhibited are worth setting too. They prevent deletion and modification without lifting the lock first.
Secure the registrar account properly
Two-factor authentication, with an authenticator app or hardware key rather than SMS. SIM swapping is a real technique and specifically defeats SMS codes.
A unique password from a password manager. Registrar accounts are a known target, and credential stuffing against them is automated.
Audit who has access. Agencies, former developers and contractors accumulate logins. If your domain sits inside an agency's registrar account rather than your own, you do not control your domain — you have an arrangement. That is worth fixing before it becomes a dispute.
Fix the contact email
Every warning a registrar sends — expiry notices, transfer requests, change confirmations — goes to the registrant email on the domain.
Two rules. It must not be at the domain it protects. If the domain goes down or gets taken, so does the mailbox you would use to recover it. Use an address at a different domain entirely.
It must go to more than one person. A departed employee's address is the classic failure: the notices go somewhere nobody reads, and the first anyone knows is the outage. A monitored group address is better than an individual.
Consider registry lock for high-value domains
Beyond the standard registrar lock, registries offer registry lock — the serverTransferProhibited, serverDeleteProhibited and serverUpdateProhibited statuses. Changes require manual verification with the registry itself, typically a phone call to authorised contacts.
It costs money, it is only offered by some registrars, and it makes legitimate changes slow and deliberate. For a domain carrying real revenue that is the point. If you look up a large company's domain in the WHOIS Lookup you will usually see all three server statuses set.
Keep DNSSEC in mind, but understand what it does
DNSSEC signs your DNS records so resolvers can detect tampered answers. It defends against DNS-level attacks — cache poisoning and forged responses — which is a real class of problem, but not the one that takes domains.
It does nothing against a compromised registrar account. An attacker with your login can change the DS record along with everything else.
It is worth having. Just do not treat it as anti-theft, and be aware that a botched nameserver change with DNSSEC enabled breaks the domain completely rather than degrading, because validating resolvers return SERVFAIL. Always update the DS record when moving DNS providers.
Monitoring
The goal is to find out within hours rather than when a customer emails.
Watch the registration record. Nameservers, registrar and status codes should not change without your knowledge. A periodic WHOIS Lookup shows all three; a change you did not make is the earliest reliable signal of a compromise.
Watch the DNS records themselves. A DNS Checker run showing an A record you did not set means someone is already redirecting your traffic. This can precede a transfer — the attacker points the domain at their own server first and moves it later.
Never ignore a transfer notification. Registrars send an email when a transfer is initiated, and there is a window — typically five days — in which you can reject it. That email is the last warning before the domain leaves. Once a transfer completes, recovery gets significantly harder.
Diarise the expiry date. Auto-renew is not a guarantee; the card on file expires. Note the registry expiry date from the WHOIS lookup, not the registrar's internal date, since they can differ.
If it has already happened
Move quickly. The window matters more than anything else you do.
- Contact the registrar immediately, by phone if possible. If the transfer has not completed, they can usually stop it. This is by far the best outcome and the reason speed matters.
- Regain control of the email account if that is the entry point. Otherwise every recovery step is visible to the attacker.
- Document everything — screenshots, timestamps, the WHOIS record before and after, transfer notifications. Every subsequent process will ask for evidence of prior control.
- If the transfer completed, the formal routes are the registrar's dispute process, ICANN's Transfer Dispute Resolution Policy for a transfer that broke the rules, or UDRP for a trademark claim. These take weeks to months.
- Assume the DNS was modified. Even after recovering the domain, verify every record against what you had. Attackers add MX records to intercept mail and TXT records to hold verification with other services.
The short version
Turn on the transfer lock, put a hardware key or authenticator on the registrar account, and make sure the contact email is at a different domain and read by more than one person. Those three take fifteen minutes and prevent nearly every real case. Then check the record periodically, because noticing in hours rather than weeks is what determines whether you get the domain back.