A failed or rejected domain transfer is frustrating, but it is almost always caused by one of a short, well-known list of issues — and every one of them has a clear fix. Domain transfers are a standardised process with strict prerequisites, so when a transfer fails, it is usually because one of those prerequisites was not met, and the error message often names the culprit. This guide walks through the common reasons a domain transfer fails and exactly how to fix each one.

You will learn the usual causes of a failed transfer — a locked domain, a bad auth code, the 60-day rule, an inaccessible or unactioned confirmation email, an expired or disputed domain, and mismatched contact details — and the fix for each. By the end you will be able to diagnose why your transfer failed and correct it so the retry goes through cleanly.

The domain is still locked

The most common reason a transfer fails is simply that the domain was still locked when you tried to transfer it. The registrar transfer lock — a security setting that is on by default — blocks any transfer request while it is active, so if you initiated a transfer without turning it off first, the request is automatically rejected.

The fix is straightforward: go to your current registrar, find the transfer lock setting in the domain’s management page (labelled something like ‘Transfer Lock’, ‘Domain Lock’, or ‘Registrar Lock’), turn it off, confirm the domain now shows as unlocked, and then retry the transfer. Because the lock change can take a short time to register, confirming the unlocked status before retrying avoids failing again for the same reason.

So if your transfer failed and you had not unlocked the domain, that is almost certainly the cause — unlock it, confirm the status, and retry. This is the single most frequent transfer failure and the easiest to fix, which is why unlocking is always the first prerequisite to check. Many ‘my transfer keeps failing’ situations are resolved entirely by realising the domain was never unlocked in the first place.

The auth code is wrong or expired

The second most common failure is an incorrect or outdated auth/EPP code. Since the auth code is the credential that authorises the transfer, an inexact code — a mistyped character, a missing digit, a stray space, or the wrong case — causes the transfer to be rejected, as does using a code that has expired or been superseded by a freshly generated one.

The fix is to obtain a correct, current auth code and enter it exactly. Get the code fresh from your current registrar (regenerating it if your registrar issues a new one each time), copy it precisely rather than typing it to avoid transcription errors, and paste it into the new registrar’s transfer form. If you had used an older code, use the latest one, since generating a new code can invalidate the previous.

So an auth-code failure is fixed by using a freshly obtained, exactly-copied code. This is worth checking carefully because the errors are subtle — a single wrong character is enough to fail the transfer — and pasting rather than typing eliminates the most common mistake. If the transfer failed with a message about an invalid authorisation or transfer code, re-obtaining and carefully re-entering the code resolves it in almost every case.

The 60-day rule is blocking it

If your domain was registered or previously transferred within the last 60 days, the industry-wide 60-day transfer lock is blocking the transfer, and no amount of unlocking or correct auth codes will get around it — it is a fixed policy, not a setting. A transfer attempted within this window fails because the domain is simply not eligible to transfer yet.

The ‘fix’ here is not a setting change but timing: you have to wait until the 60-day period from the triggering event (registration or the previous transfer) elapses, after which the transfer can proceed normally. You can check exactly when the window ends by looking at your domain’s registration or last-transfer date in its registration record. If your real goal is a hosting move rather than a registrar transfer, remember that DNS changes are not blocked by this rule, so you can move hosts now and transfer the registration later.

So if your transfer failed because of the 60-day rule, the solution is to wait out the window (or to pursue a DNS-based hosting move instead, if that is your actual aim). This one is unique among the failure causes in that it cannot be fixed by correcting a setting — it is a mandatory waiting period. Recognising it as the cause at least tells you the transfer is not broken; it simply cannot happen until the eligibility window opens.

The confirmation wasn’t approved

Many transfers fail or stall because the confirmation step was not completed. A transfer typically triggers an approval email to the domain’s administrative contact, and if that email is not approved — because it went to an inaccessible address, landed in spam, or was simply not actioned in time — the transfer cannot proceed and may eventually be cancelled.

• Inaccessible admin email: if the domain’s administrative email is an old address you cannot check, update it to a working one at your current registrar, then retry.
• Email in spam or missed: check your spam/junk folder for the confirmation, and search for it — approving it promptly is essential.
• Approval timed out: if the confirmation window lapsed, you may need to re-initiate the transfer and approve promptly this time.
• Approve on both sides if needed: some setups require action at both registrars — check for a pending approval at your current registrar too.

So a confirmation-related failure is fixed by ensuring you can receive and promptly approve the confirmation email: correct the administrative email if it is inaccessible, check spam, and act on the approval quickly. Because the confirmation is the step most dependent on human action, it is also the one most likely to stall a transfer — making sure the approval email reaches you and gets approved is often all that is needed to turn a failed or stalled transfer into a completed one on the retry.

The domain is expired or in dispute

A domain that is expired, or subject to a dispute or hold, will fail to transfer because it is not in the good standing that transfers require. An expired domain in particular cannot typically be transferred until it is renewed and restored to active status, and a domain under a dispute, legal hold, or pending-verification status is similarly blocked until that condition is cleared.

The fix depends on the specific status. For an expired domain, renew it at your current registrar to bring it back into good standing, then (after any required period) proceed with the transfer. For a verification hold — such as a pending registrant-verification requirement — complete the verification the registrar is requesting. For a genuine dispute, the transfer will not proceed until the dispute is resolved through the appropriate channel.

