Client Domains Scattered Across Registrars: The Hidden Risk Every MSP Is Sitting On

The domain sprawl problem most MSPs accept without thinking about it

In most MSP client relationships, domain ownership is an afterthought. When a business was set up years before the MSP arrived, the domain was registered by whoever happened to be handling IT at the time — a web developer, an in-house employee, or the owner themselves. That domain might live at GoDaddy, Network Solutions, Squarespace Domains, Namecheap, Cloudflare, or any of a dozen other registrars. Each one has different delegated access models, different 2FA requirements, and different support processes when something goes wrong.

For an MSP managing ten clients, this is survivable. For one managing fifty, it becomes an operational tax paid on every DNS change, every DMARC record update, every SSL renewal, and every domain expiry check. The overhead is constant and largely invisible — until something goes wrong, at which point it becomes very visible very quickly.

The scale problem:

A new MSP engineer onboarding to manage email security for a portfolio of clients recently described spending several weeks cold-calling clients to track down who registered each domain, which account held it, and how to get delegated access granted — just to be able to publish DKIM and DMARC records. This isn't a rare experience. It's the default state for MSPs that inherit client relationships without controlling the underlying domain infrastructure.

What "delegated access" actually looks like in practice

Most major registrars offer some form of delegated access — the ability to share DNS management access with a third party without transferring ownership. In theory, this is the right model. The client retains ownership of the domain; the MSP gets the access it needs to do the job. In practice, it is not clean.

Delegated access permissions vary significantly between registrars. Some platforms offer granular control over what a delegate can do — manage DNS only, no ability to transfer or change contact information. Others offer an all-or-nothing model where delegated access carries the same permissions as the account owner. An MSP that has delegated access to fifty client domains across ten registrars has created a concentrated point of exposure: if the MSP's own account credentials are compromised, every one of those client domains is at risk simultaneously.

The alternative — deleting delegated access and asking clients to re-grant it as needed — is the approach some MSPs take to limit that exposure. It also means that adding a DNS record becomes a multi-step process involving a phone call, a wait, and a manual workflow that shouldn't need to exist at all.

The two problems MSPs actually face:

lock_open Control: Delegated access grants too much or too little — either a security liability or an operational bottleneck. There's rarely a model that's both safe and frictionless.
manage_accounts Ownership continuity: Domains registered to a client contact's personal email address create a succession problem. If that person leaves the company, retires, or dies, access to the domain becomes a legal and operational crisis — not an IT problem with a clean technical fix.

The hijacking scenario: when the registrar is the attack surface

Nameserver hijacking is not a sophisticated attack. An attacker who gains access to a client's registrar account — through credential stuffing, phishing, or a password reuse exploit — doesn't need to touch the client's servers, cloud tenant, or email infrastructure. Changing the nameservers or MX records directly at the registrar bypasses everything else the MSP has put in place.

The immediate effects can include email being rerouted to attacker-controlled infrastructure, SSL certificates failing because domain validation no longer resolves correctly, and web traffic redirected to malicious sites. The MSP doesn't find out until the client notices email isn't working. By then, the damage — credential interception, email harvesting, business email compromise — may already have happened.

Recovery depends entirely on the registrar's support process. If the registrar requires identity verification before restoring access, and the compromised account's ownership information is inconsistent or outdated, the wait can stretch from hours to days. During that window, the MSP has limited options and no ability to self-serve a fix — because the domain is controlled by an account they don't own.

The registrar as a single point of failure:

The full email stack — Microsoft 365 configuration, DMARC policy, SPF records, DKIM keys — is only effective as long as the underlying DNS records remain accurate. If the DNS records are altered at the registrar level, all of that configuration becomes irrelevant instantly. Monitoring email authentication in isolation, without also monitoring the DNS and nameserver records those policies depend on, leaves a significant gap in the protection model.

Domain expiry: the slow-motion version of the same problem

Nameserver hijacking is dramatic and immediate. Domain expiry is quiet and predictable — and yet it catches MSPs regularly. When a domain is registered to a client account with an old email address, auto-renew off, and no one at the MSP actively monitoring expiry dates, the gap closes gradually until the domain lapses. At that point the company's primary business identity — its email, its website, its brand — is potentially available for anyone to register.

The 30 to 60 day grace period most registrars provide before releasing a domain is not a safety net if no one is watching. Expired domains in the grace period can be unavailable for renewal through standard UI interfaces, can have their DNS records suspended immediately, and can require escalation through registrar support channels. In the worst cases — where a domain transitions to redemption or is auctioned — recovery is expensive or impossible.

