Moving a domain does not have to interrupt your website or email. This reusable checklist shows how to copy and verify DNS records, lower TTL values, prepare a registrar transfer, test the new setup, and keep a rollback plan ready if something does not resolve as expected.
Overview
A domain transfer changes which registrar manages your domain registration. It does not automatically move your website, email service, databases, files, or DNS records. Those services continue working only if their DNS instructions remain available and correctly configured.
The safest approach is to separate the project into two possible changes:
- Registrar transfer: You move the domain registration from one registrar to another while keeping the existing hosting and DNS arrangement.
- Hosting or DNS migration: You move the website, email, or authoritative nameservers to a new provider. This is where DNS records usually need to change.
You can complete both changes, but doing them at the same time makes troubleshooting harder. If possible, move the website or DNS first, confirm that it works, and transfer the registration afterward. If the transfer itself is the only goal, leave the DNS configuration unchanged and export a copy before you begin.
Before making changes, record the domain’s current registrar, expiration date, nameservers, DNS host, hosting provider, email provider, SSL setup, and any important subdomains. A domain transfer checklist is useful because forgotten records such as autodiscover, staging, or verification entries can affect services that are not visible on the main website.
Checklist by scenario
Scenario 1: Transfer the registrar and keep DNS unchanged
- Confirm that you can sign in to the current registrar and the administrative contact email.
- Check the domain’s renewal date and make sure payment and contact details are current.
- Export or manually copy the complete DNS zone, including A, AAAA, CNAME, MX, TXT, and any less common records.
- Note the current nameservers. Do not replace them merely because the registrar is changing.
- Check the registrar’s transfer requirements, including whether the domain can be transferred and where to obtain the authorization or EPP code.
- Follow the current registrar’s instructions for unlocking the domain if an unlock step is required. The exact control and wording vary by registrar and domain extension.
- Start the transfer at the new registrar using the correct authorization code.
- Monitor the transfer status and retain access to both registrar accounts until it is complete.
- After completion, confirm that the nameservers, DNS records, renewal date, and domain contact details still match your intended setup.
In this scenario, you normally do not need to wait for DNS propagation because the authoritative DNS service has not changed. Still, check the website, email, and important subdomains after the registrar reports completion.
Scenario 2: Move DNS or hosting without interrupting the domain
- Build and test the new website or hosting environment before changing public DNS. A staging environment on cloud hosting can help you test without altering the live site.
- Copy every record from the current DNS provider into a working migration sheet.
- Ask the new hosting provider for the exact destination values for the root domain,
www, and any required application subdomains. - Reduce the TTL on records you expect to change, using the lowest practical value supported by your DNS provider. Do this ahead of the planned change so cached answers have time to expire.
- Keep email records unchanged unless email is also moving. Website migration and email migration are separate tasks.
- Change only the required A, AAAA, or CNAME records, or change nameservers if you are moving the authoritative DNS service.
- Confirm the new site, redirects, forms, application paths, APIs, and SSL certificate before considering the migration complete.
- Use a DNS propagation checker and test from more than one network or resolver.
- After the change is stable, restore a sensible TTL for normal operation and document the final configuration.
Scenario 3: Transfer the domain and keep business email working
Email depends on more than the MX record. Preserve the MX records and also check TXT records used for SPF, DKIM, and DMARC, plus any provider-specific CNAME records. Use the business email authentication checklist to verify the authentication records before and after the change.
Do not guess at email values from memory. Copy the exact hostnames, priorities, trailing-dot conventions where relevant, and text values supplied by your email provider. If the email provider is changing too, schedule that as a separate workstream and confirm the new provider’s instructions immediately before making the change.
Reusable DNS sync template
Copy this table into your change record or spreadsheet. Record the current value first, then fill in the proposed value only for records that will change.
| Host/name | Type | Current value | Proposed value | TTL | Purpose and test |
|---|---|---|---|---|---|
| @ | A/AAAA | Root website; load HTTPS site | |||
| www | CNAME/A | Primary web alias; test redirect | |||
| @ | MX | Inbound email; send and receive test | |||
| @ | TXT | SPF or verification; inspect exact text | |||
| selector._domainkey | CNAME/TXT | DKIM; send authenticated message | |||
| _dmarc | TXT | DMARC; verify policy record | |||
| Other subdomains | Various | API, staging, checkout, or verification |
What to double-check
- Nameservers: Confirm which service is authoritative. Editing records at the wrong provider will not change public DNS.
- Root and www behavior: Test both versions of the domain, including the intended HTTPS redirect and canonical host.
- SSL: Verify that the certificate covers the domain and that automatic renewal can still complete. See the SSL troubleshooting guide if browsers show warnings.
- Email: Check MX, SPF, DKIM, DMARC, mail subdomains, and any provider verification records. Send a message in both directions.
- Hidden dependencies: Review payment callbacks, API endpoints, remote access tools, analytics verification, CDN settings, and developer environments.
- Backups and rollback: Keep a current website backup and a copy of the old DNS zone. A backup is useful only if you know how to restore it; use the backup and restore testing checklist.
- Monitoring: Record the time of each change and watch error logs, uptime checks, contact forms, and email delivery during the transition.
Rollback plan: If the new website fails, restore the previous A, AAAA, or CNAME values, or return to the previous nameservers if the entire DNS service was moved. Do not delete the new configuration immediately. Preserve it for comparison, then verify the old site from multiple networks and allow cached DNS responses to expire.
Common mistakes
- Changing nameservers without first copying the complete DNS zone.
- Assuming a registrar transfer also moves hosting, email, or website files.
- Lowering TTL after the DNS change instead of before it.
- Replacing an existing SPF record with a second SPF record rather than combining the provider-approved entries carefully.
- Forgetting subdomains, verification records, or service-specific CNAME records.
- Testing only from the office network, where cached DNS may hide a problem.
- Changing the website and email at the same time without a written sequence and rollback point.
- Closing the old registrar or hosting account before confirming that the new setup is stable.
For a broader review, compare your records with the DNS health audit checklist and the guide to pointing a domain to hosting.
When to revisit
Return to this checklist before every domain transfer, registrar consolidation, renewal or expiration review, hosting migration, DNS provider change, or email provider migration. It is also worth revisiting before a seasonal planning cycle when your team has time to test backups and document ownership.
Editors maintaining this guide should review registrar-specific screens, UI screenshots, and authorization-code workflows quarterly or after a relevant registry or industry policy change. Recheck provider examples and suggested TTL guidance annually, or sooner if major registrars change their interfaces. Recheck email instructions whenever a commonly used email provider changes its setup requirements.
Your practical next step is to create a dated copy of the DNS sync template, fill it from the current authoritative DNS provider, and identify one person who can approve rollback. On migration day, follow the recorded order, test website and email separately, check results through multiple resolvers, and keep the old configuration available until the new setup has passed its planned observation period. For related launch tasks, use the website launch and migration checklist and the domain renewal guide.