So if your transfer failed because of the domain’s status, identify the specific issue (expired, in verification, or in dispute) and resolve it: renew, verify, or settle as applicable, then retry. These failures are less about the transfer process itself and more about the domain not being in a transferable state — once you restore it to good standing, the ordinary transfer prerequisites apply again and the transfer can go ahead. The domain’s status in your registrar account or its registration record usually indicates which of these applies.

Contact details or verification mismatches

A subtler class of transfer failure comes from problems with the domain’s contact details or required verifications. If the registrant contact information is incomplete, outdated, or unverified, some transfers can be held up, since the domain system increasingly requires accurate, verified registrant details. A recent change to the registrant can also, as noted, trigger a lock that blocks the transfer.

The fix is to ensure your domain’s contact details are complete, accurate, and verified before transferring: update the registrant, administrative, and technical contact information to current details, complete any email-verification the registrar requires, and avoid making registrant changes immediately before a transfer (which can start a fresh lock). Having clean, verified contact details removes this category of hold.

So if your transfer failed for reasons that do not fit the more obvious causes, check your contact details and verification status — an unverified or mismatched registrant, or a recent registrant change, can be the hidden culprit. Ensuring the domain’s contact information is accurate and verified, and not freshly changed, clears this obstacle. Between this and the other common causes — a locked domain, a bad auth code, the 60-day rule, an unapproved confirmation, and an expired or disputed domain — you have the full checklist of why a transfer fails and how to fix each, which is almost always enough to get a bounced transfer through on the retry.

FAQs

Why did my domain transfer fail?

Almost always an unmet prerequisite: the domain was still locked (unlock it), the auth/EPP code was wrong or expired (get a fresh one and paste it exactly), the 60-day rule applied (wait it out), the confirmation email wasn’t approved (check it’s accessible and approve promptly), the domain was expired or in dispute (renew or resolve), or contact details were unverified or mismatched (update and verify them). The error usually names the cause.

My domain transfer says the domain is locked — what do I do?

Go to your current registrar, open the domain’s management settings, find the transfer lock (labelled ‘Transfer Lock’, ‘Domain Lock’, or ‘Registrar Lock’), and turn it off. Confirm the domain’s status shows as unlocked, then retry the transfer. A still-locked domain is the single most common transfer failure, and unlocking plus confirming the status resolves it.

Why does my auth code keep getting rejected?

Usually it’s a copy error — a mistyped or missing character, a stray space, or wrong case — so re-copy it exactly (paste, don’t type). It may also be outdated: if your registrar generates a fresh code each time, use the latest, since a new one can invalidate the old. Get a current code from your current registrar and enter it precisely. Also confirm the domain is actually unlocked, since a locked domain fails even with a correct code.

My transfer failed because of the 60-day rule — can I fix it?

Not with a setting — the 60-day rule is a fixed anti-fraud policy that blocks transferring a domain within 60 days of registration or a previous transfer. You have to wait until the window (from your domain’s registration or last-transfer date) elapses. If your real goal is moving hosts rather than registrars, you don’t need to wait: DNS changes aren’t blocked, so move hosts now and transfer the registration later.

Why didn’t my transfer complete after I started it?

Often the confirmation wasn’t approved. A transfer sends an approval email to the domain’s administrative contact; if that address is inaccessible, the email went to spam, or it wasn’t actioned in time, the transfer stalls and can be cancelled. Fix the administrative email if it’s an old address, check spam, approve promptly, and check for a pending approval at your current registrar too — then the transfer can complete.

Can an expired domain be transferred?

Generally not until it’s renewed and restored to active, good-standing status — an expired domain, or one in dispute or under a verification hold, isn’t in the transferable state transfers require. Renew the expired domain at your current registrar (or complete the verification, or resolve the dispute, as applicable), then retry the transfer. The domain’s status in your account or registration record indicates which issue applies.

The bottom line

A failed domain transfer is almost never mysterious: because transfers are a standardised process with strict prerequisites, a failure nearly always means one specific prerequisite was not met, and the error message usually points straight at it. The most common cause is simply that the domain was still locked — fixed by turning off the transfer lock at your current registrar, confirming the unlocked status, and retrying. The next is an incorrect or outdated auth/EPP code — fixed by obtaining a fresh code and pasting it exactly, since a single wrong character or a superseded code will fail. The 60-day rule is unique in that it cannot be fixed by any setting: if the domain was registered or transferred within the last 60 days, you must wait out the window (or, if your real goal is a hosting move, do that via DNS now and transfer the registration later).

The remaining causes round out the checklist. A transfer that stalls rather than bounces is usually an unapproved confirmation — fixed by ensuring the administrative email is accessible, checking spam, and approving promptly, since that step depends most on human action. An expired, disputed, or verification-held domain fails because it is not in good standing — fixed by renewing, resolving, or verifying as applicable to restore it to a transferable state. And subtler holds come from incomplete or unverified contact details, or a recent registrant change that started a fresh lock — fixed by keeping registrant information accurate and verified and not changing it right before a transfer. Run through these six causes — locked domain, bad auth code, the 60-day rule, unapproved confirmation, bad standing, and contact/verification issues — and you can diagnose virtually any failed transfer and correct it so the retry goes through cleanly.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. A domain transfer fails almost always because of an unmet prerequisite, each with a clear fix: domain still locked (unlock it, confirm status), wrong or expired auth code (get a fresh one, paste exactly), the 60-day rule (wait it out, or move hosts via DNS instead), unapproved confirmation email (make the admin email accessible, check spam, approve promptly), expired/disputed domain (renew or resolve), or unverified/mismatched contact details (update and verify). The error usually names the cause — fix that condition and retry.