How to Transfer a Domain: Auth Code and Transfer Lock

Transferring a domain means moving its registration from one registrar to another, and it succeeds when three things line up: the name is unlocked, the authorization code from the current registrar is entered correctly, and none of the sixty-day limits in ICANN's transfer policy applies. If you want to leave a registrar over price, support or a clumsy panel, you start the transfer at the new registrar and collect the code and lock status from the old one. Registrar screens differ, so this walkthrough covers who holds which piece of information and in what order to proceed rather than button names. Country-extension transfer rules are outside this topic.

What to have in hand before you start

The real work happens before the request. ICANN's Registrants' Benefits and Responsibilities (Opens in a new tab) page says registrants are entitled to information on transferring, renewing and restoring their registrations, so the first thing to read is your current registrar's transfer page. Then prepare the items in the table. Table: Preparation items for a transfer.

Practical suggestion: start the transfer on a weekday when you can answer email, not on a holiday weekend when a confirmation might sit unread.

Reading the exit terms

Ask the old registrar how it handles departures, and ask the new one what it charges and what it adds to your term. The policy says a completed holder-authorized transfer results in a one-year extension of the existing registration, with the total unexpired term capped at ten years. Whether the new registrar's fee covers that year is not stated in the documents, so read its price page.

The authorization code

The code proves to the new registrar that you control the name. RFC 5731 (Opens in a new tab), the EPP domain mapping, calls it authInfo. The document says this information is assigned when a domain is created and may be updated later, and that it is returned only to the sponsoring registrar or to a party that supplies valid authorization information. Sharing the code is therefore close to sharing control of the name.

The ICANN Transfer Policy (Opens in a new tab) page says that if a registrar does not give holders facilities to generate and manage their own authorization code and to remove the lock, it must provide the code and remove the lock within five calendar days of the holder's initial request. It also says a registrar must not refuse to release the code solely because of a payment dispute. Panels label the code differently, for example auth code, EPP code or transfer key. Those labels vary by registrar and by interface language.

Using the code well

1. Enter it only in the new registrar's transfer form.
2. Do not paste it into chat, email or a shared document.
3. If the panel lets you regenerate it, do so once the transfer finishes.
4. If the code is rejected, ask for a fresh one before cancelling anything.
5. How long a code stays valid depends on the registrar; the documents say nothing on it.

When the code does not arrive

Write to the registrar with the domain name, the account name, the date of your first request and the two things you want: the code and the lock removed. Mention the five-calendar-day rule, noting that it applies where the registrar offers no self-service tools. Keep the reply. If nothing comes, use the complaint route in the registrar's agreement; ICANN's page says you are entitled to know how to raise concerns with your registrar.

The registrar lock

RFC 5731 says that when a domain carries the clientTransferProhibited status, requests to transfer it must be rejected. With the lock on, a move cannot start. Under section I.A.5.1 of the ICANN policy, a registrar may set that status only at registration or on later request, and the registration agreement must contain the terms of the prohibition with the holder's express consent. The page also says the lock is not a valid reason to deny a transfer unless the holder had a reasonable opportunity to unlock the name before the request.

In practice, you should be able to unlock the name yourself or by asking support, and the five calendar days run from your request. Once unlocked, start the request at the new registrar. When the move finishes, confirm in the new panel that the lock is on again.

Keeping the unlocked window short

Practical suggestion: remove the lock just before you start the transfer and restore it once the transfer completes. While unlocked, the name is exposed to an unwanted move, so do the three steps of generating the code, unlocking and requesting the transfer on the same day.

The sixty-day rules

ICANN's policy contains three different sixty-day limits. It allows a registrar to deny a transfer requested within sixty days of the name's creation, and likewise within sixty days after a prior transfer. The third is separate: a sixty-day inter-registrar transfer lock that follows a change of registrant. Table: The three limits.

Change the registrant before or after the move

For a change of registrant, the policy requires the registrar to obtain confirmation from both the prior and the new registrant through a secure mechanism, to notify both, and to process the change within one day of the confirmations. The registrar may let the holder opt out of the sixty-day lock, but only before the change request. The policy also advises the prior registrant to request an inter-registrar transfer before the change so the lock is not triggered. If you want both a new registrar and a new registrant, do the transfer first and update the registrant afterwards, after checking how both registrars handle it.

