Web tower · floor

How long does it take to transfer a domain, and what stops the clock

The answer to how long does it take to transfer a domain is written down, in a policy anybody can read, and the deadlines in it are short. What turns a transfer into a wait of weeks is a different thing entirely: a lock, and usually one triggered before the transfer was even started.

Everything on this floor comes from ICANN’s Transfer Policy and its own guidance for registrants. Every ICANN-accredited registrar is bound by that policy, which makes it the thing to quote back when a support reply and the rulebook do not match — and it is public, with numbered clauses, so quoting it is easy.

It is worth being concrete about what that changes. Chasing the registrar you are leaving, and asking it to release the name, is asking for something these clauses do not require it to give. It is the gaining registrar that sets the transfer in motion with the registry, and the losing one holds a right to object inside a window rather than a power to consent. If it stays quiet, the move proceeds.

The policy does not publish a total, so what follows is arithmetic rather than a quotation: the two deadlines a registrant actually waits on are the one for getting the code and the lock removed, and the one at the registry. Five plus five. Where the registrar offers self-service for the first, only the second is left. What the quoted clauses do establish is narrower than a guarantee and still worth having: at the registry stage, not answering is not a way to stop a transfer.

What can stop it entirely is a different matter, and it is worth knowing the two lists. ICANN sets out circumstances where a registrar may deny a transfer — evidence of fraud, a reasonable dispute over who authorised it, money owed for a previous registration period, an express written objection from the holder, the name being in Lock status — and a separate list where it must deny, covering names subject to a UDRP, URS or TDRP proceeding, or a court order. There is also a procedural right attached: your registrar “is required to specify a reason when denying your transfer request unless they are required to deny it.”

The third is the one to read twice, because unlike the other two it has nothing to do with the age of the registration. It is triggered by an edit — and by one you might well make on the way to transferring.

On the code itself, the policy gives you two routes and a deadline. Registrars either “allow you to create your own AuthInfo code through their website or customer service team”, or must “provide the AuthInfo code within five calendar days of your request”. The same clause covers the transfer lock: where there is no self-service way to remove ClientTransferProhibited, the registrar has five calendar days to remove it after you ask. Both halves are obligations rather than favours.

One more thing that is easy to miss in the middle of a move, because it involves doing nothing rather than something. ICANN notes that if you do not respond to the authorisation form, “your transfer request will not be processed”. The five-day default that works in your favour at the registry does not apply to you: silence from the old registrar approves a transfer, and silence from you cancels one.

And the question worth asking before starting at all. ICANN puts it in its own FAQ: “You may have the option to change web-hosting providers instead of registrars to avoid the inter-registrar transfer process (and lock) altogether. You may also update your domain name’s nameservers.” If what you actually want is your site somewhere else, that is a different job from moving the registration — and it has no five-day clocks and no sixty-day locks attached to it.

And if it is refused without a reason you accept, there is a route. ICANN takes formal transfer complaints from registrants directly — which is worth knowing before spending a week arguing with a support queue.

The floors below take it three ways: the clocks and what runs when, the locks and which are discretionary, and the neighbouring decisions about where a domain should live at all.

What this tower will not do

It will not tell you a registrar can refuse indefinitely. Every stage of the policy has a deadline, and at the registry the default outcome of silence is that the transfer completes.

It will not recommend a registrar. That needs renewals watched across years, which is the point at which these companies are actually tested.

And it will not treat a registrar’s help page as the rule. The rule is ICANN’s Transfer Policy, quoted here by clause number so you can check it yourself. What holds instead is simple: the five-calendar-day deadlines and clause numbers, the default approval on silence, the circumstances in which a registrar may or must deny a transfer, the three sixty-day rules, the AuthInfo code obligations and the advice to transfer before changing contact details are quoted from ICANN’s Transfer Policy and its guidance for registrants, listed below.