In this article
After the payment settles, a domain name changes hands the same day when it is pushed between two accounts at the same registrar, and within about a week when it is transferred from one registrar to another. The difference is not the seller's speed. It is that the second route runs through a waiting window written into the rules for generic extensions, and that window can only be shortened, never skipped, by the seller's own registrar.
Those two durations are the normal case. The slow cases are almost always caused by something that existed before the payment: a name registered or moved a few weeks earlier, a lock nobody removed, an authorization code that expired, a confirmation email going to an inbox nobody reads. Every one of them can be found in ten minutes before the money moves, which is why the question "how long will the transfer take" is best answered before the payment, not after it.
This article covers generic extensions such as .com, .net and .org, which follow the Transfer Policy published by ICANN, the body that coordinates them. Country-code extensions set their own rules, and each registrar adds its own practice on top; where that matters, it is said.
Figures from ICANN's Transfer Policy for generic extensions, as published by ICANN. Country-code extensions follow other rules.
What are the two ways a domain name changes hands?
A domain name changes hands either by an internal push, which moves it from the seller's account to the buyer's account at the same registrar, or by a registrar-to-registrar transfer, which moves it to a different registrar chosen by the buyer. The first is an account operation inside one company. The second is a regulated procedure between two companies and the registry that runs the extension.
A registrar is the company where the name is registered and renewed. The registry is the operator of the extension itself, the one database that says which registrar currently sponsors each name. In a push, the registry sees no change of registrar: the name stays where it is and only the customer account, and usually the registrant details, change. In a registrar-to-registrar transfer, the buyer's registrar (called the gaining registrar) asks the registry to move the name away from the seller's registrar (the registrar of record, often called the losing registrar), and the registry applies the steps of the Transfer Policy before it does so.
| Criterion | Internal push | Registrar-to-registrar transfer |
|---|---|---|
| What moves | The name, from one account to another at one registrar | The name, from one registrar to another |
| What the buyer needs | An account at the seller's registrar | An account at any registrar, plus the authorization code |
| Typical duration | Minutes to one day | Up to 5 calendar days after the request, less if approved early |
| Waiting window set by policy | None for the push itself | Default approval after 5 calendar days |
| Cost to the buyer | Usually none | Usually one year of renewal at the new registrar |
| What can follow | A 60-day lock on leaving the registrar, unless waived beforehand | A 60-day window before the next transfer |
The durations in the "typical" row for a push describe common registrar practice, not a rule: each registrar designs its own account-change process, and some add a manual review for valuable names. The durations for a transfer come from ICANN's policy and are upper limits.
How long does an internal push take, step by step?
An internal push usually completes within minutes to one day after the seller starts it, because every step happens inside one registrar and no outside party has to answer. The only real delays are the buyer not yet having an account there, and any review the registrar applies to account changes.
Registrars name the function differently: push, account change, change of ownership, move to another account. The mechanics are similar everywhere.
- Before payment: the buyer opens an accountThe buyer creates an account at the seller's registrar and gives the seller the identifier the registrar asks for, usually an account number, a username or the account's email address. Ten minutes, done before the money moves.
- Day 0: the payment settlesThe seller confirms the funds are final, not merely announced or pending, before touching the name.
- Day 0: the seller starts the pushIn the registrar's control panel, the seller selects the name and enters the buyer's account identifier. A few minutes. Some registrars send the seller a confirmation email or a second-factor prompt first.
- Day 0: the buyer acceptsMany registrars place the name in the buyer's account at once; others ask the buyer to accept it, by email or in the account. Minutes if the buyer is watching, up to a day if not.
- Day 0 or 1: the buyer takes controlThe buyer checks that the name is listed in the account, updates the registrant contact details, sets the name servers and turns on the registrar lock. This is the moment the name has changed hands.
One consequence of a push catches buyers who planned to move the name elsewhere afterwards. A push normally changes the registrant's name, organization or email address, and ICANN's Transfer Policy treats such a change as a Change of Registrant, covered in a dedicated section below.
How long does a registrar-to-registrar transfer take, step by step?
A registrar-to-registrar transfer of a generic extension completes at most five calendar days after the gaining registrar submits the request, provided the name is unlocked and the authorization code is valid. It completes sooner, often within hours, when the seller's registrar lets the seller approve the pending transfer instead of waiting for the window to run out.
Two things happen before that clock starts: the seller removes the transfer lock and obtains the authorization code. ICANN's Transfer Policy gives a registrar that does not offer self-service tools for these two actions five calendar days from the holder's request to do them. Most large registrars provide both in the control panel, so this stage usually takes minutes, but the policy allows it to take days.
- Day 0: the payment settlesThe seller confirms the funds are final.
- Day 0: the seller unlocks the name and requests the codeThe seller turns off the registrar lock and asks for the authorization code. Minutes with self-service tools; up to 5 calendar days at a registrar without them.
- Day 0: the seller sends the code to the buyerThe code goes through a channel both sides agreed on beforehand. It works like a password for the name: whoever holds it can start a transfer.
- Day 0: the buyer submits the transferAt the gaining registrar, the buyer enters the name and the code and pays the transfer fee. The registry checks the code and marks the transfer as pending.
- Within 24 hours: the seller's registrar asks for confirmationThe registrar of record must send its confirmation notice to the registered name holder no later than 24 hours after the registry's request. The notice lets the holder approve or object.
- Day 0 to Day 5: approvalIf the seller approves, at registrars that offer the option, the transfer completes at once. If nobody responds and the registrar of record does not deny the request, it is approved by default after 5 calendar days.
- Completion: the buyer takes controlThe name appears in the buyer's account at the gaining registrar. The buyer checks the registrant details, sets the name servers and turns the lock back on.
The policy also describes an authorization form that the gaining registrar obtains from the holder before submitting the request. ICANN's published policy carries a note that its compliance department defers enforcement of that requirement, so in practice the authorization code is what authorizes the request on the gaining side, and the confirmation notice from the seller's registrar is the remaining safeguard.
The five days are calendar days. A request submitted on a Monday is approved by default on the Saturday, weekend included. What does follow office hours is everything human: a seller who must telephone the registrar to release a lock, or a registrar whose support desk processes code requests by hand.
What are the authorization code and the transfer lock?
The authorization code is a secret string attached to one domain name that the gaining registrar must present to the registry to start a transfer, and the transfer lock is a status on the name that makes the registry refuse any transfer request until it is removed. A registrar-to-registrar transfer needs the lock off and a valid code; a push needs neither.
The code has several names for the same thing: authorization code, auth code, AuthInfo code, EPP code, transfer key, and now transfer authorization code. ICANN's Transfer Policy uses "AuthInfo" and requires registrars to provide it to the registered name holder. It is specific to one name. Anyone who has it and submits it while the name is unlocked can open a transfer, which is why it is sent only after the payment is final, only to the buyer, and never pasted into a shared document or a group conversation.
The lock exists at up to three levels, and they are not removed by the same party.
- The registrar lock is the ordinary one. Its technical name is the status "clientTransferProhibited". The holder switches it on and off in the control panel, and registrars turn it on by default. Under ICANN's policy a registrar must remove it within five calendar days of the holder's request when it offers no self-service switch.
- The registry lock is a premium service some registries and registrars sell for high-value names. It is set at the registry and released through a manual, verified procedure, typically a call or a signed request. Releasing it takes as long as that procedure takes, and a seller who has one should start before the payment date.
- Policy locks are applied by rule rather than by choice: the windows that follow a registration, a transfer or a change of registrant.
The public registration record shows the status codes of any name. A buyer who looks the name up before paying sees whether a transfer prohibition is in place and can ask the seller which kind it is.
Which waiting windows does ICANN's Transfer Policy set?
ICANN's Transfer Policy, as published for generic extensions, sets a five-calendar-day window after which a pending transfer is approved by default, allows a registrar to refuse a transfer requested within 60 days of the name's creation or within 60 days of a previous transfer, and requires a 60-day lock on transfers to another registrar after a Change of Registrant unless the holder opted out beforehand. Those are the numbers in force in the policy text ICANN publishes, which registrars have had to follow since 1 December 2016 and which was last updated on 21 February 2024.
The wording of each window matters, because the three do not bind in the same way.
The five-day window is a ceiling. The policy says that failure by the registrar of record to respond within five calendar days results in default approval. Nothing in it forces a registrar to use all five days, and many let the holder approve the pending request early.
The 60 days after creation and the 60 days after a previous transfer are grounds on which the registrar of record may deny a request. In the policy text they are permissions, not obligations. In practice a seller should treat them as firm: registrars commonly apply them without exception, and some registries enforce the post-registration period themselves.
The 60 days after a Change of Registrant are mandatory unless waived. The registrar must impose the lock, and may let the holder opt out of it before the change is requested. Whether the opt-out exists, and how it is offered, depends on the registrar.
The policy also lists reasons for which a registrar must refuse a transfer whatever the parties want: a pending dispute proceeding over the name that the registrar has been told about, a court order, or a pending dispute between registrars over an earlier transfer. And it lists reasons a registrar may not use: nonpayment for a future registration period, or the holder's failure to answer an email.
The policy has been under revision. ICANN's Transfer Policy Review, whose initial report was published in 2024, recommended shortening the post-registration and post-transfer windows to 30 days, removing the lock that follows a change of registrant, and issuing the transfer authorization code only on request with a validity of 14 days. Those recommendations are not what the policy text published by ICANN says. Until a revised policy takes effect, plan on the numbers above, and ask the seller's registrar what it applies, since registrars implement changes on their own schedule within the deadlines they are given.
Country-code extensions sit outside this policy. Each one is run under its own rules: some have no code and use a registry-side change of holder, some charge the registry a fee for a change of ownership, some require the new holder to meet a residence condition, and some complete a transfer the moment the code is entered. For a name under a country-code extension, the only reliable source is the registry of that extension and the two registrars involved.
Why can a push lock the name at the seller's registrar for 60 days?
A push can lock the name at the seller's registrar for 60 days because changing the registrant's name, organization or email address is a Change of Registrant under ICANN's Transfer Policy, and the registrar must then block transfers to another registrar for 60 days unless the holder opted out before the change. The push itself is fast; what it can cost is the freedom to move the name afterwards.
For a buyer who is content to keep the name where it is, the lock changes nothing: the name is in the buyer's account, under the buyer's control, with the buyer's name servers. For a buyer whose company holds all its names at one corporate registrar, it is the whole question. Two orders of operations are possible, and they do not take the same time.
The first is push, then transfer. The buyer has control on Day 0, then waits out the lock before consolidating. In the worst case the name leaves the seller's registrar on Day 60 at the earliest and, with default approval, lands at the corporate registrar on Day 65.
The second is a direct transfer to the buyer's registrar, with the registrant details updated there. The buyer has control within about five days, at the registrar of its choice. The update of the registrant details at the gaining registrar may itself count as a change of registrant and start a lock there, which rarely matters, since the name is already where the buyer wants it.
What can stall a domain transfer?
A domain transfer stalls for one of a small number of reasons: the lock is still on, the code is wrong or expired, a confirmation goes to an address nobody reads, the name is inside a policy window, or the registrar has placed a hold on the name or the account. All but the last can be checked from the seller's control panel before the payment.
| What stalls it | What happens | How to clear it |
|---|---|---|
| Registrar lock still on | The registry rejects the request at once | The seller switches the lock off, then the buyer resubmits |
| Wrong or expired code | The registry rejects the request | The seller requests a fresh code and sends it again |
| Confirmation sent to a dead address | Nobody can approve early; the full window runs | The seller updates the contact email before the sale, not during it |
| Recent registration or transfer | The seller's registrar denies the request | Wait for the 60-day window to end, or use a push |
| Recent change of registrant | The registrar must deny the request | Wait out the lock, or opt out before the change where offered |
| Registrar or registry hold | The name cannot move until the hold is lifted | The seller resolves the cause with the registrar: unpaid renewal, verification, dispute |
A few of these deserve more than a table cell.
Updating the contact email is the fix that backfires. A seller who discovers an old address on the registration record and corrects it the day before the sale may trigger a Change of Registrant, and with it the 60-day lock, at registrars where no opt-out was set. The correction belongs weeks earlier, or the route should be a push.
A privacy or proxy service replaces the holder's contact details in the public record with those of the service. On generic extensions the authorization code now carries most of the weight, so privacy rarely blocks a transfer outright, but some registrars ask for it to be switched off before releasing a name, and notices sent to a forwarding address can be filtered or delayed. Ask the seller's registrar what it requires rather than assume.
Expiry complicates everything. A name close to its expiry date can usually still be transferred, but a name that has expired and entered its grace or redemption stages may need to be renewed or restored by the seller first, at the seller's registrar's price, and rules on whether the renewal year carries over differ by registry. Renewing before the sale removes the question.
Registrar holds come from the registrar's own controls: an unpaid invoice, an unverified contact address, a payment on the account being reviewed, or a security freeze after a password reset or a change of login email. Some registrars block outgoing transfers for a period after such account changes. A seller preparing a sale should avoid changing account credentials in the days before it.
Finally, the seller can object. During the pending window, the holder can refuse the transfer through the confirmation notice. That safeguard exists to stop transfers nobody authorized, and it is why a buyer has not received the name until the registry shows the gaining registrar as sponsor.
What does a sale look like from payment day to completed transfer?
A worked example shows the spread: on the same sale, the name reaches the buyer the same day by push, on Day 1 by a transfer the seller approves, on Day 5 by default approval, and as late as Day 25 when a policy window is still running. The figures below are illustrative; the durations in days are the limits set by ICANN's policy for generic extensions.
The assumptions: a two-word .com name sells for $25,000, with a broker on a 10% commission, so $2,500 to the broker and $22,500 to the seller. The payment settles and is confirmed final on a Monday morning, which is Day 0. The name was registered years ago and has not moved, unless stated.
Route one, the push. The buyer opened an account at the seller's registrar the week before. On Monday the seller enters the buyer's account identifier, confirms by email, and the buyer accepts within the hour. By Monday afternoon the buyer has set the name servers and turned the lock on. Elapsed time: a few hours. The buyer accepts that the name may be locked at this registrar for the next 60 days.
Route two, the transfer with early approval. On Monday the seller switches off the lock, copies the code from the control panel and sends it to the buyer. The buyer submits the transfer at the gaining registrar before noon. The confirmation notice from the seller's registrar must go out within 24 hours, so by Tuesday morning at the latest. The seller approves it, and the registry moves the name. Completion: Day 1 at the latest, often Day 0.
Route two, default approval. Same steps, but the seller's registrar offers no early approval, or the notice lands in a mailbox the seller does not check. The request waits out its five calendar days and completes on Saturday, Day 5.
Route two at a slow registrar. The seller's registrar has no self-service code and takes the full five calendar days the policy allows to provide it: the code arrives on Saturday, Day 5, the buyer submits the same day, and default approval follows on Thursday of the next week, Day 10.
Route two inside a window. Suppose instead the seller had registered the name 40 days before the payment. The registrar may deny any transfer until Day 20, when the 60 days are complete. Submitted that day and approved by default, the transfer completes on Day 25. On this sale the push is the only route that hands the name over in the week of the payment.
Illustrative scenarios built on the limits in ICANN's Transfer Policy for generic extensions: 5 calendar days to provide the code, 5 calendar days to default approval, 60 days after registration. Registrar practice can be faster.
The chart makes one point a sentence hides: almost none of the spread comes from what the parties do after the payment. Four days of it come from whether early approval exists, five from how the registrar releases codes, and twenty from a registration date that was fixed weeks before anyone agreed a price.
What should both sides check before the payment?
Before the payment, both sides should agree the route, confirm that the name is free to move on that route, and fix the channel and the moment at which the code or the push will be sent. Each of those checks takes minutes, and each removes days of uncertainty after the money has moved.
The seller checks, in the control panel and with the registrar where needed:
- the creation date and the date of the last registrar transfer, against the 60-day windows;
- whether the registrant details were changed in the last 60 days, and whether an opt-out from the resulting lock is on record;
- which locks are on the name, and how long a registry lock, if any, takes to release;
- that the contact email on the registration record is one the seller reads, without changing it at the last minute;
- that the expiry date is comfortably after the planned handover, and that no invoice or verification request is outstanding on the account;
- whether the registrar offers a self-service code and early approval of a pending transfer.
The buyer checks:
- the public registration record of the name: sponsoring registrar, creation and expiry dates, status codes;
- that the person selling controls the registrar account, for instance by asking the seller to make an agreed, harmless change visible in the public record, such as adding and removing a text record in the name's zone;
- which route suits what happens next, the push if speed matters most, the transfer if the name must sit at a particular registrar;
- that the account receiving the name exists, is verified, and is protected by two-factor authentication;
- for a country-code extension, the registry's own rules on eligibility, change of holder and fees.
Both sides, and the broker if there is one, then write down the sequence in plain words: which payment event counts as settled, who confirms it, how many hours the seller has to start the push or send the code after that confirmation, how many days the buyer has to submit the transfer, and what each side does if the registrar denies the request. A written sequence also settles in advance the point that otherwise causes friction during the five-day window, namely whether the seller is expected to approve the pending transfer early.
The handover has its own short checklist. For a transfer, the buyer confirms in the public record that the sponsoring registrar has changed, not merely that a request is pending. For either route, the buyer confirms the registrant details and name servers, turns the lock on, and tells the seller in writing that the name has been received, which is the document the seller keeps.
Where a broker's commission comes out of the price, the payment side can be settled in the same spirit of agreeing everything first. Shaka is a payment router: each party's share, here the seller's $22,500 and the broker's $2,500, is agreed and can be signed by each recipient before the buyer pays, the buyer pays once, and every party is paid at the same moment by a payment that is final. It routes the payment and never holds the funds, and it has no part in moving the name, which still follows the registrar steps described above.
How does the transfer of an onchain name differ?
An onchain name is transferred by a blockchain transaction signed by its current owner, so the transfer is complete as soon as that transaction is confirmed, typically within minutes. There is no registrar account, no authorization code, no confirmation notice and no five-day window, because the record of who owns the name is the blockchain itself.
The speed changes what both sides must check, rather than removing the need to check.
The destination is an address, not an account. The seller sends the name to the wallet address the buyer supplied, and a name sent to a wrong address cannot be recalled by a support desk. The buyer confirms the address through a second channel, and on a large sale the two sides can test the channel with a small transaction first.
There is no objection period. On a generic extension the pending window gives a holder up to five days to stop a transfer nobody authorized. An onchain transfer has no such pause: once confirmed, only the new owner can move the name again. Whoever controls the seller's wallet controls the name, so the buyer's verification of the seller is done by reading the chain, where the current owner of the name is public.
Some naming systems separate roles, with one address that owns the name and another that manages its records. A buyer wants the ownership role, and checks after the transfer that both roles point where they should. Names registered for a term also keep their expiry date when they change hands, so the buyer reads it before paying, exactly as with a conventional name.
Because the name and the payment can both be moved by transactions, the sequence that takes days on a conventional sale, payment final, then code, then pending window, can be compressed into the same hour. What does not compress is the preparation: agreeing who receives what, at which address, and verifying it before anyone signs.