When a transfer can be denied

Section I.A.3.7 limits the reasons a registrar may give. The permitted reasons are listed here.

• Evidence of fraud.
• A reasonable dispute over the identity of the holder or administrative contact.
• Non-payment for the previous registration period, with listed exceptions.
• An express objection from the authorized transfer contact.
• A request within sixty days of the name's creation.
• A request within sixty days after a prior transfer.

Other rules require denial during UDRP or URS proceedings, court orders, TDRP disputes and the lock after a registrant change. The policy also says registrars must not use transfer processes as a way to secure payment for services from a holder. Table: Reading a denial.

If a reason is not on the list, ask the registrar which provision it relies on.

The clock after you ask

The policy sets timings for the process. Table: Time limits in the ICANN policy.

The policy says the form is to be communicated in English, and registrars may add other languages and are responsible for the accuracy of translations, so an English email is expected. The page states that an updated version was published on 21 February 2024, so check the current text before relying on any figure.

While you wait

Do not change account details, touch name servers or start a second change during the waiting window. If the confirmation mail does not arrive, look in spam and then write to the registrar.

If the approval mail never arrives

The approval mail goes to the address on file. If it is missing, check spam, check that the address on file is current, and check domain-level filters. Changing that address mid-process could count as a registrant change because the policy lists the email address among the material details, so ask the registrar before touching it.

Cost and the added year

Judge a transfer by total cost, not the headline price. RFC 5731 lets a transfer request carry an optional period, which is added to the registration period when the transfer completes, and it says the server may limit the number of units. Table: Questions that settle the cost.

Practical suggestion: put both registrars' three-year totals in one table before deciding.

DNS and email during the move

RFC 5731 states that transferring a domain object implicitly transfers all host objects subordinate to it. It does not say how delegated name server references are handled in a transfer. Ask both registrars in writing what happens to your name servers, export the record list before the move, and compare it afterward.

Google's Site moves without URL changes (Opens in a new tab) page says ISPs cache DNS settings according to the TTL and suggests lowering it to a few hours at least a week before a move. If name servers will change, apply that advice. If hosting changes too, handle it as its own project using the steps in changing web hosts: DNS cutover checklist. Google's guidance can change, so check the current page.

Table: name servers staying or moving

One change at a time

Practical suggestion: do not schedule the registrar transfer, a hosting change and an email provider change on the same day. When something breaks you will not know which change caused it. Finish the transfer, watch for a few days, then move to the next change.

Search Console after the move

If your domain property was verified with a DNS record, confirm that the record is still present after the transfer, especially if the name servers changed. The difference between property types is covered in Search Console domain versus URL-prefix property. A deleted verification record can break ownership checks.

Protecting the account while the lock is off

For the days of a transfer the name is more exposed, because the lock is off and a code exists. Practical suggestions follow.

• Switch on two-step verification for the registrar account.
• Protect the account's email with a strong, unique password, since approvals go there.
• Store the code in a password manager and retire it once the move is done.
• Check screenshots for codes, payment data and session details before sharing.
• If an approval request arrives for a transfer you did not start, do not approve it, forward it to your registrar and check the lock at once.

Decision rule: move or stay

Not every problem is solved by transferring. Table: Reason and suggested move.

Plan B if the transfer stalls

If a transfer is denied or sits for days, the name stays registered at the current registrar. If the expiry date is close, ask the current registrar in writing how a renewal affects a pending transfer, and do not neglect the expiry. Then clear the reason for denial and restart. Practical suggestion: start a transfer when at least a month remains before expiry, so a delay does not push you into a renewal squeeze.

Example scenario: a shoe repair shop

Example scenario: A shoe repair shop takes appointment requests through its own site. The domain was registered through a web designer's suggestion, and the owner now wants a registrar with a steadier panel. She opens the old panel, sees the name is locked and cannot find the code. She writes to support and notes the date of the request.

She then exports the DNS records and checks the expiry date, which is several months away. She unlocks the name, takes the code and requests the transfer at the new registrar on the same day. She waits for the approval email, checks spam, and confirms. Afterward she tests the appointment form, her email and the verification record, compares the records with her export, and checks that the lock is back on.

