Transferring a Domain Registrar Without Breaking Email and Websites

A registrar transfer does not have to cause downtime. Keep two things separate: the registration (who the domain is registered with) and DNS hosting (which nameservers answer for the domain). If you keep the same nameservers, or you rebuild every DNS record at the new provider and compare them before switching, email and websites carry on as normal.

Who this is for and what you will have

This guide is for administrators who manage a business domain used for a website and Microsoft 365 email and want to move it to another registrar, for example for cost, control or consolidation. By the end you will have a record inventory, a safe order of operations, a transfer that is ready to approve, and a verification routine.

Registration versus DNS hosting

Microsoft's guidance puts it simply: your registrar and DNS hosting provider are often the same company but can be different. The registrar manages the domain registration, and the DNS hosting provider manages the DNS records that route traffic for the domain.

That distinction decides your risk:

Never assume DNS records move automatically with the registration. Check the old and new registrars' documentation to see what happens to the DNS zone when the domain leaves, and recreate the records yourself.

Step 1: Find out who hosts what

Use the ICANN lookup page at https://lookup.icann.org/, as Microsoft's documentation describes:

1. Enter your domain, for example contoso.com, and select Lookup.
2. The Registrar Information section lists the current registrar.
3. In Domain Information, the Nameservers entries show which provider hosts your DNS. If the nameservers are on a different domain, look that domain up to identify the DNS provider.

You can also check from PowerShell:

Resolve-DnsName contoso.com -Type NS

Write down both answers.

Step 2: Inventory every DNS record

This step prevents most failures. Export the zone if your DNS host offers a zone file export, and record every entry by hand if not. Query the live records as well, because the dashboard might hide some:

$domain = "contoso.com"
foreach ($type in "A","AAAA","CNAME","MX","TXT","NS","SRV","CAA") {
  Write-Host "== $type"
  Resolve-DnsName $domain -Type $type -ErrorAction SilentlyContinue
}

This only queries the root of the domain. Subdomain records such as www, autodiscover, selector1._domainkey and _dmarc have to be queried by name. For background on the record types, see /blog/dns-records-explained-a-cname-mx-txt.

Records that Microsoft 365 uses

For domains connected to Microsoft 365, compare your inventory against the records in the admin center under Settings > Domains > select the domain > DNS records. Microsoft's documentation lists these for email:

For other services, Microsoft's examples include the Teams SRV record _sipfederationtls (TCP, port 5061, target sipfed.online.lync.com) and the Intune CNAME records enterpriseregistration and enterpriseenrollment. Your own tenant may not use them, so copy what is actually in your zone.

Include the records that are not Microsoft's too: the website A or CNAME records, other mail services, domain verification TXT records for other vendors, DMARC (_dmarc), CAA records and any SaaS CNAMEs. If you are unsure about email authentication, see /blog/spf-dkim-dmarc-microsoft-365-setup.

Two details from the Microsoft documentation are worth remembering when you recreate records. First, Exchange Online only supports TTL values less than 6 hours (21,600 seconds). Second, if an SPF record already exists, do not add a second one: there should be a single SPF TXT record that includes the values for all senders.

Step 3: Decide where DNS will live

There are two clean paths.

Path A: Keep DNS where it is

Point the new registrar at the same nameservers, or, better, move DNS to a dedicated DNS provider before the transfer so the two decisions are independent. With this path your records never change and the transfer is only a registration event. This is the lowest-risk approach.

Path B: Move DNS to the new registrar

1. Create the zone at the new DNS host.

2. Recreate every record from your inventory.

3. Compare the new zone with the old one by querying the new nameservers directly:

   Resolve-DnsName contoso.com -Type MX -Server ns1.newdnshost.example
   Resolve-DnsName contoso.com -Type TXT -Server ns1.newdnshost.example
   Resolve-DnsName autodiscover.contoso.com -Type CNAME -Server ns1.newdnshost.example
   Resolve-DnsName selector1._domainkey.contoso.com -Type CNAME -Server ns1.newdnshost.example

4. Only when every answer matches, change the nameservers at the registrar. Resolvers cache the old nameserver answers until their TTLs expire, so leave the old zone in place until you have confirmed the change everywhere.

Microsoft also documents a variant where you change nameservers so that Microsoft 365 hosts the DNS records, or you keep your DNS host and add records manually. Use the provider-specific articles in Microsoft's documentation for details on your DNS host.

Step 4: Prepare the transfer

Do these steps a week or more before the date you need, because several of them have waiting periods.

