Domain Expiry & Hijack Protection Checklist for Small Business
Why this page exists
You can lose your server and be back in an afternoon. You can lose your email provider and be back before lunch. Lose the domain — the name itself — and everything built on it stops at once: the website, the mail (every invoice, every password reset), the DNS records a dozen SaaS tools quietly depend on, and the trust customers place in the addresses they already know. And unlike a server, a domain that moves to someone else is not a restore job. It is a legal dispute measured in weeks, if it resolves at all.
Domains don't usually get "hacked" in the movie sense. They lapse, get phished, get transferred by a fraudster who social-engineers a support desk, or get locked inside a founder's personal account that nobody else can reach. All four are preventable with about an hour of setup and a ten-minute quarterly drill. This page is that setup and that drill.
The DNS outage runbook handles the day nameservers are down but you still own the name. This page is about the worse case: the name moving to someone who shouldn't have it — or expiring out from under you.
1. The five ways businesses lose a domain
The expired card. Auto-renew fires, the card on file was reissued or hit its limit, the renewal fails, and the warning emails go to a mailbox nobody reads. Somewhere between 30 and 45 days later the domain drops and — for a window — anyone can register it. Dropped domains get bought by resale farms within minutes, because expired names with traffic and backlinks are inventory.
The phished transfer. An email that looks like registrar housekeeping asks you to "confirm ownership" or "validate your contact details," and you hand over an EPP/auth code to someone who isn't your registrar. The transfer completes at the gaining registrar and the clock starts against you.
The account takeover. The registrar login uses the same password as something already breached, protected by SMS "2FA" that SIM-swap defeats. Attackers don't need to beat the registrar; they need to beat one reused password.
The inside change. Whoever holds the registrar account changes nameservers and points the name somewhere else — mail reroutes to an attacker's server (every password reset is now readable by them), web traffic redirects to a clone of your checkout. No transfer happens; nothing shows up in the way people usually watch for it.
The frozen founder. The domain sits in one person's personal account — their email, their phone, their death or their departure — and the business discovers it never actually owned its own name. This is the quietest of the five and the one auditors find most often.
Every control below maps to one of these five. If you do them all, none of the five is cheap to execute against you.
2. Registration: make expiry a non-event
Register in multi-year blocks. One to three years out, not the minimum. The marginal cost is nothing; the failure mode it removes is the single most common way small businesses lose a domain.
Auto-renew ON — and assume it will fail anyway. Auto-renew is a convenience, not a control. It depends on one card. Put a billing alarm in the calendar at 60, 30, and 7 days before expiry, with the renewal card's last four digits in the note so whoever gets the alarm can fix it without detective work.
The card itself gets a checklist line. The card that renews the domain is a dependency, exactly like a vendor. When it's reissued, someone updates the registrar. Add it to the offboarding-style checklist you run when a bank card changes.
Owner-of-record = the business entity, not a person. Registrant organization should be the legal entity with a role mailbox (domains@yourcompany) as the contact — a mailbox that outlives any employee, monitored by more than one person. If the founder's personal Gmail is the registrant contact, fix that this quarter.
Whois privacy is fine; ownership anonymity inside the company is not. Privacy protection hides the contact from the public. It does not excuse the company from knowing exactly which account, which email, and which recovery path control the domain. That lives in the one-page record (section 5).
Watch the drop window even if you did everything right. Know your registrar's grace/redemption timeline. Redemption fees are annoying; redemption deadlines missed are final.
3. Locks and codes: make transfers hard
Transfer lock ON, always. Most registrars default to it; verify, don't assume. In registry terms you want the status clientTransferProhibited visible on your domain. It costs nothing and blocks the casual transfer.
The EPP/auth code is a credential. Treat it like a password reset link. It is only ever generated from inside your logged-in registrar account, on your request. No legitimate registrar support flow asks you to read an auth code out over a call you didn't initiate, and no legitimate buyer of your business receives it over email. If someone emails asking for it — even using your registrar's logo, even citing an "expiring validation" — that's the attack.
Nameserver changes are the real prize — watch them. A hijacker who has your account doesn't need to transfer anything; flipping nameservers takes one click and takes your mail with it. Prefer a registrar that emails on every nameserver change, and treat any such email you didn't cause as a live incident, not a notification.
DNSSEC where the registrar supports it. It doesn't stop a nameserver change at the registrar, but it does protect resolvers and customers from forged DNS between you and them. If your registrar supports DNSSEC with a one-click DS record, it's a free layer; if DNS is managed elsewhere, keep the DS record consistent in both places or mail validation breaks.
Registry lock is the enterprise tier. Verisign's Registry Lock and equivalents require a verified human out-of-band step (a phone call to a pre-registered number) before any nameserver or nameserver-host change clears. If your domain is the business, ask your registrar what they offer; if the answer is nothing, the transfer lock plus the drills below is the realistic baseline.
Thin your attack surface: no shared registrar logins — one account, named seats, MFA by app or hardware key rather than SMS, and the recovery path reviewed the same way you review a password rollout.
4. The circular trap: recovery email and the domain it protects
The most self-inflicted outage in this whole subject: the registrar account's recovery email is an address on the domain it protects. Attacker flips your nameservers, your mail stops resolving, and the reset link for getting your registrar account back is sent to a mailbox that no longer exists on the network. Now you're recovering access through a support queue with no email, proving identity with documents, while customers see a dead site.
Recovery email lives on an independent domain. A second, separately-renewed domain used for nothing but administration, or a provider mailbox on a domain you don't also operate DNS for. One hour of setup, removes an entire class of lockout.
Two humans, both paths. At least two people at the company can name the registrar, log in, and describe the recovery path. If that person is on a flight, the domain waits for no one.
Test the recovery path annually. Actually click "forgot password" and walk the flow to the last step. Untested recovery paths rot silently — this is the same lesson as the restore test: a control you've never exercised is a story you tell yourself.
The same logic applies to hosting and email vendors: the account that controls your domain's DNS at Cloudflare/wherever is a second door — same MFA rules, same ownership rules, same record-keeping. The vendor security review applies to your registrar and DNS provider like any other vendor.
5. The one-page domain record (and the 10-minute quarterly drill)
Write it once, review it quarterly, store it where the DR plan lives:
Domain, registrar, account owner(s), MFA method, recovery email (and where that mailbox lives)
Transfer-lock status, DNSSEC on/off (and DS record location), nameserver provider
Who is authorized to request an EPP code (roles, not just names)
Registrar support line for fraud/urgent cases, and the account number they'll ask for
The quarterly drill, ten minutes with a browser:
Look the domain up on RDAP (rdap.org forwards to the right registry). Confirm: expiry date more than 90 days out, status shows clientTransferProhibited, nameservers match the record above.
Log in to the registrar. MFA still works. Recovery email still receives mail (send yourself a test).
Check the audit/notifications tab: any logins or changes you don't recognize?
Confirm the renewal card is still the card you think it is.
If anything drifted, fix it now, not in the next quarterly.
This is the domain's version of the annual review cadence, compressed — because the domain is the one asset where a silent drift becomes a hostage situation instead of an inconvenience.
5b. First hour when the domain moves anyway
Despite everything, assume a bad hour can come. Order of operations:
Don't email the hijacker and don't tip them off. Every minute of their ignorance is leverage.
If nameservers changed but you still hold the registrar account: revert the nameservers first — that's one screen and restores mail and web instantly. Then rotate the account password and MFA, and treat the account as compromised (the first-hour revoke sequence applies to accounts, not just laptops).
If a transfer completed: call the losing registrar's fraud team immediately — not a web form. Registrars can file a registrar-level transfer dispute, and under ICANN's Transfer Policy a domain within 60 days of a transfer can't be transferred again — which contains the damage while it's contested. Ask specifically for the fraud/security team and say the words "unauthorized domain transfer."
If the account itself was taken over: registrar support, account recovery with documented ownership (your one-page record is now evidence), and your payment history as proof of control.
While DNS is hostile: publish your status through a channel you control that isn't on the dead domain (a status page on another domain, direct email to staff via an external provider) — the incident comms templates cover the wording.
Expect email-based attacks during the outage: with your mail down, "we noticed your mail is bouncing" phishing lands differently. Warn finance about payment-change requests the same week; the callback rule is the only thing that keeps a DNS incident from becoming a wire incident.
Document timestamps from the first minute. Every registrar dispute, every ICANN escalation, every insurance claim runs on your timeline log — same discipline as the incident timeline.
The short version
Multi-year registration + auto-renew + calendar alarms at 60/30/7 days.
Transfer lock ON; the EPP code is a credential; nameserver-change emails are incidents.
Business entity owns the domain; role mailbox is the contact; two people can log in.
Recovery email on an independent domain — never on the domain it protects.
Ten-minute RDAP drill every quarter; one-page record next to the DR plan.
An hour of setup and ten minutes a quarter. That's the entire price of never explaining to a customer why your invoices started coming from someone else's server.