Blog / vendor management
Who Actually Owns Your Domain and Accounts?
A plain look at who really controls your domain, DNS, hosting and cloud accounts, why that matters more than most owners expect, and how to fix it.
Every few months I get asked to help with something that should take an afternoon. Move a website. Switch email providers. Point a domain at a new system. And then we find out the account everything depends on is not in the client's name.
Sometimes it is in a former employee's name. Sometimes it belongs to the web designer who built the site in 2016 and has since moved on. Once in a while nobody knows at all, and we are reduced to guessing at old email addresses to see which one gets the password reset.
This is not a rare failure. It is closer to the default state of a business that has grown by hiring whoever was available at the time.
The accounts that actually matter
Most businesses have dozens of logins, but only a handful of them are load bearing. If you lose access to these, everything downstream stops working and you cannot fix it yourself.
Your domain registration comes first. The domain is the anchor for your website and your email, and whoever controls the registrar account controls both. Everything else can be rebuilt in a week. A domain you cannot prove you own can take months to recover, if you recover it.
Then DNS, which is often not at the registrar. Then the hosting account, the email tenant (usually Microsoft 365 or Google Workspace), the cloud account if you have one, and whatever payment processor takes your money. If you sell online, add the SSL and the store platform. If you have custom software, add the source code repository, because a codebase living in a contractor's personal account is a real business risk, not a paperwork issue.
How it happens
Almost nobody sets out to hold a client hostage. The usual story is duller than that.
A vendor gets hired to do a job. They need a domain to do it, so they buy one on their own account and bill it back. It is faster than waiting two weeks for the client to open a registrar account and sort out a credit card. The vendor is being helpful. Five years later the helpfulness has hardened into a dependency nobody noticed forming.
The second common version: a staff member sets something up under their work email, leaves, the mailbox gets deleted, and the recovery address goes with it. The account still runs. It just cannot be recovered by anyone living.
Write the register before you need it
The fix starts as a boring document. I ask clients to build a one page list of critical accounts with four columns: what the service is, the legal entity or person named on the account, the email address that receives password resets, and who pays for it.
Fill it in honestly, including the rows where the answer is "not sure". Those rows are the work.
Two rules make the register hold up. The account should be in the business's name, not a person's, and the recovery email should be a shared mailbox or distribution address that survives an employee leaving. Something like [email protected] that two people can read. Personal mailboxes as recovery addresses are how companies lose accounts.
Store the register somewhere your accountant or your successor could find it. A password manager with a business vault is the sensible option. A spreadsheet in a drawer is worse but still better than nothing.
Getting ownership back
If a vendor holds something, ask plainly and in writing. Most will hand it over without drama, and a fair number will be relieved to stop being on the hook for a domain renewal they forgot they were paying.
Do it while the relationship is good. Asking for account ownership during a dispute reads as an accusation, and it puts a vendor who was going to cooperate on the defensive. Asking during a calm quarter reads as good housekeeping, because that is what it is.
For domains, the transfer process is standardised and you do not need permission so much as an authorisation code. For a Microsoft 365 or Google tenant, you are usually adding yourself as an administrator rather than moving anything. For hosting, ownership normally means having the account in your business name with your billing on file, which also means you can move providers on your own schedule. That last part is the whole point, and it is worth checking before you need it, not after. If you want a hosting account you actually control, my company DrivenHost is one option, but the principle holds wherever you go.
A vendor who refuses outright has told you something important about the rest of the relationship. That is worth knowing on a quiet Tuesday rather than during an outage.
What this is really about
Account ownership is not an IT chore. It is the difference between choosing your vendors and being stuck with them.
Every conversation I have about managing vendors well eventually comes back to this. Leverage in a vendor relationship is mostly the ability to leave. If your provider holds your domain, your DNS and your mailboxes, you do not have that ability, and both sides know it whether or not anyone says so. The same logic applies when you are choosing who builds your website: ask about account ownership before the work starts, when it costs nothing to agree on.
An afternoon with a spreadsheet buys you the option to change your mind later. That is a good trade.
If you want a second set of eyes on where your accounts sit and what would break if a vendor disappeared tomorrow, that is the kind of thing I do in a short assessment. Work is quoted as a fixed fee, hourly or on retainer, depending on what suits. Get in touch if it would help.