Domain Hijacking: Lock Down the Account, Not Just Email

Domain hijacking almost never starts with a clever DNS exploit. It starts with an attacker getting into your registrar account. Once they're in, they can repoint your mail, your website, and your SSO without touching a single server you actually monitor. Lock down that account first. DNS hygiene matters, but it's the second line of defense, not the first.

Why the registrar login matters more than your DNS records

Most security attention goes to DNS records: SPF, DKIM, DMARC, maybe a DNSSEC checkbox. Those matter for email spoofing. But none of them protect you if someone simply logs into your registrar or DNS provider dashboard and changes where your domain points.

From there, an attacker can redirect your website, intercept password-reset emails, issue certificates in your name, and quietly take over connected SaaS accounts that use "send a magic link to the domain's email" as their recovery path. The domain is the root of trust for almost everything else you run. If the account that controls it is weak, every downstream control is built on sand.

Lock down the registrar account this week

This is a short list, but each item closes a real gap attackers actively look for.

• Move off personal email. If the registrar account is tied to a founder's personal Gmail, change it to a role-based company address that's itself protected with strong MFA.

• Turn on registrar/transfer lock. Every major registrar offers a setting that blocks unauthorized transfers to another provider. If it's off, turn it on. There's rarely a good reason to leave it disabled.

• Use app-based or hardware MFA, not SMS. SMS codes can be intercepted via SIM-swap, which is one of the most common paths into registrar accounts.

• Enable WHOIS/registrant privacy where available, so your admin contact details aren't public reconnaissance for social-engineering attempts.

• Check who actually has login access. Former employees, old agencies, or a contractor who set things up years ago are the most common "forgotten door" into a registrar account.

Decision rule: if you can't name, right now, every person or vendor with registrar login access, treat that as an open finding and review it this week, not at the next renewal.

Separate "who can log in" from "who can change DNS"

Registrar access and DNS management access are often the same login, which means anyone who can renew the domain can also repoint it. Where your provider supports it, split these:

• Use a dedicated DNS management account (or your cloud provider's DNS service) with its own access controls, separate from the registrar login used for billing and renewals.

• Limit who can edit DNS records to the smallest practical group, typically one or two senior technical people, not the whole engineering team.

• Require a second approver for high-impact changes (MX records, root A/AAAA records, nameserver changes) if your provider or workflow allows it.

If you're a small team without the headcount for formal approval workflows, the practical version is simpler: keep a shared log (even a spreadsheet) of DNS changes, who made them, and why. It's not a technical control, but it gives you something to check when something looks off. A virtual CISO engagement can help formalize this habit as part of a broader program.

Watch for the warning signs, and know what to do if it happens

Domain hijacking is rarely loud. Watch for:

• Unexpected "your domain transfer has been approved" or "nameservers updated" emails you didn't initiate.

• Your site or mail suddenly behaving oddly for some users but not others (a sign DNS changes are propagating).

• Login notifications from your registrar at odd hours or from unfamiliar locations.

If you suspect hijacking: contact your registrar's support immediately to freeze the account and reverse any pending transfer, change the account password and MFA method, and review DNS records line by line for anything that doesn't belong. Don't assume it's "just email." Treat it as an active incident until proven otherwise. If you don't have in-house capacity to run that response calmly while also keeping the business running, that's exactly the gap an incident response engagement is built to close.

If an agency or reseller controls your domain, here's the real objection

A common pushback: "our web agency or IT reseller manages our domain for us, so this isn't our problem." It still is. If you don't personally hold registrant rights and MFA-protected access, you're relying entirely on that vendor's security hygiene. And you likely have no direct way to recover the domain quickly if that vendor is slow, unresponsive, or the relationship ends badly.

The fix isn't necessarily to take DNS management in-house. It's to make sure your business, not just the vendor, is listed as the registrant, has a documented account recovery path, and has at least one person who could regain control without depending on that vendor answering the phone. Ask for this in writing; a cooperative vendor will have no issue providing it.

Next step

Registrar and DNS access is one of the highest-leverage, lowest-cost things to get right. It's a one-time cleanup, not an ongoing budget line. If you want a second set of eyes on your current setup, including how it connects to your broader cloud and identity posture, start with a free security review. It's a low-friction way to find out where the real gaps are before someone else does.