How to Transfer a Domain Without Breaking Everything

You unlock your domain at 9 AM on a Tuesday. You figure it will take maybe twenty minutes. You have a new registrar ready. You have the account set up. The transfer button is right there.

Then you notice a banner at the top of the screen.

"This domain is subject to a 60-day transfer lock. It cannot be transferred until [date two months from now]."

You renew your domain, and the lock resets. Every time. Most registrars reset the clock automatically on renewal, and they do not send a warning before they do it. You agreed to this in the terms of service you clicked through when you first registered. That agreement is the entire operating manual for your relationship with your registrar. Most people never read it.

Here's the thing: a domain transfer is not technically complicated. The hard part is the waiting, the dependencies, and the things that break quietly while the process runs. This guide covers all of it. Not what registrars say in their help articles. What actually happens.

The Pre-Transfer Checklist (Do This Before You Touch Anything)

The biggest transfer mistakes happen in the first five minutes. Someone decides to move their domain, clicks unlock, and starts the process without documenting what they already have. Then they wonder why their email stopped working.

Before you initiate anything, write down three things.

Your current DNS records. Every A record, CNAME, MX record, and TXT record. Log into your current registrar, open the DNS management panel, and copy every row into a document. This takes ten minutes. Skipping it costs days.

Your current nameservers. There is a difference between where your domain is registered and where it points. If your domain uses nameservers from a hosting provider (common with Squarespace, Wix, and many shared hosting setups), transferring the registration does not automatically move those nameservers. Your site may keep working. Your email may not. Understanding this distinction before you start will save you a significant amount of confusion.

Your registrar account email address. The transfer confirmation goes to the email address on file with your current registrar's WHOIS record. If that email address no longer exists, you cannot confirm the transfer. This is a more common problem than it sounds. People change email providers, retire old addresses, or did not realize their registrar still had their 2014 email on file.

What an EPP Code Is and Why You Need One

The EPP code goes by several names: authorization code, auth code, transfer key, EPP key. Different registrars call it different things. It is the same thing.

An EPP code is a password that authorizes a domain transfer. It proves to the gaining registrar (the one you are moving to) that the current registrant (you) has approved the move. Without it, the transfer cannot proceed.

Under ICANN policy, your current registrar is required to provide your EPP code within five business days of your requesting it. This is not optional. It is a rule. The registrar cannot charge you for the code. They cannot withhold it without cause. If they refuse or delay past five business days without a documented reason, that is an ICANN policy violation you can formally report.

Here is how to request it: log into your current registrar, navigate to domain management, look for a section labeled "transfer," "transfer out," or "authorization code." Most registrars will email it to you or display it on screen. If yours requires a support ticket, open one and document the date you submitted it.

Keep the EPP code somewhere safe. It expires. Most codes expire after 14-30 days, though this varies by registrar. If you start a transfer and it fails or times out, you may need a new code.

The 60-Day Lock Trap

This is the one that catches people off guard most often.

ICANN's Transfer Policy includes a provision called the Change of Registrant lock. When certain changes occur on a domain, including a registration renewal, the domain becomes locked against transfer for 60 days. The theory is fraud prevention: if someone hijacks your account and tries to move your domain immediately, the 60-day window gives you time to catch it.

In practice, it means this: if you renew your domain on January 1st, you cannot transfer it until at least March 2nd. Most registrars apply the lock automatically on renewal. They may not remind you before it kicks in.

A few scenarios where this catches people:

You decide to move your domain right after a renewal email arrives. You paid for another year, you unlock the domain, you start the transfer, and it fails. The renewal triggered the lock four days ago.

Your registrar gets acquired. The acquisition triggers account-level changes. Some registrars interpret this as a registration change and reset the transfer lock on affected domains. You find this out when you try to leave.

You update your contact information because you moved or changed email addresses. Depending on the registrar, updating registrant contact data can trigger the 60-day lock under ICANN's Change of Registrant policy. Some registrars are more aggressive than others about applying this.

If you are in the lock window and need to transfer urgently, your only real option is to contact your registrar and ask for an exception. This sometimes works for registrar shutdowns or documented abuse situations. It rarely works for "I just want to move." Plan ahead when you can.

DNS Propagation: What Breaks and for How Long

Here is a common misunderstanding: transferring your domain registration is not the same as moving your website or email.

When you transfer registration, you are moving the paperwork. The domain still points wherever it pointed before, until you change the nameservers or DNS records at the new registrar. If you set up your DNS records correctly at the new registrar before the transfer completes, the transition can be nearly seamless. If you wait until after the transfer to configure DNS, you have downtime.

The DNS propagation window is the time it takes for DNS changes to spread across the internet's resolver network. The industry standard range is 24-48 hours, though most changes propagate faster now. The exact speed depends on your TTL (Time to Live) settings on DNS records.

TTL is the value that tells DNS resolvers how long to cache a record before checking for updates. If your TTL is set to 86400 (24 hours), resolvers will hold the old record for up to 24 hours after you change it. If you lower your TTL to 300 (5 minutes) 24-48 hours before initiating the transfer, propagation after the change will be much faster.

The practical sequence: lower your TTL at the current registrar 48 hours before you plan to move. Set up all your DNS records at the new registrar before the transfer initiates. After the transfer completes and nameservers propagate, verify your site and email are working before considering the job done.