1. Check the age of the registration. ICANN's transfer policy allows a registrar to deny a transfer requested within 60 days of the creation date shown in the registry Whois record, and a domain can also be protected for a period after an earlier inter-registrar transfer.
2. Check for recent registrant changes. ICANN states that registrars must impose a lock preventing any transfer to another registrar for 60 days after a change to the registrant name, organisation or email address (or the administrative email when no registrant email exists). Registrars may, but are not required to, let you opt out before making the change. Avoid editing contact details until the transfer is complete. ICANN reform of this rule has been under discussion, so check the current rule rather than relying on this summary. The policy page cited in References is the 2016 text; it notes that ICANN published an updated Transfer Policy on 21 February 2024 to reflect the Registration Data Policy, so confirm the provisions in this section against the current version and your registrar's own terms.
3. Confirm the registrant contact email is one you can read. Transfer confirmations are sent there.
4. Unlock the domain. Domains in registrar lock status carry the ClientTransferProhibited status. ICANN's policy requires registrars to give the registered name holder the authorization code and, where the holder cannot manage the lock themselves, to remove the lock within five calendar days of the request.
5. Request the authorization code (also called the transfer or EPP code) and treat it like a password.
6. Renew if the domain is close to expiry. A completed transfer adds a one-year extension to the existing registration under ICANN's policy, with a total unexpired term capped at ten years, and your new registrar will usually charge for that year.
7. Lower the TTL on records you will change, if you plan Path B, a day or more ahead so caches expire quickly. Microsoft's examples use 3600 seconds.

Step 5: Run the transfer

1. At the new registrar, start an incoming transfer and enter the domain and authorization code.
2. Confirm the nameserver option. Choose to keep the current nameservers unless you completed Path B.
3. Approve the transfer emails. ICANN's policy requires the current registrar to send the transfer confirmation within 24 hours of receiving the request from the registry. If the current registrar does not respond within five calendar days, the transfer receives a default approval, so you do not need to wait the full period if you approve it sooner.
4. Do not change DNS, nameservers or contact details while the transfer is pending, unless your plan says otherwise.

Step 6: Verify after the transfer

Registration:

• Look the domain up again at https://lookup.icann.org/ and confirm the new registrar and the expiry date.

DNS and email:

Resolve-DnsName contoso.com -Type NS
Resolve-DnsName contoso.com -Type MX
Resolve-DnsName contoso.com -Type TXT
Resolve-DnsName autodiscover.contoso.com -Type CNAME
Resolve-DnsName selector1._domainkey.contoso.com -Type CNAME
Resolve-DnsName selector2._domainkey.contoso.com -Type CNAME

Then check in the Microsoft 365 admin center: go to Settings > Domains, select the domain and review DNS records for any errors. Send test messages in both directions and open the website over HTTPS. Check the message headers of an external message for SPF, DKIM and DMARC passes.

Troubleshooting

The transfer is rejected

Check the three common causes: the domain is still locked, the authorization code was mistyped or has expired, or one of the 60-day restrictions applies. Ask the current registrar to state the reason; ICANN's policy lists the situations in which a registrar may deny a transfer.

Mail stops arriving after the nameserver change

The MX record is missing or different at the new DNS host. Recreate it exactly as shown in the Microsoft 365 admin center. If the previous provider's MX records are still present, remove them or give them a lower priority, because lower numbers have higher priority in MX records.

Messages are marked as spam or fail authentication

Check the SPF TXT record exists and that there is only one. Then confirm the DKIM CNAME records, which can be recreated from the admin center. See /blog/dkim-cname-missing-microsoft-365-fix for the usual error.

Outlook keeps asking for credentials or cannot configure

The autodiscover CNAME is missing or points to the wrong target. Recreate it from the admin center values.

Teams or device enrolment stops working

The SRV or CNAME records for those services were not copied. Compare against the DNS records page in the admin center.

Websites show errors or certificates fail

Check the website A, AAAA and CNAME records against your inventory, and any other records the site depends on, such as CAA and verification TXT records.

Checklist

• Registrar and DNS host identified using the ICANN lookup and Resolve-DnsName -Type NS.
• Full DNS inventory saved, including MX, SPF, autodiscover, DKIM, DMARC, SRV and CNAME entries.
• Decision made: keep DNS in place (Path A) or recreate and compare the zone first (Path B).
• Domain age and recent registrant changes checked against the 60-day rules.
• Domain unlocked, authorization code obtained, contact email accessible, renewal date known.
• TTLs lowered ahead of any DNS change.
• Transfer approved and nameservers left alone unless Path B is complete.
• Post-transfer checks run: registrar, NS, MX, SPF, DKIM, autodiscover, website, test emails.

References

• Find your domain registrar and DNS hosting provider (Microsoft 365 admin): https://learn.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/find-your-domain-registrar
• Connect your domain by adding DNS records (Microsoft 365 admin): https://learn.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/create-dns-records-at-any-dns-hosting-provider
• Gather the information you need to create DNS records: https://learn.microsoft.com/en-us/microsoft-365/admin/get-help-with-domains/information-for-dns-records
• ICANN Transfer Policy: https://www.icann.org/resources/pages/transfer-policy-2016-06-01-en
• ICANN, About Change of Registrant: https://www.icann.org/resources/pages/ownership-2013-05-03-en
• ICANN Lookup: https://lookup.icann.org/