In a second version of the story, the old registrar tells her the name changed registrant details recently and a sixty-day lock applies. She waits, writes the end date in her calendar and restarts the transfer when it passes. Waiting costs nothing, but she must deal with renewal separately if expiry is near.

What the story shows

Preparation turns a transfer into a routine task. What slows things down here is not a technical obstacle but not knowing where the code is and not reading the approval email.

Practical suggestion: after the move, the owner adds one page to her notes: registrar name, support address, expiry date, where the DNS export lives and who else can log in. The next time she needs to change registrar, she starts from that page rather than from memory, and anyone covering for her during a holiday can act on it.

Many names and client names

With several names, or names you manage for clients, each has its own code, lock status and expiry. Keep one table: name, old and new registrar, lock status and date, sixty-day dates, request date and outcome. When the name belongs to a client, the code and approval mail belong to the client's address. Get written authority, have the client manage the code request, and check after the transfer that the registrant record shows the client's name. If a registrant change is needed, plan the sixty-day lock before the move.

Checklist after the transfer

• The new registrar's panel shows the name as active and the expiry date moved as expected.
• The transfer lock is on again.
• The home page, an inner page and the booking or contact form load from another network.
• Email works in both directions.
• DNS records match the exported list.
• The Search Console verification record and other TXT records are in place.
• Automatic renewal is on and the payment method is valid.
• The contact email is read by two people.
• If the old registrar also provided email or hosting, that use was checked before closing the account.
• Your notes show the new registrar, expiry date and responsible person.

Before closing the old account

If the old account still holds other names, mail or hosting, closing it can cause trouble. Save invoices, notice addresses and DNS exports first.

Questions to put in writing

1. Is my name locked, and how do I remove the lock?
2. Can I generate the authorization code myself? If not, will you provide it within five calendar days?
3. Was my name created, transferred or its registrant changed in the last sixty days?
4. Is any invoice or period unpaid?
5. What happens to my name servers when the transfer completes?
6. Does a successful transfer add a year, and what is the fee?

Keep the export file, the support replies and the dates of each step in one folder. If the new registrar or the old one later disputes what happened, a dated trail answers the question faster than memory does. It also helps whoever takes over the account, because the folder shows which steps were done, in what order, and where the evidence sits. Add the renewal date and the name of the person who approves payment, and the folder doubles as a handover note.

Frequently Asked Questions

How long does a domain transfer take?

The ICANN policy gives the current registrar five calendar days to respond, and no response counts as approval. Actual timing depends on the registrars and the extension, so read the current policy text and your registrar's description.

Can a registrar refuse the code over a payment dispute?

ICANN's policy says the registrar of record must not refuse to release the code solely because of a payment dispute. If the code does not arrive, make the request in writing and cite the relevant provision.

What does the transfer lock do?

Under RFC 5731, transfer requests for a name carrying clientTransferProhibited must be rejected. The lock blocks unwanted moves, so keeping it on when you are not transferring is sensible.

Can I move a domain I just registered?

The ICANN policy lets a registrar deny a transfer requested within sixty days of the name's creation, so wait out that period first.

What happens to my site and email during the transfer?

RFC 5731 says subordinate host objects transfer with the domain but does not say how delegated name server references are treated. Export your record list first and compare it after the transfer.

Does changing the registrant lock the name?

Under the ICANN policy a sixty-day lock follows a change of registrant, though the registrar may let the holder opt out of it before the change request. Ask your registrar how it handles this.

Conclusion

A domain transfer comes down to three stages in order: preparation, the code and the lock, then verification after the move. The sixty-day limits, the reasons for denial and the five-day windows are written in the ICANN policy, while the panel steps differ between registrars. Exporting the record list, tying the approval email to an address you read and keeping the transfer separate from a hosting change are the three lowest-cost safeguards. On a stalled or delayed transfer, get the reason in writing, note the relevant time limit and keep an eye on your expiry date. Treat the code and the lock as sensitive: keep them out of screenshots and shared documents, confirm the lock is back on when the move ends and leave automatic renewal on at the new registrar. Extension rules can differ, so read the documents for your own extension too.

After the move is done, our guest post service is one way to get your site introduced in context.