Email Continuity During a Transfer

Email is the most commonly broken thing in a domain transfer. And it breaks quietly. Your site usually shows an obvious error if DNS is wrong. Email fails silently. Messages bounce, disappear, or route to the wrong place, and you may not find out for hours.

The specific risk: your email may be hosted through a service that points to your domain via MX records. Those MX records live in DNS. If your DNS configuration at the new registrar is incomplete or different from the current one, email delivery fails.

Before you transfer, check that your MX records are exactly correct at the new registrar. These look something like: @ MX 10 mail.yourdomain.com or, for Google Workspace: @ MX 1 aspmx.l.google.com. The exact values depend on your email provider. Most email services have documentation that lists the exact MX records to use.

After the transfer, send test emails both to and from your domain. Do not assume it is working. Test it.

If your email is set up through your current registrar (many registrars sell email as a bundled product), transferring the domain registration may disrupt or terminate that service. Check the terms. If your email service is tied to your registrar, you will need to either migrate email to a standalone provider before transferring or set up a new email service at the new registrar before the move.

The Step-by-Step Transfer Walkthrough

This is the operational sequence for a clean transfer.

Step 1: 48-72 hours before transfer. Lower DNS TTL values at your current registrar to 300 seconds (5 minutes). This minimizes propagation delay when you make DNS changes at the new registrar.

Step 2: 24 hours before transfer. Set up all DNS records (A, CNAME, MX, TXT, any others) at the new registrar. Match them exactly to your current configuration. Do not activate them yet. Have them ready.

Step 3: Verify the 60-day lock. Confirm the transfer lock is not active on your domain. If it is, find the unlock date and plan accordingly.

Step 4: Disable domain privacy temporarily. Some registrars require WHOIS contact information to be visible for transfer confirmation to work. Disable privacy protection briefly if your registrar requires it.

Step 5: Request the EPP code. Log into your current registrar and request the authorization code. Document the date and time you requested it.

Step 6: Unlock the domain. In your current registrar's settings, disable the transfer lock. This is usually labeled "unlock domain" or "enable transfer."

Step 7: Initiate the transfer at the new registrar. Enter your domain name and EPP code. The gaining registrar sends a transfer request to the losing registrar.

Step 8: Confirm the transfer. Watch the email address on file with your current registrar. A confirmation email will arrive. Some registrars require you to approve it. Others run a passive approval window: if you do not deny it within 5 days, the transfer proceeds automatically.

Step 9: Verify propagation. After the transfer completes (typically 5-7 days for the full process, though often faster), verify your site and email are functioning correctly. Use a tool like DNS Checker to confirm nameservers have propagated globally.

Step 10: Re-enable domain privacy at the new registrar if you want it active.

What to Do If Transfer Is Refused

If your current registrar refuses the transfer, delays it beyond the ICANN-mandated window, or cites vague policy reasons without documentation, you have options.

First, ask the registrar to specify in writing the exact reason for the denial. ICANN policy allows registrars to refuse a transfer under specific, documented circumstances (such as a pending legal dispute or unresolved UDRP proceeding). Vague refusals without documentation are not compliant.

Second, file a complaint with ICANN. ICANN's Registrar Compliance team handles violations of the Transfer Policy. The complaint process is documented at icann.org. This does not produce instant results, but it creates a formal record and often prompts registrar action.

For a deeper look at the full range of tactics registrars use to prevent you from leaving, and what your rights are in each scenario, read Can Your Registrar Hold Your Domain Hostage. That article covers the specific patterns in detail.

You have the right to transfer your domain. ICANN's Transfer Policy exists to protect that right. Understanding it before you need it makes the difference between a transfer that takes a week and one that takes three months.

What the Transfer Transfers (and What It Doesn't)

A domain transfer moves registration. It does not automatically move:

• Your website files (those live on a hosting server, which is separate)
• Your email history (that lives with your email provider)
• SSL/TLS certificates tied to the old registrar
• Any services bundled by the current registrar (email, website builder, DNS management features specific to that registrar)

Understand what you are actually moving. The registration is the authorization layer, the paperwork that says you have the right to use this domain name for the registered period. Everything that depends on the domain to function (site, email, apps) continues to work as long as your DNS records point correctly, regardless of where the registration lives.

This is also why the guidance to keep domains and hosting separate matters so much. When your registration, hosting, and email are all bundled at the same provider, a transfer becomes a migration of everything at once. Keeping them separate means a registration transfer stays contained. You change the paperwork. The systems keep running.

The domain itself accumulates history. Every day of consistent signals, every connection to structured content and verified addresses, every renewal on time. That history moves with the registration. It is one of the few forms of continuity in domain ownership that survives a registrar change cleanly.

Which is worth thinking about before you transfer. Not whether to move. But what you are carrying with you when you do.

Read more about the mechanics of trust as infrastructure and how continuity of ownership signals credibility over time. For context on what you actually own when you register a domain, start with Do You Actually Own Your Domain? What ICANN Says.

For the companion article on what you actually signed when you registered your domain, and what ICANN says about the limits of domain ownership, read Do You Actually Own Your Domain?. For context on the expiry risks that often prompt a transfer decision, see Your Domain Expires One Day at a Time. And for the long-term question of which registrar to trust with your domain going forward, the independent analysis is in Best Domain Registrars for Long-Term Ownership in 2026.