# Transferring a Domain Registrar Without Breaking Email and Websites

> Move a domain to a new registrar safely: export and compare DNS records, handle nameservers, prepare the transfer and verify Microsoft 365 email.

Source: https://www.epifive.com/blog/domain-registrar-transfer-dns-checklist · Published 2026-10-26 · EpiFive

## Key takeaways

- A registrar transfer moves the registration, while DNS hosting is a separate service that you must deliberately keep or move.
- Export or screenshot every DNS record, then recreate them at the new DNS host and compare the results before changing nameservers.
- Microsoft 365 needs MX, SPF TXT, autodiscover, DKIM and often Teams or Intune records, so confirm each one after any DNS move.
- Unlock the domain, get the authorization code and check for the 60-day restrictions well before the date you need the transfer to finish.
- Lower TTLs before the change and verify with Resolve-DnsName or nslookup against both the old and new nameservers.

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:

| Situation | What a transfer changes | Risk to email and web |
| --- | --- | --- |
| DNS hosted elsewhere (for example a separate DNS service), nameservers stay the same | Only registration | Very low |
| DNS hosted at the old registrar, nameservers point to the old registrar | Registration, and probably the DNS hosting | High unless you recreate the zone first |
| You move DNS to the new registrar as well | Registration and nameservers | Medium; depends on how carefully records are copied |

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:

```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:

```powershell
$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](https://www.epifive.com/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:

| Record | Host | Notes |
| --- | --- | --- |
| MX | `@` | Required. Copy the value from the admin center; priority typically 0 |
| CNAME | `autodiscover` | Optional but highly recommended; lets Outlook configure itself |
| TXT (SPF) | `@` | `v=spf1 include:spf.protection.outlook.com -all`, merged into a single SPF record if one exists |
| CNAME (DKIM) | `selector1._domainkey` and `selector2._domainkey` | Optional; values come from the admin center |

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](https://www.epifive.com/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:

   ```powershell
   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:

```powershell
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](https://www.epifive.com/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/

## Frequently asked questions

### Will transferring a domain to a new registrar cause downtime?

Not by itself. A registrar transfer changes who manages the registration, not where the domain points. Downtime happens when the DNS zone is hosted at the old registrar and the nameservers or records change during or after the transfer without the records being recreated first.

### How long does a domain transfer take?

It depends on the registry and registrars. ICANN's transfer policy gives the losing registrar five calendar days to respond to a registry notification, after which the transfer is treated as approved by default. Many transfers finish sooner when the current registrar approves quickly.

### Why is my domain transfer refused?

Common reasons are that the domain is still in registrar lock, the authorization code is wrong, or the domain was registered or transferred within the last 60 days. A recent change to the registrant name, organisation or email can also trigger a 60-day lock on transfers.

### Do I need to change MX records when I transfer a domain?

Only if the DNS zone moves. If you keep the existing nameservers, or you recreate every record at the new DNS host before switching nameservers, the MX records stay the same and Microsoft 365 mail keeps flowing.