Blog · October 22, 2026

Your domain and email: what you should own, and why

The accounts that should be in your name before a website project starts, and the handover checklist that stops a supplier from holding your business hostage.

A domain name and an email inbox connected to a set of account keys

The domain is the address of your business. The email is how people reach you. Neither should live in someone else's account.

This is not a technical point. If a supplier owns the domain and the relationship ends badly, you can lose the address your customers already know. If the email is on a personal account, a staff change can take the whole inbox with it.

The fix is simple, and it is easier before the project than after.

The domain

Register the domain in your name, with an account you control. That means:

  • The registrant name and email are yours, not the developer's.
  • You have the registrar login and can reset the password.
  • Auto-renew is on, and the card on file is yours.
  • The domain is not locked to a reseller with no transfer option.
  • WHOIS privacy is on, unless you need the owner details public.

If a developer registers it for you, ask for the registrar, the account email and the transfer process in writing. A domain can be transferred, but it is much easier when the current owner cooperates.

The DNS

DNS is the set of records that points the domain at your website and your email. You do not need to understand every record type. You do need access to the place where they are edited.

Common records:

  • A or CNAME: points the domain at the website host.
  • MX: points email at the mail provider.
  • TXT: verifies ownership and carries email security records such as SPF and DMARC.

If the DNS is in the developer's account, you can still run the site, but you cannot move it without them. Ask for access, or ask for the records in a document.

The email

A custom address on Google Workspace, Microsoft 365 or a similar provider is a subscription in your name. That means:

  • The admin account belongs to you.
  • Billing is on your card.
  • You can add and remove users.
  • You have recovery options that do not depend on one person's phone.
  • The MX records point at the provider you chose.

A shared inbox such as hello@ can be a group or alias. That is fine, but someone needs to own the admin account behind it.

What a handover should include

At the end of a project, ask for:

  • Registrar name, login email and renewal date.
  • DNS provider and a list of the records.
  • Email provider, admin account and billing details.
  • Hosting or deployment account.
  • Analytics and Search Console access, if used.
  • Source files and a copy of the live site.
  • A note of any subscriptions and their renewal dates.

Put it in one document. A handover that lives in a chat thread is not a handover.

Red flags

  • "The domain is registered for you" with no mention of the account.
  • The domain is in the agency's name because it was "easier".
  • The email is on a personal Gmail address with the company name in the display name.
  • You have a website login but not the registrar or DNS.
  • The renewal invoice arrives from someone else's account.
  • Nobody knows who has the recovery phone number.

None of these are unusual. All of them are fixable. The time to fix them is before the next project, not during a dispute.

What I do

When I build a website, the domain and email are set up in your name. You pay the subscriptions directly. I help with the records, the Workspace setup and the testing, then hand over the accounts.

That is part of the Websites service, not an extra. If you already have accounts, I work with what you own. If you do not, I set them up properly.

Owning your accounts is not a technical detail. It is the difference between a website you can leave and a website that can leave you.