How to Transfer a Domain to a Different Host
When you transfer a domain to a different host, you’re juggling more than just a registrar change, you’re also protecting your website, DNS, and email from disruption. You’ll need to plan ahead, back up everything, and coordinate DNS changes so visitors and mail don’t hit dead ends.
Done right, the move’s almost invisible to users. The challenge is knowing which steps you can’t afford to skip, and in what order.
Check If Your Domain Can Transfer Without Downtime
Before transferring a domain to a new host, first confirm that your new provider can fully handle your DNS so the move doesn't cause service interruption. DNS management, ensuring your website and email remain fully functional throughout the transfer process. Learn more about their service here:
Replicate all existing DNS records on the new nameservers, including A, MX, CNAME, and TXT records (such as SPF, DKIM, and DMARC). Reduce the TTL (time to live) values to around 300 seconds at least 48–72 hours before the transfer. This helps DNS changes propagate more quickly.
Use tools like dig or WhatsMyDNS to verify that the new DNS servers are responding correctly across multiple locations and wait until propagation is effectively complete. Keep the current MX records and email configuration unchanged until DNS propagation has finished to avoid email delivery issues.
After confirming that DNS is stable and fully propagated, unlock the domain, obtain the EPP/Auth code from your current registrar, and then initiate the registrar transfer.
Decide What to Move: Registrar, Hosting, Email, or All Three
Once you’ve confirmed you can switch DNS without downtime, decide precisely what you're moving: only the domain registration, your hosting and DNS, your email service, or all of these together.
A registrar transfer changes which company manages your domain record. It typically requires an EPP/auth code from the current registrar and, in many cases, adds one additional year to the registration term (subject to registry rules and any exceptions).
If you're changing DNS or hosting providers, plan to replicate all existing DNS records at the new provider before changing name servers. This includes A, AAAA, CNAME, MX, TXT, and any other relevant records.
If you intend to keep email hosted with your current provider, you must configure matching MX, SPF, DKIM, and DMARC records at the new DNS host to maintain email delivery and authentication.
If you're also moving mailboxes (for example, between IMAP, Exchange, or Google Workspace/Office 365 tenants), plan and complete the mailbox migration before changing DNS or MX records. This approach reduces the risk of message loss or delivery issues during the transition.
Back Up Your Site and Export All DNS/Email Records
Treat backing up your site and exporting DNS and email records as a required step before any domain move.
Begin by exporting a full DNS zone file from your current provider, including A, AAAA, MX, CNAME, TXT, SRV, and DKIM records, and save a clearly dated copy. Record your SPF configuration, DKIM selectors and keys, and DMARC policy so they can be reproduced accurately at the new provider.
Then create a complete backup of your site, including both files and databases, using your CMS tools or hosting control panel. Store backups in at least two locations (for example, local storage and a separate cloud location) and generate checksums to verify data integrity.
Finally, export all email data, mailboxes, contacts, calendars, and attachments, and verify that total mailbox sizes and message counts match what you see in the live accounts. This helps ensure that no data is lost during the transition.
Lower DNS TTLs Before You Transfer the Domain
Lower DNS TTLs (time-to-live) before moving a domain helps DNS changes propagate more quickly when you switch providers. Adjust key records, such as A, AAAA, MX, and CNAME, to a shorter TTL (for example, 300 seconds) at least 48–72 hours before modifying DNS settings or initiating a registrar transfer.
Resolvers continue using the previously cached values until their existing TTLs expire, so reducing TTLs in advance ensures the shorter values are in effect when you make the actual changes. Keep TTLs low during the transfer and for 24–48 hours afterward to limit the impact of any necessary adjustments. After this period, you can increase TTLs again (for example, to a range like 3600–86400 seconds) to reduce query load and improve cache efficiency.
Check your DNS provider’s policies for minimum allowed TTLs and any charges associated with frequent DNS updates, as these constraints may affect how aggressively you can lower TTLs.
Unlock Your Domain and Get the Authorization Code (EPP/Auth)
Before you can transfer your domain, you must unlock it at your current registrar and obtain its authorization code (often called the EPP, AuthInfo, or transfer code). Sign in to your registrar account, go to your domain management or settings area (frequently labeled “Manage Domains” or similar), and disable any registrar lock or transfer lock associated with the domain.
After the domain is unlocked, request or generate the Auth/EPP code. Many registrars display this code immediately in the control panel or send it by email. ICANN requires registrars for generic top-level domains (gTLDs) to provide the code within five days of request. Some country-code top-level domains (ccTLDs) don't use EPP codes and may follow different transfer procedures, so you should verify the specific rules for your domain extension.
Avoid changing the registrant contact information immediately before a transfer, as this can trigger a 60‑day transfer lock in many cases. Once you have the correct authorization code and the domain is unlocked, provide the code to your new registrar to initiate the transfer.
Set Up and Test Matching DNS and Email on the New Host
Smooth transfers begin by replicating your existing DNS and email configuration on the new host. Before updating name servers, export or record all existing DNS entries from your current provider, including A, MX, CNAME, and TXT records (such as SPF), along with DKIM and DMARC settings. Recreate these records exactly in the new DNS zone to maintain consistent behavior.
To reduce propagation delays, lower the TTL values to a short interval (for example, 300 seconds) 48–72 hours before making changes. Configure MX records and any email-related CNAME or TXT records on the new host to match the old setup. Then perform tests by sending and receiving email using the domain, verifying delivery, headers, and spam status where possible.
Keep the old mail server running or configured to relay mail during the transition. This reduces the risk of lost messages while DNS changes propagate and ensures a more reliable switchover.
Switch Name Servers and Monitor DNS/Email Propagation
Typically, you should switch your domain’s nameservers to your new provider only after you have fully replicated and verified the DNS zone. In your domain registrar’s control panel, update the NS records to point to the new provider’s nameservers so that the new DNS zone becomes authoritative at the time of transfer.
It is advisable to reduce TTL values (for example, to 300 seconds) 48–72 hours before changing nameservers to help changes propagate more quickly.
After the switch, monitor propagation using global DNS checking tools and verify that A, MX, CNAME, and TXT (including SPF, DKIM, and DMARC) records resolve as expected. Perform MX lookups and test SMTP connectivity to confirm mail flow. Maintain both the old and new DNS zones in parallel until DNS responses are consistent and email delivery remains stable.
Start the Registrar Transfer to Your New Domain Provider
Once your DNS records are stable and you're ready to move the domain registration, begin the registrar transfer by unlocking the domain at your current provider and requesting the authorization (EPP) code.
Under ICANN rules, your current registrar is required to provide this code within five calendar days.
At your new registrar, access the domain transfer tool, enter your domain name, provide the EPP code, and pay any applicable transfer fee.
Pricing varies by provider and TLD, so it's advisable to confirm the current fee (for example, common .com transfer fees are typically in the range of standard registration costs).
Monitor your email for confirmation messages from both the losing and gaining registrars and respond within the specified time frames, as failing to respond may delay or block the transfer.
Review ICANN’s 60‑day transfer lock policy, which can restrict transfers within 60 days of certain changes (such as recent registration or registrant information updates).
Track the status of your transfer from your new registrar’s transfer or domain management page until the process is complete.
Keep Email Flowing During Transfer (Microsoft 365, Google Workspace, Others)
During a registrar transfer, handle email as an independent, critical service and plan its migration separately to avoid disruption or data loss.
Before changing nameservers, record all relevant DNS entries (MX, SPF, DKIM, DMARC) and recreate them at the new DNS provider. Reduce DNS TTL values (for example, to 300 seconds) 48–72 hours in advance to make any changes propagate more quickly.
For Microsoft 365, consider using tools such as the Mailbox Replication Service (MRS) or configuring an Internal Relay domain and connectors so old and new mail systems can operate in parallel during the transition.
For Google Workspace and similar services, keep MX records pointed to the existing email host until the migration is complete, configure forwarding or a catch‑all address if appropriate, verify end-to-end mail flow with testing, and decommission the old host only after confirming that all mail is being delivered correctly to the new environment.
Run Post-Transfer Checks: DNS, SSL, DNSSEC, and WHOIS Privacy
After the registrar confirms your transfer, run a set of checks to ensure services continue to operate as expected.
Begin by comparing DNS records (A, AAAA, MX, CNAME, TXT, SPF, DKIM, DMARC) at the new provider with a recent export from the previous host. This helps confirm that websites, email delivery, and authentication remain consistent.
Next, verify that SSL/TLS is functioning correctly on both the apex domain and common subdomains (such as www). If necessary, reissue or reinstall certificates (for example, via Let’s Encrypt) and check for mixed-content issues that could affect security or browser behavior.
If DNSSEC was in use before the transfer, confirm that it remains correctly configured. This may involve re-enabling DNSSEC at the new registrar and adding or updating DS records at the registry level.
Finally, review WHOIS information to ensure that contact details, registrar data, and privacy or proxy settings are accurate and in line with your preferences. Over the following 48–72 hours, monitor DNS and service status using online tools to detect any propagation or configuration issues.
Conclusion
By planning ahead, backing up everything, and lowering DNS TTLs, you’ll make your domain transfer smooth and low‑risk. You’ll move your registrar, hosting, and email on your own schedule, keep messages flowing, and avoid unexpected downtime. Once the transfer finishes, you’ll verify DNS, SSL, DNSSEC, and WHOIS privacy so your site and email stay secure and stable. Follow these steps, and you’ll change hosts confidently without disrupting visitors or clients.