Domain Hijacking Isn't Rare Anymore: How MSPs Should Structure Client Domain Access

The Lockout

A version of this thread shows up on r/msp every few months, and it always reads about the same. A client's account with their web host or registrar gets compromised. Whoever got in changes the nameservers, or the MX records, or both. By the time anyone notices, it's because the client's site is showing something wrong or their email has quietly stopped arriving, and the account is locked pending a support ticket with no real timeline. The MSP is stuck watching it happen from the outside.

What's more telling than the hijack itself is what happens in the replies. Someone says the client should hold the registrar account and the MSP should just have delegated access. Someone else says that's how you end up locked out during an actual incident, and full management under the MSP's own account is the only way to move fast when it matters. A third person raises what happens if the client who technically owns the domain leaves the company, or dies, and nobody can prove who's allowed to touch it. Nobody's wrong exactly. They're describing different trade-offs, and most MSPs have never sat down and picked one on purpose.

Why This Is an MSP Problem, Not Just a Client Problem

It's tempting to file domain security under "the client's account, the client's problem." That doesn't hold up once you're the one fielding the call when the client's email stops working, and it definitely doesn't hold up if the domain in question is the one hosting the client's Microsoft 365 verification records, their DMARC policy, or their VPN endpoint.

A hijacked domain isn't a website problem. It's an email problem, a DNS problem, and depending on what else is delegated to it, potentially a full-network access problem. Whoever manages DNS for that client is the one who gets the call first, whether or not they hold the registrar credentials, and whoever gets the call first is the one whose response time the client remembers.

There's also a quieter version of this that doesn't involve an attacker at all: a client's web developer gets handed "the login" to make one change, and doesn't know what a nameserver is, and points the whole domain at a new host by accident. Same blast radius, same phone call, no hijack required. The access model that protects against a criminal taking over an account is largely the same access model that protects against a well-meaning developer breaking one.

Three Ownership Models, and Why the Debate Never Settles

Strip the forum arguments down and there are really three shapes this takes. None of them is universally correct, they trade off risk differently, and most MSPs are running a mix across their client base without having chosen to.

The "client-owned with delegated access" row is where most of the disagreement lives, because delegated access is only as strong as the account it's delegated from. If a client's personal email gets compromised and that email is the recovery path for their registrar login, the MSP's delegated access doesn't save anyone. It just means the MSP finds out slightly faster that it's already gone.

The succession question that comes up constantly — what happens if the client who owns the domain leaves the company, or the account is tied to an individual who's no longer reachable — is really an argument for moving critical domains toward the third model over time, not for avoiding ownership decisions altogether. A domain registered to a person who no longer works at the company, secured by an email account that person no longer has access to, is a liability regardless of who's "managing" the DNS on top of it.

There isn't a single right answer for every client. There is a wrong one: not deciding, and ending up with a portfolio where nobody could say with confidence, for any given domain, who's actually able to act on it in an emergency.

What Actually Stops a Hijack

Access model matters less than what protects the account underneath it. Most of the hijacks that show up in these threads didn't happen because of a DNS misconfiguration. They happened because a registrar login was weak, reused, or recoverable through a channel nobody was watching.

A few things that actually move the needle:

• MFA that the MSP controls, not the client's personal phone number. SMS-based MFA tied to a client's cell number is exactly the thing AI-assisted vishing calls are getting good at social-engineering around. TOTP apps or hardware keys, tied to credentials the MSP manages centrally, close that door.
• Rotating credentials the moment a domain moves into MSP management. If a client hands over "the login," that login has probably been shared with a web developer, a former employee, or sits in an old email thread somewhere. Treat it as already compromised and rotate it.
• One place to store registrar credentials, not a password manager entry per technician's personal habits. Every additional place a credential lives is another surface that has to be individually secured, and individually audited when someone leaves the team.
• Registry lock where the registrar offers it, for domains where an unauthorized transfer or NS change would be genuinely catastrophic. This is a registrar-level control, not something any DNS management layer can add on top, but it's worth asking for on the domains that matter most.

None of this is exotic. It's the same credential hygiene MSPs already apply to client Microsoft 365 tenants. Domains just don't get the same discipline as often, because they're touched less frequently and it's easy to forget they're a standing liability sitting quietly in the background.

Catching It Before the Client Calls

Even with good credential hygiene, the honest goal isn't "this will never happen." It's "we know within minutes instead of finding out from the client." That gap is the whole ballgame. A hijack that's caught and reverted in ten minutes is an inconvenience. The same hijack, discovered 36 hours later because nobody was watching, is the kind of incident that shows up in a churn conversation.

This is the part most MSPs are missing entirely, not because it's hard, but because it requires visibility across every registrar a client's domains happen to sit at, and most MSPs don't have a single place to watch that. Unified DNS's Zone Health and DNS Security reports run across every connected provider in the account, and scheduled record reconciliation keeps the platform's view of a zone in sync with what's actually live at the nameservers, which is what catches a change made outside the portal instead of through it — the exact scenario in every one of these hijack stories, where the change happened at the registrar directly, not through anything the MSP controlled.

For domains at registrars an MSP doesn't have API access to, or hasn't been granted write access on, Unified DNS's Monitoring Only provider tracks the domain using public DNS and RDAP lookups with no credentials required at all. That matters more than it sounds like: it means "we don't have full access to this client's registrar" and "we have no visibility into this client's DNS" don't have to be the same sentence. A domain can sit entirely in the client's own account, fully outside the MSP's control, and still show up the moment its nameservers or expiration status change unexpectedly.

That's a genuinely different posture than only finding out when the site or the email breaks and the client calls. Tools built purely for DNS monitoring exist too, and they're not wrong to use, but they only tell you something changed. They don't let you also manage the records that need fixing once you know. We wrote a full comparison of that trade-off here if it's relevant to how your stack is put together today.

