Domain migration checklist: DNS, email, TLS and redirects

Which migration are you doing?

"Domain migration" covers several different projects, and they fail in different ways. Moving DNS hosting changes who answers queries; transferring the registrar changes who controls the delegation; moving mail changes where MX points; a rename changes every URL and address. Identify which of these you are doing, because each has its own critical step.

Step 1: inventory

Export the complete zone from the current DNS provider, as a zone file if possible. Many providers hide records that were added automatically, so compare the export with live queries. Pay special attention to records nobody remembers adding: they are often verifications for services that break silently when the record disappears.

for name in example.com www.example.com _dmarc.example.com _mta-sts.example.com; do
  for type in A AAAA CNAME MX TXT CAA; do
    dig +noall +answer "$name" "$type"
  done
done

Run Domain Health before you start and save the result. After the migration, the same check is a quick regression test for SPF, DMARC, MX, TLS, headers and redirects.

Step 2: lower TTLs

Resolvers cache records for their TTL. If a record has a TTL of one day and you change it, some users keep the old value for up to a day. Lowering TTLs to around 300 seconds at least one old TTL period before the change means the cutover reaches everyone within minutes, and so does a rollback.

Name server changes are different: the NS records for your domain in the TLD zone have their own TTL set by the registry, commonly one or two days, and you cannot lower it. Plan for both old and new name servers to receive queries for that period, which is why the old DNS provider must keep serving the zone until it passes.

Step 3: moving DNS hosting

1. Create the zone at the new provider and import every record from the inventory.
2. Compare answers from the old and new name servers directly for every name and type in the inventory.
3. Plan DNSSEC: if the zone is signed, follow the approach in the DNSSEC guide before changing name servers.
4. Change the name servers at the registrar.
5. Watch query logs at the new provider and error rates of your services.
6. Keep the old zone unchanged and served for at least the NS TTL plus a margin, then delete it.

dig @ns1.old-dns.example.net example.com MX +short
dig @ns1.new-dns.example.net example.com MX +short

dig @ns1.old-dns.example.net selector1._domainkey.example.com TXT +short
dig @ns1.new-dns.example.net selector1._domainkey.example.com TXT +short

Check the delegation afterwards with the WHOIS lookup for the name servers the registry has, and with DNS Lookup for what resolvers see.

Step 4: transferring the registrar

A registrar transfer does not have to touch DNS at all, and ideally it does not. Keep the name servers pointing at your DNS provider throughout, so the transfer is invisible to users. Do not start a transfer close to the expiry date, and check that the registrant contact email works, because transfer confirmations go there.

• Unlock the domain (remove the transfer lock) at the current registrar.
• Obtain the authorization code (auth code, EPP code).
• Confirm name servers and any DS records, and note them.
• Start the transfer at the new registrar and approve the confirmation messages.
• After completion, verify name servers, DS records, contacts and auto-renew; re-enable the transfer lock and registry lock if you use it.
• Expect a 60-day restriction on further transfers after a completed transfer, as allowed under ICANN transfer policy for generic TLDs.

Step 5: moving email

Mail tolerates short outages because sending servers retry, often for days. It does not tolerate authentication mistakes, which cause immediate rejection under an enforcing DMARC policy. Set up authentication for the new provider before any mail flows through it.

1. Verify the domain at the new mail provider and publish its DKIM records alongside the old ones.
2. Add the new provider to SPF while keeping the old one, and check the lookup count with the Email Security.
3. If you use MTA-STS, add the new MX hosts to the policy file and change the policy id at least one max_age before switching MX.
4. Migrate mailboxes, then change the MX records.
5. Watch DMARC aggregate reports and the old provider for mail still arriving there.
6. After a few weeks, remove the old provider from SPF, revoke its DKIM keys and update the MTA-STS policy.

Check the new MX records with the MX & SMTP after the change. Keep rua reporting on throughout; a sending system that still uses the old provider's relay shows up there.

Step 6: TLS certificates

Have a valid certificate on the new host before traffic moves. If the new platform issues certificates with HTTP validation, it may only be able to do so after DNS points at it, which creates a short window of certificate errors; DNS-based validation or uploading an existing certificate avoids that. With HSTS enabled, a certificate error is a hard outage for returning visitors.

• Check CAA records allow the certificate authority the new platform uses.
• Cover every host name, including www and any subdomains that move.
• Test the new host before cutover by connecting to its IP with the right host name.
• After cutover, confirm with the TLS Checker and set up expiry monitoring.

curl -sS -o /dev/null -w '%{http_code} %{ssl_verify_result}\n' --resolve example.com:443:192.0.2.80 https://example.com/

Step 7: renaming a domain

A rename is the largest migration because every link, bookmark, search result and email address points at the old name. The goal is that nothing ever breaks: old URLs redirect permanently to their new equivalent, old addresses keep receiving mail for a transition period, and the old domain stays registered. Redirect each page to its matching new page, not everything to the home page.

server {
    listen 443 ssl;
    server_name example.org www.example.org;
    return 301 https://example.com$request_uri;
}

• Build a URL map for pages whose paths change, and test it with the Redirect Checker.
• Use 301 redirects and keep them in place for years, not months.
• Tell search engines through their tools, for example the change of address feature in Google Search Console.
• Update OAuth redirect URIs, SSO settings, webhooks, API clients and hard-coded links in apps.
• Keep forwarding mail from old addresses for a transition period and tell contacts about the new ones.
• Keep the old domain renewed; an expired old domain can be registered by someone else and receive your traffic and mail.

Plan the rollback before you start

Every cutover step should have a written way back and a person who decides when to use it. With low TTLs, reverting a record change takes minutes; reverting a name server change takes as long as the NS TTL, which is why the old DNS provider must stay untouched. Write the rollback down before the change window, not during an incident.

Agree on the signals that trigger a rollback before the window opens, for example mail bouncing for more than fifteen minutes or the main site returning errors for a region. Clear criteria prevent both panic reversals of a healthy change and hours of debugging a broken one while users are affected.

Permanent redirects are the one change that is hard to undo, because browsers cache 301 responses. If you are not sure about a URL mapping, test it with 302 for a short period and switch to 301 once it is confirmed.

After the migration

Only decommission the old DNS zone, mail tenant or hosting after these checks pass. Cancelled services that still have DNS records pointing at them are also the classic setup for subdomain takeover, so remove those records as part of the clean-up.

FAQ

Sources

• RFC 1034: Domain Names, Concepts and Facilities (caching and TTL)
• RFC 8659: DNS Certification Authority Authorization (CAA)
• ICANN: Transfer Policy
• Google Search Central: Site moves with URL changes
• RFC 8461: MTA-STS