Move a Domain Without Downtime:Lock, Auth Code, 60-Day Rules

To move a domain to a new registrar, you remove the transfer lock at your current registrar, get the auth code, start the transfer at the new registrar and approve the confirmation emails. Most failed transfers come down to two things you can check in five minutes: a 60-day window that blocks the move, or an auth code that was wrong or no longer valid.

Here is a fact that surprises people: under ICANN rules, if you change the registrant name, organization or email on a domain, the old registrar must refuse a transfer for 60 days unless you opted out before the change. Many people "tidy up" their contact details right before a transfer and lock themselves out for two months. Let's make sure that is not you.

What a domain transfer actually is

A domain transfer moves the registration of your domain from one registrar (the company you pay for the name) to another. ICANN calls the old one the losing registrar and the new one the gaining registrar.

Two pieces of jargon you will see everywhere:

• Transfer lock: a status on the domain that blocks transfers. In registration data it may show as clientTransferProhibited. ICANN says this status will "reject requests to transfer the domain from your current registrar to another."
• Auth code: also called an EPP code, AuthInfo code or transfer code. ICANN describes it as "a code created by a registrar to help identify the domain name holder and prevent unauthorized transfers."

Why this matters: ICANN's own registrant FAQ lists another option besides transferring: you can "update your domain name's nameservers or change the hosting IP address assigned to your domain name" without moving registrars at all. If you only want a new host, not a new registrar, our guide on how to point a domain to your hosting is the faster path.

Heads up: the rules in this guide are ICANN rules. They apply to generic top-level domains such as .com, .net, .org and similar. Country-code domains such as .uk, .in, .pk or .ae follow their own registry's rules, so read those before you start. This guide is general information, not legal advice.

Before you start

• Login access to your current registrar account, and to the email inbox of the domain's registrant contact.
• An account at the new registrar, and a payment method. Many transfers add renewal time. Cloudflare, for example, says "Most transfers include a one-year extension from your current expiration date." Check your new registrar's transfer and renewal price before you pay; our guide on how to read a renewal price helps here.
• A copy of every DNS record for the domain (A, AAAA, CNAME, MX, TXT and any others). Export or screenshot them. This is your backup.
• The free ICANN Lookup RDAP tool for registration data, and optionally a terminal with dig for DNS checks.
• Time: Cloudflare estimates "About 30 minutes" of active work and "Up to 10 days" in total. GoDaddy says "Transfers typically take 5-7 days to complete."
• Risk level: low for the registration, medium for website and email if DNS sits at the old registrar unplanned.

Your pre-transfer checklist, in order:

• The registrant email on the domain is one you can read today.
• You have not changed the registrant name, organization or email in the last 60 days.
• The domain was registered more than 60 days ago and was not transferred in the last 60 days.
• The domain is not expired or in redemption.
• You know where your DNS is hosted, and you have a copy of every record.
• DNSSEC is planned for (turned off first if your nameservers will change).
• The transfer lock is removed.
• You have the auth code.
• You know which inbox the confirmation emails will reach.

Step-by-step: move your domain without breaking anything

Step 1: Look up the domain's current status

Use ICANN Lookup to inspect the domain status and registrar using RDAP. RDAP replaced WHOIS; most gTLD providers no longer have to offer WHOIS. If a WHOIS service is available, this optional legacy command shows status lines:

whois example.com | grep -i "status"

You will see one or more lines like this:

Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited

What the common results mean, using ICANN's EPP status code page:

• clientTransferProhibited: the transfer lock is on. You remove it at your registrar in Step 5.
• serverTransferProhibited: the registry, not your registrar, is blocking transfers. ICANN says this "may indicate an issue with your domain that needs to be addressed promptly." Contact your registrar.
• pendingTransfer: a transfer is already in progress. If you did not start one, ICANN says to contact your registrar immediately.
• redemptionPeriod or clientHold: something is already wrong (deletion requested, or the domain held out of the DNS). Contact your registrar first.

