BUY WEBSITES
BUY DOMAINS
LOGIN
SIGNUP
Domain Transfer Failures: The Common Causes, the Status Codes Behind Them, and How to Fix a Transfer That Will Not Complete in 2026
A failed domain transfer is almost never a lost domain. In nearly every case the request ran into one unmet condition, the registrar refused it for a reason the rules permit, and the name stayed exactly where it was, with its registration and expiry date untouched. Diagnosing which condition stopped the move is the whole job.
This guide maps the failure to its cause and its fix. It groups the recurring causes the way registrars surface them, ties each to the registration status code you can read yourself, and separates a mechanical stall you fix in minutes from a policy denial you satisfy and from a genuine dispute that escalates. The rules in play are ICANN’s Transfer Policy, the rulebook every accredited registrar follows.
It also covers the case the registrar help pages skip: the freshly acquired aged or expired domain, which is where transfers fail at the highest rate. A name bought at auction or through a marketplace can be inside a lock window, mid-redemption, or carrying a stale masked contact from the prior owner. SEO Domains operates the curated marketplace where the registration status and inherited authority of a domain are read before it is listed, so the transfer starts on a name whose state is known, not guessed.
What a failed domain transfer actually is, and what it is not
A failed transfer is a request that did not complete, and it splits into three distinct states: a mechanical failure caused by an unmet precondition you fix yourself, a policy denial the losing registrar is entitled to issue under ICANN’s Transfer Policy, and a genuine dispute where a transfer is contested between parties. The first kind accounts for the bulk of failures, and the name is never at risk in any of the three.
The word failure gets applied to all three states, which is why a transfer feels stuck when it is only waiting or correctly refused. Telling the three apart is the first move, because each routes to a different fix, and only the third leaves the registrant’s own control.
The three states a stalled transfer can be in
A mechanical failure is the request that never validated: a mistyped authorization code, a lock left on, a confirmation email that never arrived. The registrant clears the condition and resubmits, and the transfer proceeds. A policy denial is a deliberate refusal the losing registrar issued for a reason the Transfer Policy lists, such as the domain sitting inside its 60-day lock or carrying an unpaid balance. The registrant satisfies the condition and the denial lifts. A genuine dispute is the rare case where a transfer was attempted without authority or is contested, and that one routes to ICANN’s dispute process instead of a self-service fix.
In progress, not failed
A valid request inside the losing registrar’s five-day window. Nothing is wrong. The registry will auto-complete it if the window passes without a denial. Reading this as a failure causes a needless cancellation.
Mechanical failure (you fix it)
An unmet precondition stopped validation: bad auth code, registrar lock on, stale contact email, privacy masking the address. Clear the condition at the source and resubmit. The bulk of failures live here.
Policy denial (you satisfy it)
A refusal the Transfer Policy permits: inside the 60-day lock, unpaid prior term, court order, pending dispute, evidence of fraud. Resolve the underlying reason and the denial lifts. Recoverable, not lost.
Genuine dispute (you escalate it)
A transfer contested between parties or attempted without authority. This is the rare case, and it routes to ICANN’s Transfer Dispute Resolution Policy, a separate track from a routine denial.
Why the name itself is never at risk
A failed transfer leaves the domain where it started. The registration does not lapse, the expiry date does not move, the DNS keeps resolving, and the inherited authority of an aged name is untouched. The transfer is an administrative action layered on top of a registration that continues regardless. That is why a failure is a diagnostic problem instead of an emergency, and why the right response is to read the cause calmly in place of cancelling and restarting blindly.
Diagnose it first: read the symptom, then the status code
Every failed transfer announces itself as one of a short list of symptoms: a request denied instantly, a request that never started, a confirmation email that never arrived, or an authorization code rejected at validation. Each symptom maps to a small set of root causes, and the registration status code, read through RDAP, the lookup that replaced WHOIS on 28 January 2025, confirms which one is in play.
Registrars surface a failure as a terse notice or a dashboard flag, rarely with the underlying reason spelled out. Working backward from the visible symptom narrows the cause faster than reading every possible failure mode in order. The table below is the diagnostic map: find the symptom, read across to the likely cause, then confirm it against the status code before acting.
| The symptom you see | The likely cause | The status code to read |
|---|---|---|
| Request denied within minutes | Domain inside the 60-day registration or post-transfer lock | Recent creation or transfer date in the RDAP record |
| Request accepted but never starts | Registrar lock still on at the losing registrar | clientTransferProhibited |
| No confirmation email arrives | Stale administrative email, or privacy masking the address | Privacy or proxy contact in the RDAP record |
| Authorization code rejected | Code mistyped, expired, or generated for a different domain | No status change, validation fails at the gaining registrar |
| Transfer blocked, domain unreachable | Domain suspended, expired, or in its redemption grace period | clientHold, serverHold, or redemptionPeriod |
| Transfer rejected after a delay | A permitted policy denial, or an active DNSSEC chain | Denial notice from the losing registrar, or a DS record present |
Read the status before you change anything
The discipline that separates a clean fix from a chaotic one is checking the registration record before touching the request. A domain showing clientTransferProhibited needs an unlock, not a new authorization code. A domain showing redemptionPeriod needs a restore, not a resubmit. Acting on the wrong assumption wastes the eligibility window and, at certain registrars, can reset the process. The status code removes the guesswork, and it is the same record the gaining registrar reads when it validates the request.
Cause one: the authorization code is wrong, expired, or unreachable
The authorization code, also called the auth code, EPP code, or Transfer Authorization Code, is the single biggest point of failure. The gaining registrar validates it against the registry, and the move stops dead if the code is mistyped, carries a trailing space, has expired, or was generated for a different domain. The fix is to regenerate it at the losing registrar and enter it exactly.
What goes wrong with the code
The code is a unique secret tied to one domain, issued by the losing registrar and required by the gaining one as proof of control. Four things break it. A character entered wrong, including an uppercase or lowercase slip, fails validation outright. A trailing space or line break picked up in a copy-and-paste does the same and is the hardest to spot. A code left unused past its validity window expires, since registrars time-limit it under the policy tightening adopted in the 2024 Transfer Policy amendments. And a code copied from the wrong domain in a portfolio never matches. The mechanics of the code and how registrars deliver it are detailed in EPP code (auth code) explained.
The fix: regenerate, then enter it exactly
The reliable repair is to request a new code from the losing registrar instead of reusing a suspect one. Copy it without surrounding whitespace, paste it into the gaining registrar exactly as issued, and submit within its validity window. If a registrar shows the code only on request or sends it to the contact email, confirm that email is reachable first, because an unreachable contact turns a code problem into a confirmation problem, the subject of cause three. A regenerated code entered cleanly clears the large majority of code-related rejections in one pass.
Cause two: the locks, the registrar lock and the 60-day ICANN locks
Two kinds of lock stop a transfer. The registrar lock, shown as clientTransferProhibited, is a security setting the owner removes at the losing registrar before the move. The 60-day ICANN locks are policy windows that block a transfer after a domain is registered, after a prior inter-registrar transfer, and at certain registrars after a change of registrant. The first is removed in a click, the second is waited out.
The registrar lock: clientTransferProhibited
Nearly every domain carries a registrar lock by default, because it is the front-line defence against hijacking. It appears in the registration record as the status clientTransferProhibited, and while it is set, the gaining registrar cannot pull the domain, so a request either stalls or is rejected. The owner removes it in the losing registrar’s control panel, and it re-applies automatically once the transfer completes. The reasons to keep the lock on at every other time, and the safe way to toggle it, are covered in Transfer locking and when to unlock.
The 60-day eligibility locks under ICANN policy
ICANN’s Transfer Policy prohibits an inter-registrar transfer within 60 days of a domain’s initial registration, and within 60 days of a prior inter-registrar transfer. A domain registered three weeks ago cannot move yet, and a domain that just changed registrars cannot move again for two months. This is the instant denial that catches buyers off guard, because it cannot be removed, only waited out. The full mechanics, including the way a change of registrant can trigger a comparable window, sit in ICANN’s 60-day transfer rule.
Cause three: the contact and confirmation chain is broken
A transfer depends on a confirmation reaching a reachable administrative contact. When the email on record is outdated, or a privacy service masks it, the confirmation request the gaining registrar sends goes nowhere, and the transfer silently never starts. This is the quietest failure mode, because nothing visibly breaks. The fix is to update the contact email and lift privacy temporarily before requesting.
Why a silent failure is the hardest to spot
Unlike a rejected code or a locked domain, a broken contact chain produces no error. The request is accepted, the confirmation is dispatched, and then it lands in a mailbox nobody reads, an address that no longer exists, or behind a privacy proxy that strips it. The registrant waits for a result that was never going to arrive. The two root causes are a stale administrative email left over from an old account or a prior owner, and a WHOIS or RDAP privacy service masking the real contact from the registrar that needs to reach it.
The fix: a reachable contact, privacy lifted
Before initiating, confirm the administrative contact email on the registration record is one you can open, and update it if it is not. Where the registrar requires it, lift contact privacy for the duration of the transfer so the confirmation reaches a visible address, then restore it after the move completes. Checking the spam folder matters too, because confirmation messages are frequently filtered. A reachable contact turns the silent failure into a confirmation you can approve in one click, which is the action that accelerates the whole timeline.
Cause four: the domain state blocks the move
A set of failures are not about the request at all, but about the condition the domain is in. An expired or suspended domain, a name in its redemption grace period, an active DNSSEC chain, or a registration already at its maximum term will each block a transfer until the state is cleared. The registration status code names the state, and the fix is to resolve the state before resubmitting.
Expiry, suspension, and redemption
A transfer cannot run on a domain that is not in good standing. An expired domain must be renewed first. A suspended one, shown as clientHold or serverHold, has had its resolution turned off by the registrar or registry and has to be restored before it can move. A name that lapsed and entered redemptionPeriod, the grace window after expiry, must be redeemed through the registrar, usually at a recovery fee, before any transfer is possible. A domain in pendingDelete is past redemption and scheduled for deletion, and cannot be transferred at all. Reading the status code first tells you which of these you face.
| Status code | What it means | The fix |
|---|---|---|
| clientTransferProhibited | Registrar lock set as a security default | Remove the lock in the losing registrar’s control panel |
| clientHold or serverHold | Domain suspended, resolution turned off | Contact the registrar to lift the hold before transferring |
| redemptionPeriod | Expired, in the post-lapse grace window | Redeem and renew through the registrar first, then transfer |
| pendingDelete | Past redemption, scheduled for deletion | Cannot transfer; wait for the drop, then re-register or backorder |
| DNSSEC active (DS record set) | A signed chain of trust the new registrar cannot continue | Disable DNSSEC, wait the DS record TTL, then transfer |
| Maximum registration term reached | Term plus the renewal year would exceed the TLD cap | Wait until the years remaining leave room under the cap |
DNSSEC and the maximum-term cap
Two state-based failures surprise even experienced owners. An active DNSSEC configuration signs the domain with a chain of trust anchored at the current registrar. If the gaining registrar cannot continue that chain, the transfer breaks, so DNSSEC is disabled and the DS record’s time-to-live is allowed to expire, around 24 hours in practice, before the move. Separately, the major top-level domains cap the total registration term, commonly ten years for the leading generic extensions. Because an inter-registrar transfer usually adds a renewal year, a domain already near its cap can be refused until enough of the term has elapsed to make room.
Cause five: a permitted policy denial, and when it is a real dispute
ICANN’s Transfer Policy lists the specific reasons a losing registrar is permitted to deny a transfer, including evidence of fraud, a court order, a reasonable dispute over the request, non-payment for a previous registration term, and the domain being inside its 60-day lock. A denial for one of these is a recoverable state, not a hijacking. A genuine contested transfer is the separate exception, and it routes to ICANN’s dispute process.
The permitted denial reasons
A losing registrar does not refuse a transfer arbitrarily. The Transfer Policy enumerates the grounds on which a denial is allowed, and a refusal outside that list is itself a policy breach the registrant can escalate. The permitted grounds include evidence of fraud, a reasonable dispute over the identity of the person requesting the transfer, a court order, the domain falling within 60 days of registration or a prior transfer, and an outstanding balance for a previous registration term. Each is satisfied the same way: resolve the underlying condition, then resubmit. An unpaid balance is paid, a court order is lifted, a lock window is waited out.
When a denial is a genuine dispute
A small share of failures are not unmet preconditions but real disputes, where a transfer was attempted without authority or two parties contest who controls the domain. ICANN’s Transfer Dispute Resolution Policy exists for exactly these cases, and it is a separate, formal track filed between registrars in place of a self-service fix. Recognising that a problem has crossed from a mechanical denial into a genuine dispute is what tells a registrant to stop resubmitting and start escalating. The full path, including who can file and the timeline, is set out in Handling a transfer dispute.
The fix-and-resubmit sequence, step by step
A failed transfer is repaired in a fixed order: read the status code, clear the lock, fix the contact and confirmation path, regenerate the authorization code, resolve any domain-state or policy condition, then resubmit at the gaining registrar and approve promptly. Working the sequence in order prevents the leading mistake, which is changing one thing, resubmitting blind, and failing on the next unmet condition.
The steps below run from the cheapest check to the heaviest, so the fastest fixes are tried first. Each step pairs the action with the specific mistake that sends a transfer back to the start. The consolidated table after the steps is the scannable reference for every cause covered above, mapped to its fix in one place.
-
Read the registration status code first
Look up the domain through RDAP and read its status. clientTransferProhibited means unlock, redemptionPeriod means redeem, a recent creation date means wait out the 60-day lock. The code tells you which step below truly applies.
The mistake: resubmitting blind without reading the status. You repair the wrong thing, the transfer fails again, and you burn the eligibility window guessing.
-
Remove the registrar lock at the losing registrar
If the status shows clientTransferProhibited, clear it in the losing registrar’s control panel and allow a short propagation window. The lock re-applies on its own once the transfer completes.
The mistake: trying to unlock at the gaining registrar. The lock is always cleared at the source, the losing registrar, never the destination.
-
Fix the contact email and lift privacy
Confirm the administrative contact email is current and reachable, update it if not, and lift WHOIS or RDAP privacy where the registrar requires it so the confirmation can arrive. Check the spam folder for a confirmation already sent.
The mistake: leaving a stale or masked contact in place. The confirmation goes to an address nobody reads and the transfer stalls with no visible error.
-
Regenerate the authorization code
Request a fresh code from the losing registrar in place of reusing a suspect one. Copy it with no trailing space, and note any validity window it carries so it does not expire before you use it.
The mistake: re-entering the old code by hand or with a hidden trailing space. An invalid or expired code is rejected at validation every time.
-
Resolve any domain-state or DNSSEC condition
Renew an expiring domain, redeem one in its grace period, and lift any clientHold or serverHold. If DNSSEC is active, disable it and wait the DS record TTL before retrying so the chain of trust does not break the move.
The mistake: starting a transfer in the final days before expiry. A domain that lapses mid-transfer can drop into redemption and turn a simple move into a recovery.
-
Satisfy any permitted policy denial
If the losing registrar issued a denial, read the stated reason against the permitted grounds. Pay an outstanding balance, clear a court order, or wait out the 60-day lock. If the reason is not on the permitted list, that is grounds to escalate.
The mistake: resubmitting against a valid denial without resolving its cause. The same denial returns until the underlying condition is satisfied.
-
Resubmit at the gaining registrar and approve promptly
With the conditions cleared, reinitiate at the gaining registrar, enter the fresh code, and approve the confirmation as soon as it arrives. Prompt approval shortens the losing-registrar window from five days to a day or two.
The mistake: cancelling a request that is only waiting out the five-day window. The wait is normal, and cancelling can reset the process or trigger a fresh lock.
| The cause | Why the transfer fails | The fix |
|---|---|---|
| Invalid or expired auth code | The code fails validation against the registry at the gaining registrar | Regenerate at the losing registrar, paste with no trailing space |
| Registrar lock on | clientTransferProhibited blocks the gaining registrar from pulling the domain | Remove the lock in the losing registrar’s control panel |
| Inside the 60-day lock | ICANN policy prohibits a transfer after registration or a prior transfer | Wait out the window, confirm eligibility via the RDAP date first |
| Stale or masked contact email | The confirmation request reaches no one, so the move never starts | Update the admin email and lift privacy before requesting |
| Domain expired or in redemption | A name out of good standing cannot be transferred | Renew or redeem through the registrar, then transfer |
| DNSSEC active | The signed chain of trust cannot continue at the new registrar | Disable DNSSEC, wait the DS record TTL, then retry |
| Permitted policy denial | Unpaid prior term, court order, fraud, or pending dispute | Resolve the underlying condition; these are valid denials, not errors |
| Maximum term reached | The renewal year would push the term past the TLD cap | Wait until the years remaining leave room under the cap |
| Cancelled a waiting request | A request inside the five-day window was not a failure | Let the window run; the registry auto-completes a clean transfer |
Failed transfer frequently asked questions
The five questions that recur when a domain transfer fails, answered against ICANN’s Transfer Policy and the diagnostic this guide lays out.
Q1Why did my domain transfer fail?
Almost always one unmet condition stopped it: an invalid or expired authorization code, a registrar lock left on, a domain inside its 60-day eligibility lock, a stale or privacy-masked contact email, or a domain out of good standing through expiry or a registry hold. Read the registration status code through RDAP to identify which, then fix that condition at the losing registrar and resubmit. The domain stays put and untouched while you do.
Q2Did I lose my domain when the transfer failed?
No. A failed transfer leaves the domain exactly where it was, at its current registrar, with its registration, expiry date, DNS, and inherited authority all intact. A failure is a request that did not complete, not a deletion. The single risk to the name is starting a transfer in the final days before expiry and letting it lapse mid-move, which is why a domain near expiry is renewed before any transfer is attempted.
Q3Can I retry a transfer immediately after it fails?
Yes, as soon as the condition that caused the failure is fixed. A rejected code, a lock left on, or a bad contact email can be corrected and the transfer reinitiated right away. The one exception is a failure caused by the 60-day ICANN lock, which cannot be cleared and has to be waited out before a new request will succeed. Confirm eligibility via the registration date before resubmitting.
Q4Why does the transfer say the authorization code is invalid?
The leading reason is a trailing space or line break captured when the code was copied, which fails validation even though the visible characters look correct. A code can also have expired, been mistyped including an uppercase or lowercase slip, or been generated for a different domain in the account. Request a fresh code from the losing registrar, copy it cleanly with no surrounding whitespace, and enter it exactly as issued.
Q5The transfer has been pending for days. Has it failed?
Not necessarily. Under ICANN’s Transfer Policy the losing registrar has up to five calendar days to acknowledge or deny a valid request, and the registry auto-completes the move if that window passes without a denial. A transfer pending inside that window is in progress, not failed. Approving the confirmation at both ends shortens it to a day or two. Cancelling a request that is only waiting is the mistake that resets the clock.
Where transfers fail most: the acquired domain, and how to start clean
The transfer that fails at the highest rate is the one on a freshly acquired aged or expired domain, because a recently registered or recently transferred name can be inside its 60-day lock, mid-redemption, or carrying a stale masked contact from the prior owner. Reading the domain’s registration status before purchase removes every one of those failures in advance. SEO Domains operates the curated marketplace where that status is read before a name is listed.
Why the acquired name is the high-risk transfer
A domain bought blind is the worst-case transfer. It can have changed registrars weeks ago and still sit inside its post-transfer lock. It can have lapsed and been re-registered, which restarts the clock. Its administrative contact can be the previous owner’s masked address, breaking the confirmation chain before the buyer even starts. None of these are visible from a listing price, and every one of them surfaces as a failed transfer at the costliest moment, right after the money has changed hands. The diligence that prevents them belongs at purchase, through an RDAP read of the registration record, not after the failure.
How a screened acquisition removes the failure
The way to never debug an acquired-domain transfer is to source a name whose state is already known. A registration record read before listing tells you the creation and transfer dates, the lock status, and whether the contact is reachable, so the 60-day lock, the redemption risk, and the broken confirmation chain are all resolved before purchase instead of diagnosed after it. Browse transfer-ready aged and expired domains, with registration status and authority screened before pricing, on the SEO Domains marketplace, where the inherited authority and the registration state are both read before the name is sold. The asset is the domain’s earned authority; the transfer is the administrative step that never needs to put it at risk.
