Before you change website providers, check who controls your domain, DNS and email

Three things that are easy to mix up

1. The domain registration. This is your right to use your web address (for example, yourclinic.com). It is held through a company called a registrar. ICANN describes the registrant, also called the "Registered Name Holder", as "the person or entity that holds the rights to a domain name." (Source: ICANN general FAQ)

2. DNS (the internet's address book). DNS records point your domain at things. For example, A records map a domain name to an internet address, and an MX record "is required to deliver email to a mail server." (Source: Cloudflare: record types) These records are served by nameservers, which Cloudflare's documentation describes as DNS servers that answer queries for the domains they are responsible for. (Source: Cloudflare: nameservers) Microsoft notes that your registrar and your DNS hosting provider "are often the same company, but they can be different." (Source: Microsoft: find your registrar)

3. Email. If you use Google Workspace or Microsoft 365, your mailboxes live with that service, but mail only reaches them because of the MX records in your DNS. Microsoft describes the MX record as the one that "specifies where email for the domain should go." (Source: Microsoft: DNS records)

A website provider might control one, two or all three of these. The point of this review is to find out which.

Why the name on the registration matters

ICANN's own FAQ covers a situation many owners don't expect. If you hired a developer to help manage your domain, "they may have registered the domain name using their own contact details", even if you paid. You may then "need to provide proof of your payment" to show the registrar that you are the rightful holder. (Source: ICANN general FAQ)

ICANN has also written that letting a third party be listed as registrant "is generally not considered a good practice", and that an organization that outsources domain management "should ideally still be listed as the registrant of the domain." (Source: ICANN good-practice blog)

Two related details:

• Privacy and proxy services. With a privacy service, you remain the registrant of record and alternative contact details are published. With a proxy service, "the proxy service becomes the registered name holder of record." (Source: ICANN privacy/proxy) It is worth knowing which one you have.
• Renewal reminders. ICANN policy requires registrars to send renewal reminders about one month and one week before a domain expires, and ICANN advises keeping your contact information up to date so you receive them. (Source: ICANN renewal FAQ) If the contact email belongs to a former provider or staff member, those reminders may not reach you.

The read-only checklist

Use this table to record what you find. "Who should own it" reflects the guidance cited. Your situation may call for a different arrangement, which is fine as long as it is a deliberate choice that is written down.

What to ask your current provider

Keep it friendly and in writing. At this stage you are asking for information, not making changes.

1. Which registrar is our domain with, and whose name and email are on the registration?
2. Who holds the login for the registrar account? Can a named person at our business be given access?
3. When does the domain renew, and where do renewal notices go?
4. Where is our DNS hosted, and can you send us a copy of our current DNS records?
5. Where is our email hosted, and who are the admin users on that account?
6. Do any other services use our domain (forms, booking tools, newsletters) and rely on records you manage?
7. When we move, what will you need from us, and what will you hand back?

Timing: why some changes take weeks, not days

A few rules are worth knowing before you choose a switch date. They come from ICANN's Transfer Policy, which governs transfers between ICANN-accredited registrars (Sources: ICANN Transfer Policy; ICANN transfer FAQ) and applies to generic domains, a group that ICANN says includes .com, .net and .org. (Source: ICANN gTLD definition)

• Moving to a new registrar needs an authorization code. ICANN says "An Auth-Code is required for a domain holder to transfer a domain name from one registrar to another." (Source: ICANN transfer FAQ) Registrars either let you generate it yourself or must provide it within five calendar days of your request. (Sources: ICANN Transfer Policy; ICANN transfer guide)
• Changing the registrant can trigger a 60-day lock. Under the current policy, a registrar "must impose a 60-day inter-registrar transfer lock following a Change of Registrant." A change to the registrant's name, organization or email address can count. A registrar may let you opt out before the change is requested, but it doesn't have to offer this. (Sources: ICANN Transfer Policy; ICANN transfer guide)
• New or recently moved domains. A registrar may refuse a transfer within 60 days of a domain's creation or of a previous transfer. (Source: ICANN Transfer Policy)
• These rules are under review. An ICANN working group has recommended shortening the post-creation and post-transfer periods to 30 days and removing the lock after a registrant change. Those recommendations went to the ICANN Board for consideration in 2025. (Source: ICANN comment report, 2025) As of October 2026 they were not yet in force: ICANN's transfer page still lists the policy updated in February 2024 as its latest version, and the policy project page shows the Board's adoption as still to be decided. (Sources: ICANN transfers page; GNSO policy project page) Before you plan around any of these timings, check ICANN's current policy page or ask your registrar which rules apply. (Source: ICANN transfers page)

Country-code domains are different: ICANN says their registration policies are managed locally, so check with your country's registry or your registrar. (Source: ICANN ccTLD page)

If you believe a registrar has wrongly refused a transfer, or hasn't provided the code, ICANN accepts complaints. (Sources: ICANN transfer FAQ; ICANN transfer guide)

Example handoff note (illustrative only)

This is a made-up example to show the format. The business, names and details are fictional.

What this checklist doesn't do

It won't move your domain or email, and it can't promise that a switch will go smoothly. What it gives you is a clear, written picture of who holds each key, so you and your next provider can plan the move with the right people involved.