Tutorial

Domain Transfer Guide: Move Without Losing Email or Website

June 11, 2026

Back to Blog
Managing servers the hard way? Panelica gives you isolated hosting, built-in Docker and AI-assisted management.
Start free

Understanding the Three Types of Domain Transfer

Before diving into the process, it is essential to understand that "domain transfer" can mean three very different things. Confusing them leads to unnecessary downtime and lost emails.

Registrar Transfer

Moving your domain registration from one registrar to another (e.g., GoDaddy to Cloudflare). DNS records, website, and email are not affected unless you change nameservers during the process. The domain's WHOIS registrar field changes.

Duration: 1-7 days

DNS Migration

Changing your nameservers to a different DNS provider (e.g., from registrar's DNS to Cloudflare). The domain stays at the same registrar. Your website and email continue working if you recreate all DNS records at the new provider first.

Duration: Minutes to 48 hours

Full Migration (Server + DNS + Registrar)

Moving everything: domain registration, DNS, website files, databases, and email. This is the most complex scenario and requires careful coordination to avoid downtime. Each component must be migrated in the correct order.

Duration: 1-14 days total

This guide covers all three scenarios with specific focus on avoiding email and website interruptions. Whether you are moving a single blog or a business with 50 email accounts, the principles are the same.

Pre-Transfer Checklist: Do This Before Anything Else

Preparation is 90% of a successful domain transfer. Skip any of these steps and you risk downtime.

1
Document all current DNS records. Export your complete DNS zone from your current provider. Include A records, CNAME records, MX records, TXT records (SPF, DKIM, DMARC), SRV records, and any custom records. Screenshot or export to a file — you will need to recreate every single one.
# Export all DNS records using dig
$ dig example.com ANY +noall +answer
example.com. 3600 IN A 93.184.216.34
example.com. 3600 IN MX 10 mail.example.com.
example.com. 3600 IN TXT "v=spf1 ip4:93.184.216.34 -all"

# Don't forget subdomain records
$ dig mail.example.com A +short
93.184.216.34
$ dig www.example.com A +short
93.184.216.34
$ dig _dmarc.example.com TXT +short
"v=DMARC1; p=quarantine; rua=mailto:[email protected]"
2
Lower DNS TTL values 48 hours before the transfer. Change all TTL values from their default (usually 3600 or 86400 seconds) to 300 seconds (5 minutes). This ensures that when you make DNS changes during the transfer, the old records expire quickly from caches worldwide.
3
Verify domain eligibility for transfer. Your domain must be unlocked, must not have been transferred or registered within the last 60 days (ICANN policy), and must not be expired. Some TLDs have additional restrictions.
4
Disable WHOIS privacy protection. Most registrars require WHOIS privacy to be disabled during transfer so the authorization email can reach the domain owner. Re-enable it at the new registrar after the transfer completes.
5
Obtain the EPP/Authorization code. This is a unique code that proves you own the domain and authorize the transfer. Request it from your current registrar — it is usually found in the domain management section.
Critical Warning: Never let your domain expire during a transfer. If the domain expires mid-transfer, the transfer will fail and you may enter a redemption period where recovering the domain costs significantly more. Renew your domain at the current registrar before initiating the transfer.

Email Continuity: The Most Critical Part

Email is the most fragile component during a domain transfer. Unlike website traffic, which can tolerate brief interruptions, lost emails are gone forever. The key insight is that MX records tell the world where to deliver your email — as long as MX records point to a working mail server, email keeps flowing.

Scenario A: Keeping the Same Mail Server

If you are only transferring the registrar or DNS provider but your mail server stays the same (same IP, same Postfix/Dovecot), email continuity is straightforward.

  • Record your current MX records and their priorities exactly
  • Record the A record for your mail hostname (e.g., mail.example.com)
  • Record all email-related TXT records: SPF, DKIM, DMARC
  • At the new DNS provider, create these records BEFORE changing nameservers
  • Verify MX resolution from the new nameservers before going live

Scenario B: Changing Mail Servers

If you are also migrating to a new mail server, the process requires more careful timing.

Set up new mail server
Create all accounts
Import existing mail
IMAP sync or backup
Update MX records
Point to new server
Monitor both servers
48 hours overlap
Decommission old
After DNS propagation
The 48-Hour Overlap Rule: Keep both the old and new mail servers running for at least 48 hours after changing MX records. During DNS propagation, some sending servers will still have the old MX cached and will deliver to the old server. Check the old server's inbox periodically and forward any stragglers.

Email Backup Before Transfer

Always back up all email accounts before any domain transfer. Use IMAP synchronization to create a local copy of every mailbox.

# Sync all email using imapsync (install: apt install imapsync)
$ imapsync \
  --host1 old-mail.example.com --user1 [email protected] \
  --password1 'oldpass' \
  --host2 new-mail.example.com --user2 [email protected] \
  --password2 'newpass' \
  --ssl1 --ssl2

Host1: 3847 messages in 12 folders
Host2: 0 messages
Syncing...
Transferred: 3847/3847 messages (100%)

The Registrar Transfer Process: Step by Step

Once preparation is complete, the actual transfer follows a standardized ICANN-mandated process. While the interface varies between registrars, the steps are identical.

1
Unlock the domain at the current registrar. Look for "Domain Lock", "Transfer Lock", or "Registrar Lock" in your domain settings. Set it to "Unlocked". Some registrars call this "clientTransferProhibited" status — it must be removed.
2
Request the EPP/Auth code. This is sent to the domain registrant email. Some registrars display it immediately in the dashboard; others email it. The code is typically valid for 5-14 days.
3
Initiate the transfer at the new registrar. Enter your domain name and the EPP code. You will usually need to pay for one year of renewal — this extends your domain registration by one year from the current expiration date.
4
Approve the transfer. The current registrar sends a confirmation email to the domain registrant. You must approve (or not reject) this request. Some registrars auto-approve after 5 days of no response.
5
Wait for transfer completion. ICANN allows up to 7 days, but most transfers complete in 1-3 days. During this time, your domain continues to work normally — DNS records are not affected by the transfer itself.
6
Verify at the new registrar. Once complete, check that all your domain settings transferred correctly: nameservers, WHOIS information, auto-renewal, and domain lock status.

Registrar-Specific Transfer Procedures

RegistrarUnlock LocationEPP CodeTransfer TimeNotes
GoDaddyDomain Settings → Domain LockEmail or Dashboard5-7 daysMust disable privacy
NamecheapDomain List → Manage → Sharing & TransferDashboard (instant)3-5 daysFree WHOIS privacy
CloudflareDomain Management → ConfigurationDashboard1-5 daysAt-cost pricing, no markup
Google DomainsRegistration Settings → Transfer LockDashboard5-7 daysNow Squarespace Domains
PorkbunDomain Management → Authorization CodeDashboard (instant)3-5 daysCompetitive pricing
HoverDomain Overview → Transfer LockEmail request5-7 daysClean interface

ICANN Transfer Policy: What You Need to Know

60-Day Lock Rule: ICANN requires a 60-day lock after any domain registration or transfer. You cannot transfer a domain within 60 days of registering it, and after a transfer completes, another 60-day lock begins. Additionally, changing the WHOIS registrant name or email triggers a new 60-day lock at some registrars. Plan accordingly.

Other ICANN policies that affect transfers:

  • Transfers must be completed within 7 calendar days of initiation
  • The losing registrar cannot charge a fee to release the domain
  • The gaining registrar must add one year of registration (paid by you)
  • Expired domains can be transferred during the renewal grace period (varies by TLD)
  • Some country-code TLDs (.uk, .de, .eu) have different transfer rules than generic TLDs

Post-Transfer DNS Verification

After the transfer completes, you must verify that DNS is resolving correctly. This is especially important if the transfer changed your nameservers.

# Check nameservers
$ dig example.com NS +short
ns1.newprovider.com.
ns2.newprovider.com.

# Verify A record resolves
$ dig example.com A +short
93.184.216.34

# Verify MX records for email
$ dig example.com MX +short
10 mail.example.com.

# Verify SPF
$ dig example.com TXT +short | grep spf
"v=spf1 ip4:93.184.216.34 -all"

# Check from multiple DNS servers to confirm propagation
$ for dns in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo -n "$dns: "; dig @$dns example.com A +short
done
1.1.1.1: 93.184.216.34
8.8.8.8: 93.184.216.34
9.9.9.9: 93.184.216.34

Avoiding Downtime: The Zero-Downtime Transfer Strategy

Here is the exact sequence to transfer a domain with zero downtime — whether you are moving registrars, DNS providers, or both.

DayActionPurpose
D-2Lower all TTLs to 300 secondsEnsure fast DNS propagation when changes happen
D-1Document and recreate all DNS records at new providerNew DNS is ready before switching
D-1Verify new DNS records using dig @new-nsConfirm records are correct before going live
D-0Change nameservers (or initiate registrar transfer)Begin migration
D-0Monitor DNS propagation with dig @multiple-resolversTrack when the switch takes effect globally
D+1Verify website and email from multiple locationsConfirm everything works end-to-end
D+2Restore TTLs to normal values (3600+)Reduce DNS query load once stable
D+7Decommission old DNS/mail if migrating serversClean shutdown after full propagation

Transferring Multiple Domains

When transferring multiple domains, batch processing saves time but requires extra caution. Here are best practices for bulk transfers.

  • Transfer domains in batches of 10-20, not all at once — if something goes wrong, the blast radius is limited
  • Start with your least critical domain as a test run
  • Unlock all domains in a batch before initiating any transfers
  • Use a spreadsheet to track: domain name, EPP code, transfer status, DNS records documented, email accounts
  • Some registrars offer bulk transfer tools (Cloudflare, Namecheap) that process multiple EPP codes at once
  • Stagger batches by 24 hours to allow monitoring between groups

Common Mistakes and How to Avoid Them

Mistake

Forgetting to recreate DNS records at the new provider before changing nameservers.

Prevention

Always set up DNS at the new provider first. Verify with dig @new-ns example.com. Only change nameservers after confirming all records resolve correctly.

Mistake

Not lowering TTL before transfer, causing 24+ hour propagation delays.

Prevention

Lower TTL to 300 seconds at least 48 hours before the transfer. The old TTL must expire from caches before the low TTL takes effect.

Mistake

Letting the domain expire during transfer, entering redemption period.

Prevention

Renew the domain at the current registrar for at least one year before initiating the transfer. The extra renewal cost is negligible compared to redemption fees.

Mistake

Missing email-related DNS records (DKIM, DMARC) during recreation, causing email delivery failures.

Prevention

Use dig example.com ANY and check for _dmarc, _domainkey, and other underscore-prefixed records that are easy to miss in standard DNS exports.

Special Cases: Country-Code TLDs

Country-code TLDs (ccTLDs) like .uk, .de, .eu, .nl, and .au have their own transfer policies that often differ from the standard ICANN process for generic TLDs (.com, .net, .org).

TLDTransfer MethodDurationSpecial Notes
.ukIPS tag change (no EPP code)Instant to 48 hoursChange IPS tag at current registrar
.deAuthInfo code (like EPP)1-5 daysDENIC handles directly
.euAuth code via email5-7 daysMust be EU/EEA resident
.nlAuth code (transfer token)1-5 daysSIDN handles directly
.auAuth code1-5 daysEligibility requirements

How Panelica Simplifies Post-Transfer Setup

After transferring your domain to a new registrar, Panelica's domain management makes the hosting setup straightforward. Add your domain through the panel and Panelica auto-provisions the complete stack: Nginx virtual host, PHP-FPM pool, SSL certificate via Let's Encrypt, and DNS records if you are using the built-in BIND DNS server or Cloudflare integration.

For Cloudflare users, the panel's DNS integration automatically creates the A record, MX records, SPF, DKIM, and DMARC entries for your transferred domain. This eliminates the most error-prone part of post-transfer setup — manually recreating dozens of DNS records. The domain health check verifies all records are correct before you start receiving traffic.

Key Takeaway: Domain transfers are procedurally straightforward but require meticulous preparation. Lower TTLs 48 hours ahead, document every DNS record, back up all email, set up DNS at the new provider before switching nameservers, and keep both mail servers running for 48 hours of overlap. With this checklist, you can transfer any domain with zero downtime.
Security-first hosting panel

Run your servers on a modern panel.

Panelica is a modern, security-first hosting panel — isolated services, built-in Docker and AI-assisted management, with one-click migration from any panel.

Zero-downtime migration Fully isolated services Cancel anytime
Share:
Are your backups really safe?