How to stop your domain from being stolen: registrar lock, 2FA, DNSSEC & auth codes

Domains get stolen in a handful of unglamorous ways: someone breaks into your registrar account with a phished or reused password, a leaked transfer code gets used, a support desk gets talked into “recovering” the domain for an impersonator, or a renewal quietly lapses until the name drops back into the public pool. The defenses are just as unglamorous — cheap, mostly one-time settings: two-factor authentication on the registrar account, the transfer lock confirmed, DNSSEC enabled, and your auth code and registrant email guarded like the keys they are. The only real work is doing them in the right order — these controls are not equally important.

How do domains actually get stolen?

Five vectors account for essentially all of it:

• A broken-into registrar account. A reused password surfaces in a breach dump or a phishing page harvests a real one, and an account without 2FA is open. From inside, the attacker unlocks the domain, changes the contact email, and requests a transfer out — using the same buttons you would.

• A social-engineered support desk. Attackers impersonate the registrant to support staff, armed with whatever public data they can gather, and talk their way into a password reset or a pushed-through transfer. It’s one reason WHOIS privacy matters — it limits an impersonator’s raw material; see GDPR, WHOIS privacy, and your domain.

• A leaked auth code. The transfer authorization code is effectively the domain’s transfer password — anyone holding it can initiate a move to another registrar. Pasted into an old support ticket, it’s a loaded key waiting to be found.

• A lapsed renewal. Expiry isn’t theft, but the outcome is the same. There’s a grace-and-redemption window to recover an expired domain first — but once it truly drops, anyone can register it, including someone after the OAuth callbacks, email, and payment integrations still pointing at the old name. (It’s also why you should check a domain’s history before you buy one that’s lived a previous life.)

• A compromised registrant email. The quiet one. Registrar password resets and transfer confirmations route to the registrant email, making that inbox a master key. If recovery can override your strongest control, recovery is your weakest control.

Now the defenses, in order of leverage.

What’s the single most important control?

Two-factor authentication on your registrar account — nothing else is close. Almost every control below is managed from inside that account, so whoever controls the account controls the domain, and most locks with it. Account access beats every lock you can toggle yourself. (The one deliberate exception is registry lock, which is exactly why it exists — more below.)

Not all 2FA is equal, though:

• A TOTP authenticator app is the floor. Free, supported everywhere that matters, immune to SIM-swapping.
• A hardware key (FIDO2/WebAuthn) is the ceiling. Phishing-resistant — the key won’t authenticate to a fake login page. If your registrar supports it, use it.
• SMS codes are the weakest form. A SIM-swap moves your phone number — and your codes — to an attacker’s device. Better than nothing, but a stopgap.

It’s why 2FA is step one in our first-hour checklist after registering a domain. And if a registrar makes 2FA hard to find, that’s a signal — our best registrars for indie hackers guide weighs 2FA type and DNSSEC support alongside pricing.

Registrar lock vs. registry lock — what’s the difference?

They sound interchangeable. They aren’t.

Registrar lock is the EPP status clientTransferProhibited. When set, outbound transfer requests to another registrar are refused — even if someone has your auth code. Most registrars apply it by default, and it costs nothing in daily use — DNS changes, nameserver updates, and renewals all work normally. Confirm it’s set rather than assuming. Its limit is the theme of this article: the lock is toggled from inside your registrar account, so it stops a stolen auth code, not a stolen account. (Its cousin clientHold, the status that takes a domain offline entirely, gets its own guide.)

Registry lock is a different animal: a registry-level freeze on any modification, deletion, or transfer, released only after manual, out-of-band verification — typically a phone call to a pre-agreed contact or a passphrase exchanged between registrar and registry. No control-panel click can undo it, which is the point: even a fully compromised account can’t move the domain. The catch is availability. It’s generally a paid, enterprise-tier offering sold through brand-protection registrars like MarkMonitor and CSC — not a free toggle every registrant can flip, and availability varies by registrar and registry. For a side project, 2FA plus the standard registrar lock is right-sized; for the domain your business runs through, registry lock is worth a look.

Does DNSSEC stop domain hijacking?

It stops one specific kind of attack — DNS tampering, not ownership theft — and the boundary matters.

DNSSEC cryptographically signs your DNS zone data so validating resolvers can verify the answers they receive are authentic and untampered. That neutralizes cache poisoning and on-path tampering — forged DNS answers that quietly send your visitors somewhere else. You enable it through your registrar by publishing a DS record at the parent zone; registrar and TLD registry both need to support it. DNSSEC is broadly available, though validation adoption across the internet is still partial.

Here’s what DNSSEC does not do: protect your registrar account. An attacker who takes over the account doesn’t defeat DNSSEC — they change records through the legitimate control panel, and the changes get signed by the legitimate, now attacker-controlled, key chain. Validators wave them through; cryptographically they’re real. Or the attacker simply deletes the DS record and switches DNSSEC off. Enable it — it closes a real attack class at no ongoing cost — but never mistake it for account security. It protects resolution integrity, not ownership.

What about your auth code and your registrant email?

Treat the auth code like a password, because it is one. Don’t email it, don’t paste it into support tickets, and if you suspect it has leaked, regenerate it — most registrars support on-demand regeneration, which invalidates the old code. The good news: under ICANN’s updated transfer policy, registrars are increasingly replacing static codes that sit in your control panel indefinitely with codes generated on request that expire shortly after. There’s also a built-in backstop — a transfer requires a confirmation to the registrant, not just the code. The full mechanics, including the post-registration transfer-lock windows, are in our guide to transferring a domain to another registrar.

Secure the registrant email like it’s the domain itself. It’s the de facto master recovery key: registrar password resets and transfer notices route there. Give that mailbox its own 2FA, read what arrives in it, and never let it lapse — an expired mailbox tied to your registrant contact is itself a takeover vector. If the address lives on a custom domain, set up email on your domain properly.

Then close the two quiet gaps. Turn on auto-renew — it fails silently when the payment card expires, so keep that current — and consider monitoring that alerts you to changes in nameservers, contacts, or status flags. Finally, keep DNS/hosting credentials separate from, and as hardened as, your registrar login: a hosting-side breach can rewrite A and MX records and hijack traffic without touching any registrar lock.

What does the five-minute lockdown look like?

In priority order:

1. 2FA on the registrar account — TOTP minimum, hardware key if supported.
2. 2FA on the registrant email — the recovery path gets the same protection as the account.
3. Confirm clientTransferProhibited is set on every domain you own.
4. Auto-renew on, payment method current.
5. Enable DNSSEC — for resolution integrity, knowing what it doesn’t cover.
6. Regenerate the auth code if it has ever been shared — and never share it again.
7. Registry lock — only if the domain is business-critical enough for the enterprise tier.

Steps one through six cost nothing and are set-and-forget. Done once, domain theft moves from plausible bad day to something requiring a genuinely sophisticated attacker — which, for almost every project, is enough.

And if the domain worth protecting doesn’t exist yet: Domain Yoga turns one prompt into roughly 250 availability-checked, brandability-ranked name ideas in seconds — so you can spend your energy securing the name instead of hunting for it.