Step 2: Check your contact details, but do not change them yet

The updated Transfer Policy identifies the Registered Name Holder as the transfer authority. Use the owner's registrar account or an authorized representative; do not rely on an old administrative-contact record.

Log in at your current registrar and check one thing: can you read email at the registrant email address today? Confirmation emails, and at some registrars the auth code, go there. GoDaddy, for example, says "We'll also send the auth code to the Registrant email address on the domain."

Heads up: this is where the 60-day trap lives. Under the Transfer Policy, a Change of Registrant is a material change to the registrant's name, organization or email address. After such a change, "The Registrar must impose a 60-day inter-registrar transfer lock." The registrar may let you opt out of that lock, but only before the change, and ICANN's FAQ is clear that "the registrar does not have to offer this option."

So, if the registrant email is old and you must fix it:

• Ask your registrar first whether it offers an opt-out of the 60-day lock.
• If it does, choose the opt-out before you save the new email.
• If it does not, accept that the transfer must wait 60 days, or keep the old email working until the transfer is done.

Why this matters: a typo fix is fine, because a material change is "a change which is not a typographical correction." A new email address is material, even if the person is the same.

Made-up example: Sana runs a small bakery site on example.com. On a Monday she changes the registrant email from an old address to a new one, and on Tuesday she pays a new registrar for the transfer. On Friday the transfer is rejected. The 60-day Change of Registrant lock started the day she saved the new email. Transferring first and changing the email later would have avoided it.

Step 3: Check the 60-day windows

There are three 60-day rules, and only one is mandatory.

• Change of Registrant lock (must deny): the old registrar must refuse the transfer within 60 days of a change to the registrant name, organization or email, unless you opted out before the change.
• New registration (may deny): ICANN's FAQ lists "Domain name is within 60 days of initial registration" as a reason a registrar may deny a transfer.
• Recent transfer (may deny): "Registrars also have the option of denying a transfer request within 60 days from when you last transferred the domain name."

Plan for all three anyway. Cloudflare, as a gaining registrar, lists the last two as conditions: "Your domain was registered at least 60 days ago and has not been transferred in the last 60 days."

Check creation and expiry dates in ICANN Lookup and transfer/contact-change dates in your registrar account history. If WHOIS is available, this optional command prints its date fields:

whois example.com | grep -iE "creation date|updated date|expir"

Quick tip: the "updated date" changes for many reasons, so your registrar's account history is the better record of a contact change.

Heads up on policy changes: An ICANN public comment summary dated 2 July 2025 shows the Transfer Policy Review recommendations, including 30-day windows and removing the Change of Registrant lock, went to the ICANN Board. At the time of writing (13 October 2026), ICANN's published Transfer Policy page still shows the 60-day rules described here, so check that page before you plan around a shorter window.

Step 4: Protect your DNS before anything moves

This step keeps your site and email online. Your site stays up only while your nameservers keep answering with the right records, so check who answers for your domain before anything moves.

First, find out who answers for your domain today. This command lists your domain's nameservers:

dig example.com NS +short

You will see something like this:

ns1.example-dns.net.
ns2.example-dns.net.

Now you have one of three situations:

• Your DNS is at your web host or a separate DNS provider (not the old registrar): good. Keep those nameservers in place and check with the dig commands below that they did not change.
• Your DNS is at the old registrar: ask the old registrar, in writing, whether its DNS service keeps working after the domain leaves. Do not assume. The safer path is to move DNS first: recreate every record at the provider you will keep, switch the nameservers, wait for the change to settle, then start the transfer.
• The new registrar requires its own DNS: some do. Cloudflare says "Cloudflare Registrar requires your domain to use Cloudflare for authoritative DNS (full setup)." In that case you set up DNS there and change nameservers before the transfer.

