How long does a domain transfer take?

Before you start

Three things have to be in place before your new registrar can request the transfer. The rules below come from ICANN’s Transfer Policy, which covers generic domains such as .com, .net and .org. Country-code domains such as .uk or .de follow their own registry’s process.

Unlock the domain

Registrars often lock domains against transfers. A WHOIS or RDAP lookup shows the lock as clientTransferProhibited (in RDAP, client transfer prohibited), and while it’s on, the transfer can’t go through. Turn it off in your registrar’s dashboard. If the registrar offers no way to do that yourself, it must remove the lock “within five (5) calendar days” of your request (Transfer Policy, section 5.2).

A serverTransferProhibited status is a lock set by the registry, which only your registrar can ask the registry to lift. Domain status codes explains each lock.

Get the auth code (EPP code)

The auth code is a password for the domain. Registrars also call it the EPP code, AuthInfo code or transfer code. In EPP, the protocol registrars use to talk to the registry, the new registrar sends it with the transfer request (RFC 5731, section 3.2.4), which shows the request comes from the domain’s holder. In the words of ICANN’s registrant FAQ, it “is required for a domain holder to transfer a domain name from one registrar to another.”

Copy it from your registrar’s dashboard, or ask for it: your registrar “must provide you with the AuthInfo code within five (5) calendar days of your request.” Treat it like a password, and give it only to the new registrar.

Check the 60-day rules

Your current registrar may refuse a transfer (Transfer Policy, section 3.7):

• within 60 days of the domain’s creation date, and
• within 60 days of its last transfer to another registrar.

For .com, the registry enforces the first rule itself: transfers “may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration” (.com registry agreement, Appendix 7, section 3.1.1).

There is a third lock. After a change of registrant, meaning a new owner name, organization or email address, you can’t transfer the domain for 60 days unless your registrar let you opt out beforehand. ICANN’s FAQ advises: “If your ultimate goal is to transfer the domain name, you may want to consider completing the transfer process before changing your contact information.”

If the domain has already expired, the old registrar may also refuse until the expired period is paid for (section 3.7.3).

The timeline for a .com

The 5 days are the registry’s Transfer Pending Period. Appendix 7 (section 3.3.1) says “the current value of the Transfer Pending Period is five calendar days for all Registrars”, and if the current registrar “does not explicitly approve or reject the request”, the registry “will approve the request automatically after the end of the Transfer Pending Period.” The Transfer Policy says the same from the registrar’s side (section 3.5). An early approval finalizes the transfer at once, which is why some transfers finish the same day.

While it waits, lookups show the status pendingTransfer. If you see it on a domain you didn’t ask to move, contact your registrar right away and ask it to refuse the transfer.

The transfer adds a year

A transfer renews the registration. For .com, “the term of registration of the Registered Name shall be extended by one year, provided that the maximum term of the registration as of the effective date of sponsorship change shall not exceed ten years” (Appendix 7, section 2.3). The registry charges the new registrar for that year.

Two cases work differently:

• A registration already near the 10-year maximum gains less than a year, or none.
• Just after expiry, in the registry’s 45-day Auto-Renew Grace Period, the year the registry added automatically is cancelled and the transfer’s year replaces it, so you don’t gain two (section 3.1.3).

Compare the expiry date before and after. Your new registrar’s dashboard should show the year added.

Your website and email during the transfer

A transfer changes which registrar sponsors the domain. It doesn’t change the domain’s nameservers, so DNS, the website and email carry on as before.

The exception is DNS hosted by the old registrar itself. If your nameservers belong to the old registrar, ask it how long it keeps serving your records after the domain leaves, or move your DNS first. Email stopped after changing nameservers covers what to copy before that move.

What can stop a transfer

The old registrar may refuse only for the reasons in section 3.7 of the Transfer Policy, and it must tell you and the new registrar why:

• evidence of fraud
• a reasonable dispute over who the domain holder is
• unpaid fees for a past or current registration period
• your own express objection, such as a lock you asked for
• the 60-day periods above

It must refuse during a UDRP or URS dispute you’ve been told about, under a court order, during a dispute over an earlier transfer, or during the 60-day lock after a change of registrant (section 3.8). It may not refuse over payment for a future period, or because you didn’t answer its email (section 3.9).

If the new registrar says the transfer failed, check the two things the request depends on first: the lock is off, and the auth code is current and copied exactly.

Check the lock and dates yourself

RDAP, the replacement for WHOIS, returns a domain’s statuses and dates as JSON. This shows the transfer lock and the dates the 60-day rules count from:

curl -sL https://rdap.org/domain/example.com \
  | jq '.status, [.events[]
      | select(.eventAction | IN("registration", "transfer"))
      | .eventAction + " " + .eventDate]'

[
  "client delete prohibited",
  "client transfer prohibited",
  "client update prohibited"
]
[
  "registration 1995-08-14T04:00:00Z"
]

Captured on October 24, 2026 with curl 8.7.1 and jq 1.7.1. client transfer prohibited is the lock, still on. A transfer event, when a domain has one, is “the object instance was transferred from one registrar to another” (RFC 9083, section 10.2.3); example.com shows none. RDAP vs WHOIS explains the rest of the response.

Rules that are changing

On June 7, 2026, ICANN’s Board adopted the 47 recommendations of a review of the Transfer Policy (resolution 2026.06.07.04) and directed ICANN to implement them. They don’t apply yet: the new policy text still has to be written, and as of October 24, 2026 ICANN hasn’t published it or a date it takes effect. Among the changes in the working group’s Final Report of February 4, 2025:

• Shorter restrictions. The 60 days after registration and after a transfer become 720 hours (30 days) for every generic domain (recommendations 3 and 18).
• A new name and an expiry for the auth code. It becomes the Transfer Authorization Code (TAC), valid for 336 hours (14 days) once set (recommendations 4 and 9).
• The same 5 days, in hours. The old registrar’s time to answer is written as 120 hours (recommendation 17).

Until the new policy takes effect, the 60-day and 5-day rules above are the ones that apply.

Sources

All sources were checked on October 24, 2026. The command output comes from our own run on that date.

• Transfer Policy, ICANN, as updated on February 21, 2024: sections 3.4–3.9 (the old registrar’s duties and the reasons it may or must refuse) and 5.2 (locks and auth codes).
• FAQs for Domain Name Registrants, ICANN: the auth code, the 60-day locks and the five days to receive a code.
• .com Registry Agreement, Appendix 7, ICANN and Verisign, December 1, 2012: sections 2.3 (a year added, up to ten), 3.1.1 (no transfers in the first 60 days), 3.1.3 (Auto-Renew Grace Period) and 3.3.1 (the five-day Transfer Pending Period).
• RFC 5731: EPP Domain Name Mapping, IETF, section 3.2.4: the transfer command and its authorization information.
• RFC 9083: JSON Responses for RDAP, IETF, June 2021, section 10.2.3: the transfer event.
• Approved Resolutions, Regular Meeting of the ICANN Board, June 7, 2026: resolution 2026.06.07.04 adopting the Transfer Policy Review recommendations.
• Transfer Policy Review PDP Working Group Final Report, ICANN GNSO, February 4, 2025: recommendations 3, 4, 9, 17 and 18.