For large vendors in the space, even multi-domain lapses have occurred. When a security tooling vendor's own product domain expires and redirects to a squatter, it's a visible example of an operational failure that no amount of sophisticated security tooling can prevent if the renewal process isn't managed. The same risk applies to every client domain an MSP oversees without centralised expiry monitoring in place.

Why the DNS management conversation keeps happening in the MSP community

The recurring question in MSP communities about domain and DNS management tooling isn't really about finding a better registrar. It's about finding a model that removes the friction. MSPs need to be able to make DNS changes — adding SPF includes for new SaaS tools, updating DKIM keys when a signing key rotates, configuring DMARC records, pointing MX records during email migrations — quickly and without a workflow that involves client-side action every time.

The underlying issue is that most registrar platforms were built for individual domain owners, not for IT service providers managing dozens or hundreds of domains for different organisations. Multi-tenancy is an afterthought, access models are inconsistent, and there's no concept of portfolio-level visibility — which domains are expiring soon, which have DNSSEC enabled, which have undergone nameserver changes in the last 24 hours.

The MSPs that operate with the least friction have typically solved this by registering and maintaining all client domains through a single platform that they control — where they're the registrant of record on behalf of the client, the DNS is managed through an API they directly access, and alerts fire automatically when anything changes outside of expected parameters.

What that centralised model enables:

bolt DNS changes — including DKIM key updates, SPF modifications, MX record changes — done directly without client involvement, in seconds rather than days.
notifications_active Expiry alerts at configurable lead times — 90, 60, 30 days — across the entire client portfolio from a single view.
monitor_heart Nameserver and DNS record monitoring that alerts immediately when any record changes outside of a documented change window — including changes made without MSP involvement.
lock Consistent access control with clear boundaries between clients — no cross-contamination of credentials, no single account that unlocks the entire portfolio if compromised.

The connection to DMARC and email security that often gets missed

Domain management and email authentication are not separate disciplines. DMARC, DKIM, and SPF all depend on DNS records that exist at the domain level. If the domain is on a registrar the MSP doesn't control, every email security configuration the MSP has put in place is contingent on a third party maintaining accurate, unmodified DNS. That's a dependency most MSPs don't explicitly acknowledge — until a registrar account compromise changes a nameserver and takes all of it offline at once.

The reason monitoring matters here is that the gap isn't always dramatic. A web developer updating a client's Cloudflare zone for a website change can accidentally modify or delete a DKIM record. A registrar migration that goes slightly wrong can leave SPF records behind. A new employee at a client setting up a marketing SaaS adds a broad SPF include without informing the MSP. In each case, the MSP's DMARC aggregate reports will eventually surface the failure — but only if someone is watching them.

DNS change monitoring that runs alongside DMARC report analysis closes this gap. When a DNS record change triggers an alert before it has caused a deliverability problem, the MSP can investigate and correct it proactively rather than reactively. Combined with centralised domain management, this creates a posture where the MSP knows about any change to domain infrastructure as it happens, regardless of whether that change came through their own workflow or not.

The full picture:

DMARC enforcement is only as reliable as the DNS records underlying it. DNS records are only trustworthy if the domain and nameserver infrastructure is monitored for unexpected changes. And nameserver security is only consistent if the domain is registered through an account the MSP controls with appropriate access policies in place. These layers are part of the same stack — and gaps at any layer expose the ones above it.

What the transition to centralised management involves

Moving client domains from scattered registrar accounts into a single managed platform is not a one-afternoon project for a large portfolio. But it is a tractable one. The general approach is to prioritise domains where the access situation is most fragile — domains on client-personal accounts, domains with upcoming expiry dates, domains where DNS changes are frequent — and transfer those first.

For domains that can't be transferred immediately — because the client owns the relationship with a specific registrar, or because a transfer is locked pending expiry — the intermediate step is to establish proper delegated access with documented scope, and to add DNS monitoring so that any unexpected change at the registrar level raises an alert before it causes an outage.

Domain registration and DNS management built for MSPs — where the platform understands multi-tenancy and client isolation from the ground up — changes what's achievable at scale. Adding a DKIM record, checking expiry dates across a full client portfolio, or getting an alert when a nameserver changes becomes a two-click operation rather than a cross-team investigation.