If your nameservers will change, deal with DNSSEC (a system that signs DNS answers so they cannot be faked) first. Cloudflare's instruction is: "If DNSSEC is enabled at your current registrar, disable it before you change nameservers." The reason is that old signatures "will no longer match, which causes DNS resolution failures." Cloudflare also says to "Wait at least 24 hours for the change to propagate before changing nameservers." Our DNSSEC and DS record guide explains how to turn it back on afterwards.

Step 5: Remove the transfer lock

ICANN requires registrars to "provide a readily accessible and reasonable means for name holders to remove the lock status." Look for an option labelled Transfer Lock or Domain Lock in your domain's settings; the exact label varies by registrar. Below are two verified examples.

At Cloudflare Registrar, per Cloudflare's transfer-out docs:

1. In the Cloudflare dashboard, go to the Manage Domains page.
2. Find the domain and select Manage.
3. Go to Configuration and choose Unlock.
4. Confirm with Confirm and Unlock.

At GoDaddy, the transfer-away help page lists three prep steps: "Unlock your domain", "Turn off Domain Privacy" and "Fully downgrade Domain Protection to none".

What you should see: the registrar dashboard confirms unlocking, and ICANN Lookup no longer shows clientTransferProhibited. A policy lock can remain even if that EPP code disappears.

Step 6: Get the auth code

Many registrars show the code right in the dashboard. If yours does not, ICANN's rule is: "Your registrar must provide you with the AuthInfo code within five (5) calendar days of your request."

At Cloudflare, the code appears after you remove the lock. Cloudflare calls it "auth code (also referred to as authentication code and authorization code)" and says the new registrar may call it EPP. If you lose it, select Regenerate.

At GoDaddy, the steps from the help page are:

1. Open your Domain Portfolio and select the domain.
2. Under Transfer, select Transfer to Another Registrar.
3. Review the checklist and select Continue with transfer. If prompted, verify your identity.
4. Optionally select Click here to see Authorization Code, then Copy to Clipboard. GoDaddy also emails the code to the registrant email.

Quick tip: paste the code into a plain text editor first, so a stray space or missing character is easy to spot.

Heads up: ICANN's pages do not set a validity period for auth codes. Cloudflare notes that "Authorization codes are usually only valid for a limited period." So get the code when you are ready to use it, not weeks ahead.

Step 7: Start the transfer at the new registrar

Now go to the gaining registrar, enter the domain and paste the auth code. At Cloudflare, you go to Transfer domains, select your domain and enter the code.

Pay only after Steps 1 to 6 are done, so a 60-day lock or a bad code shows up before your card is charged.

Good to know: ICANN's FAQ says registrars may set their own transfer fees, but "a transfer cannot be denied due to non-payment of this transfer fee."

Step 8: Approve the confirmation emails

Watch the registrant inbox closely for the next few days. There can be two emails:

• From the new registrar, if its flow asks for email approval. Follow that registrar's actual authorization process. ICANN currently defers enforcement of the gaining-registrar standardized FOA requirement, so two approval emails are not universal.
• From the old registrar, confirming or asking for approval. Cloudflare, as a gaining registrar, says your current registrar "will email you confirming the transfer or asking for your approval."

GoDaddy notes that approving the transfer can help speed it up. If you do nothing, the Transfer Policy says that when the old registrar does not respond within five calendar days, the transfer goes ahead by default.

Heads up: never approve a transfer email you did not expect. Contact your registrar instead.

Step 9: After the transfer, tidy up

When the new registrar shows the domain as active in your account:

• Turn the transfer lock back on at the new registrar. ICANN's EPP page says statuses like clientTransferProhibited can help prevent unauthorized transfers.
• If you turned off DNSSEC, turn it back on and add the new DS record. Cloudflare says "you can re-enable DNSSEC through Cloudflare with one click."
• Check the new expiry date and renewal price.
• Turn domain privacy back on if your new registrar offers it and you turned it off.

