Locks, contacts and expiry — Domain Security Fundamentals

The controls here are unglamorous, mostly free, and disproportionately effective. Working through them for one domain takes about half an hour and is frequently the highest-value half hour in a domain security programme.

Two locks, and they are not the same

	Transfer lock	Registry lock
Status code	`clientTransferProhibited`	`serverTransferProhibited`, `serverUpdateProhibited`, `serverDeleteProhibited`
Set by	You, in the registrar control panel.	The registry, on request, via your registrar.
Defeated by	Anyone with your registrar account.	Nobody without passing out-of-band verification.
Cost	Free, and usually on by default.	A fee, and real friction on legitimate changes.
Use for	Every domain you own.	Domains where an outage would be a serious incident.

The distinction matters because they defend different things. Transfer lock stops a transfer initiated without your knowledge; it does nothing against someone who has your account, since they can simply turn it off. Registry lock is enforced above the registrar and requires a human verification step — so account compromise alone is not enough.

Registry lock is meant to be inconvenient

Changes take a phone call and a day rather than a click. That is the product, not a defect of it. For a domain carrying your primary mail and your public presence, a day’s delay on a planned change is a reasonable price for making an unplanned change impossible. It is not available in every TLD, which is a genuine input when choosing where a critical domain lives.

# what is actually set
whois example.com | grep -i 'status:'

# expect at minimum:
#   clientTransferProhibited
# and for critical domains:
#   serverTransferProhibited serverUpdateProhibited serverDeleteProhibited

The account itself

Individual logins, never a shared one. A shared registrar login cannot be attributed, cannot be revoked when someone leaves, and cannot have a personal second factor. If the registrar supports multi-user accounts with roles, use them; if it does not, that is a reason to consider a different registrar.
Multi-factor authentication, on every account. Prefer an authenticator app or a hardware key over SMS, which is defeated by SIM swapping — a technique used specifically against high-value domain accounts.
A registrant contact that is a monitored role address, not a person. domains@example.com going to a team, not dave@example.com going to someone who left in 2022. Every recovery process routes through this address.
That contact address must not depend on the domain it protects. If example.com’s registration contact is domains@example.com, and the domain is taken, the recovery emails go to the attacker. Use a separate domain or an external address for the critical ones.

The circular dependency is the subtle one

It is easy to miss because it is invisible until the day it matters, and on that day it is the difference between a fast recovery and a slow legal process.

Auth codes

Transferring a domain requires an authorisation code from the current registrar. Treat it as a credential: request it only when a transfer is actually happening, do not leave it in a ticket or a shared document, and confirm it has been rotated afterwards. Some registrars display a static code indefinitely, which makes it a standing password to move your domain.

The audit

Transfer lock set?
Registry lock, for domains where an outage would be an incident?
MFA on every account with access, and not SMS where avoidable?
Individual logins rather than a shared one?
Registrant contact a monitored role address, at a domain other than this one?
Auto-renew on, with a payment method that will not expire?
Expiry date known, and more than a year out?
Nameservers in the registration match what you expect?
DS record present if the zone is signed?

Nine questions. Run them across every domain you own, including the parked ones — those are where the answers are worst, and a lapsed parked domain is a working address for someone impersonating you.

Knowledge check

A company has MFA on its registrar account, a transfer lock set, and the registrant contact listed as domains@company.com. An attacker compromises the company's email system. What is the weakest point?

The transfer lock, because an attacker with email access can request its removal.
The registrant contact is at the same domain it protects, so account recovery emails go to the compromised system.
MFA, because it can be bypassed by SIM swapping.
Nothing — these three controls are sufficient against email compromise.

Not this — The transfer lock, because an attacker with email access can request its removal. Close, but the transfer lock is a consequence rather than the root. It can be cleared by anyone with the registrar account, and the question is how they get it.

Correct — The registrant contact is at the same domain it protects, so account recovery emails go to the compromised system. The circular dependency. With control of domains@company.com the attacker can drive a password reset, and MFA is frequently recoverable through the same verified address. Every control here ultimately routes back to a mailbox inside the thing being protected. A contact address on an unrelated domain breaks the loop.

Not this — MFA, because it can be bypassed by SIM swapping. A real risk if the second factor is SMS, and the question does not say it is. The structural flaw here does not depend on which factor was chosen.

Not this — Nothing — these three controls are sufficient against email compromise. They are a good baseline and they share a single dependency. Email compromise is precisely the scenario that collapses all three at once when the recovery address lives inside the compromised system.