The First Hour of a Suspected Hijack

When a domain looks compromised, the sequence matters more than any individual step:

1. Confirm it's actually a hijack, not a self-inflicted change. Check whether anyone on the client side or the MSP side made a legitimate change recently. A surprising number of "hijacks" are an unannounced developer change or an auto-renew failure that looks similar from a distance.
2. Check current NS and MX records against your last known-good state. If you have an audit log or a recent backup of the zone, you already know exactly what changed and when, instead of guessing from memory or old documentation.
3. Contact the registrar's support with the account details ready, not after searching for them. This is where having credentials centralized instead of scattered actually saves time — the difference between an immediate ticket and twenty minutes spent finding out which of five accounts this domain even lives in.
4. If DNS is still resolving to the attacker's infrastructure, get the client's users and any downstream systems (email, VPN, SSO) aware immediately. Don't wait for full resolution before communicating; the exposure window is the thing that hurts the client most, not the eventual fix.
5. Once access is restored, rotate every credential associated with the account, not just the one that was obviously used. Assume anything reachable from that login was touched.
6. Revert DNS to the known-good state and verify propagation before declaring it resolved. A restore that looks complete in the dashboard but hasn't propagated yet is how the same incident reopens six hours later.

Step 2 is the one that separates a fast recovery from a slow one. If nothing was tracking the zone's state before the incident, "known-good" is whatever someone can remember or reconstruct from old tickets, which is a bad position to be rebuilding a client's email routing from.

A Decision Framework You Can Actually Use

For every domain in your portfolio, three questions settle which model applies:

• Would an outage on this domain page someone at 2am, or just be annoying by Monday? High-stakes domains (primary business domain, anything routing email or VPN/SSO) belong in MSP-managed or at minimum delegated-with-MFA-you-control. Low-stakes domains (a parked brand-defense purchase, a legacy redirect) can stay client-owned with monitoring-only visibility.
• Does the MSP have write access today, or only visibility? If it's visibility only, that's not a gap to apologize for, it's a legitimate tier, as long as it's monitored rather than ignored. The failure mode isn't "we don't manage this domain." It's "we don't manage it and nobody's watching it either."
• Who's the named account holder, and are they still reachable? If the answer is a former employee, a personal email nobody checks, or "not sure," that domain needs to move up a tier regardless of how critical it otherwise is, because an unreachable account holder is itself the risk.

Run every client domain through those three questions once, and you end up with a portfolio where every domain has a deliberate tier instead of an inherited one, and where "monitoring only" and "no visibility at all" are no longer the same thing by accident.

Frequently Asked Questions

Should the MSP or the client own the domain registration?

There's no single right answer, but the deciding factor should be how much damage an outage on that domain would cause, not habit or convenience. High-stakes domains, meaning anything routing email, VPN, or SSO, are usually safer under MSP management with the client retained as the WHOIS registrant. Lower-stakes domains can reasonably stay client-owned as long as the MSP has at least monitoring visibility into them.

What's the difference between delegated access and full management?

Delegated access means the MSP is granted a user role or API credentials inside the client's own registrar account. Full management means the domain has been transferred into an account the MSP controls directly, with the client retaining registrant rights. Delegated access is faster to set up and less disruptive, but it inherits the security of the client's parent account, including its recovery email and MFA, which the MSP usually doesn't control.

How can an MSP detect unauthorized DNS or nameserver changes?

The most reliable way is continuous monitoring across every registrar a client's domains touch, not just the ones the MSP has full access to. Unified DNS's Zone Health and DNS Security reports run across every connected provider, and scheduled record reconciliation flags changes made outside the platform. For domains the MSP only has read access to, the Monitoring Only provider tracks public DNS and RDAP data with no credentials required, so a hijack or expiration surfaces on its own instead of waiting for the client to call.

Does DNSSEC prevent domain hijacking?

No. DNSSEC protects against DNS response tampering and cache poisoning between the nameserver and the resolver, but it doesn't stop someone who has successfully logged into the registrar account from changing the nameservers or the DS record themselves. It's a real and worthwhile control, but it addresses a different threat than a compromised registrar login.

What should an MSP do if a client's domain is hijacked?

Confirm it's genuinely unauthorized rather than a legitimate but undocumented change, check current records against a known-good backup or audit log, contact the registrar with account details ready rather than searching for them mid-incident, notify affected downstream systems immediately rather than waiting for full resolution, and rotate every credential tied to the account once access is restored. Having a pre-incident backup of the zone is what turns this from a reconstruction project into a restore.

What happens to a domain if the client who owns it leaves the company or becomes unreachable?

This is one of the strongest arguments for moving critical domains toward MSP-managed ownership over time. A domain registered to an individual who's no longer with the company, secured by an email account that person no longer controls, is a liability independent of who's technically managing the DNS on top of it. If a domain's named account holder is unreachable, that's reason enough to reassess its tier regardless of how critical the domain otherwise is.

Get Started with Unified DNS

Unified DNS gives MSPs one place to see every client domain, whether it's fully managed through a direct API integration or only visible through Monitoring Only for the accounts you don't hold credentials for. MFA, encrypted credential storage in Azure Key Vault, role-based access, and a full audit log come standard, so the access model you choose for each client is actually enforceable instead of just documented somewhere.

Unified DNS is live — try it free for a month with code FREETRIAL2026 at billing setup. No commitment. Or contact us if you want help mapping your current client domain portfolio to a tiered access model.

Zoe Montague is the founder of Silverfern Technology Consultants and the creator of Unified DNS, a DNS management platform built for MSPs.