How to check it worked

Check the status and registrar

Check the registrar and status in ICANN Lookup and the new registrar account. If legacy WHOIS is available, you can also run:

whois example.com | grep -iE "registrar:|status"

During the move you may see pendingTransfer. When it is done, the registration data shows your new registrar, and after Step 9 you should see clientTransferProhibited again.

Check the nameservers did not change by surprise

This command asks for the nameservers again:

dig example.com NS +short

Expected result: the same nameservers you planned in Step 4.

Check your website still resolves

This command asks for your site's IPv4 address:

dig example.com A +short

Expected result: your host's IP address, for example 203.0.113.25. Then open the site in a private window.

Check mail routing

This command lists your mail servers:

dig example.com MX +short

Expected result: the same mail servers as before the move. Send a test email from an outside account.

Troubleshooting

The new registrar says the domain is locked

Likely cause: the domain still shows clientTransferProhibited. Fix: remove the lock at your current registrar (Step 5), wait a little, and confirm in the dashboard and ICANN Lookup before retrying. If the status is serverTransferProhibited, the block is at the registry, so contact your registrar.

The new registrar says the auth code is invalid

Likely cause: a copy and paste error, an old code, or a code from a different domain (codes are unique per domain). Fix: paste into a text editor to remove spaces, then request a fresh code. At Cloudflare, use Regenerate.

Transfer rejected after a contact change

Likely cause: the registrant name, organization or email changed in the last 60 days. ICANN says registrars must deny this transfer. Fix: wait until 60 days have passed. Next time, ask about the opt-out before changing contact details.

Transfer rejected because the domain is new or was recently moved

Likely cause: it is within 60 days of first registration or of the last transfer. These denials are allowed but not required. Fix: wait out the window, or ask the old registrar whether it will allow the transfer anyway.

No confirmation email arrives

Likely cause: the registrant email is old, filtered as spam, or hidden behind a privacy service. Fix: check spam folders, and check the registrant email at the old registrar. Changing the email can start the 60-day lock, so ask about the opt-out first.

The domain expired or is in redemption

Likely cause: the renewal lapsed. ICANN says registrars may not deny a transfer only because it expired, but if the domain is in the Redemption Grace Period, "the name must be restored by your current registrar before it can be transferred." Fix: restore or renew at the current registrar first. If you are moving to Cloudflare after a recent renewal, Cloudflare asks you to "wait at least 45 days after the original expiration date before transferring."

The old registrar will not give you the code

Likely cause: a slow support queue or a billing dispute. ICANN says the code must come within five calendar days, and the Transfer Policy says a registrar must not refuse it solely over a payment dispute. Fix: ask in writing and keep the date. If you believe a denial was wrong, ICANN's FAQ says you can file a formal Transfer Complaint with ICANN.

The site went down after the transfer

Likely cause: DNS was hosted at the old registrar and stopped, the nameservers changed, or DNSSEC signatures no longer match. Fix: run the dig checks above. Recreate your records from your Step 4 backup at the DNS provider you now use, check the nameservers point there, and remove or update the DS record.

When to ask for help

Ask your registrar, not a forum, when you see serverTransferProhibited, clientHold or redemptionPeriod. These usually need the registrar to act.

Ask your host or a developer before you change nameservers on a site that runs business email, because MX and TXT records are easy to miss.

The one message worth forwarding

Send this to whoever looks after your domain:

"Hi, we plan to move example.com to a new registrar. Before we pay, can you confirm: 1) the registrant email is one we can read now, and nobody changed the registrant name, organization or email in the last 60 days; 2) the domain was registered and last transferred more than 60 days ago; 3) where our DNS is hosted, with a copy of every record; 4) whether DNSSEC is on. Please do not change any contact details until we have talked, because that can start a 60-day transfer lock."

The takeaway: check the 60-day windows and your DNS before you pay, and the transfer itself becomes the easy part.