Ahosting Logo
Knowledge Base

What to Do When a Domain Transfer Fails

Five reasons a transfer is rejected, in the order worth checkingLockedthe defaultstate; it has tobe switched offfirstInside sixty daysof registrationor of a previoustransferWrong or expired coderequest a freshoneApproval not receivedsent to thecontact address,often behindprivacyRegistry holdunverifiedcontact details,or a disputeThe rejection message rarely names the cause. Working down this list is faster than reading it.

A transfer is submitted and rejected, and the message says something unhelpful. The real cause is nearly always on a short list.

1. The domain is still locked

Transfer lock is on by default, and it exists precisely to prevent transfers. It has to be turned off at the current registrar, deliberately.

whois example.com | grep -i status

A status containing clientTransferProhibited is this. Turn it off, wait a few minutes for the registry to reflect it, and try again.

Turn it back on once the transfer completes: it is a protection worth having the rest of the time. Domain locking goes over why.

2. The authorisation code is wrong

More often than it should be, and for dull reasons.

Codes are frequently regenerated when the domain is unlocked, so a code obtained before unlocking is no longer valid. Get it after unlocking.

They also expire, and they contain characters that are easy to mistype. Copy it rather than retyping it, and check for a trailing space. A space copied along with the code is a genuinely common cause.

Getting your EPP authorisation code goes into where it comes from.

3. You are inside a sixty-day window

Two separate rules, and both produce a flat refusal.

A domain transferred between registrars cannot be transferred again for sixty days.

A domain whose registrant contact was changed may also be locked for sixty days, depending on the registrar's settings. This catches people who tidy up their contact details and then try to move the domain the same week.

There is no way round either. If a move is planned, transfer first and correct the contact details afterwards.

4. The contact address is unreachable

Approval messages go to the administrative contact on the registration. If that address belongs to a former employee or a domain that no longer works, the approval nobody received is sitting somewhere nobody reads.

whois example.com | grep -i email

Update the contact to a working address, then note that doing so may start the sixty-day lock above, so check the registrar's behaviour before changing it in the middle of a transfer.

Privacy protection can also intercept these messages. Some registrars handle it transparently and some do not; turning privacy off for the duration removes the uncertainty.

5. Too close to expiry

Most registries refuse a transfer within a short window before expiry, and a domain already expired must be renewed before it can move at all.

Renewing does not lose the remaining time; the year is added to what is left, and most transfers add a year as well. So renewing first is not money wasted.

A domain in redemption is a different situation with a substantial fee, and that must be resolved with the current registrar before anything else. What happens when a domain expires sets out the stages.

When the registrar simply refuses

The losing registrar may decline for non-payment, a dispute, or a domain acquired in a way they are investigating.

That is a commercial conversation instead of a technical one, and resubmitting achieves nothing. Ask them directly what the hold is for.

If the domain is held in an account you cannot reach at all, the registrant contact is what matters, and if that is you, the registrar has a recovery process. Moving a domain between registrar accounts walks through the case where a full transfer is the wrong tool anyway.

While the transfer is pending

The domain keeps working. Nameservers do not change during a transfer, so the site and email carry on.

What can change is at completion, when some registrars reset nameservers to their own defaults. Record the current DNS records before starting, so recreating them is a checklist instead of an emergency. What to check after transferring a domain has the detail.

Check the status before submitting again

Resubmitting a refused transfer without changing anything is the commonest response and it achieves nothing except another wait.

whois example.com | grep -iE 'status|registrar:|expir'

Read every status line in place of the first. A domain can carry several at once. A transfer prohibition and a registrar hold, for instance, and clearing one leaves the other in place.

Statuses beginning client are set by the registrar and can be lifted by them. Statuses beginning server are set by the registry and cannot: those require the underlying reason to be resolved first, which is a different conversation. There is more on the most common one in unverified contact details.

Watch the transfer instead of waiting for it

A pending transfer has an observable state, and knowing which stage it is at determines whether to act.

whois example.com | grep -i 'pendingTransfer'
dig example.com NS +short

A pendingTransfer status means the request reached the registry and is awaiting approval or the automatic timeout. That is progress, and interfering with it (changing nameservers, altering contacts) can cancel it.

The absence of that status a day after submitting means the request never reached the registry, which is a different problem: it was rejected at the gaining registrar rather than by the losing one.

Approving rather than waiting out the clock

Most transfers complete automatically after several days if nobody objects, and most people wait for that unnecessarily.

The losing registrar usually offers an explicit approval that completes it immediately, frequently in the domain's own management screen rather than in a message.

Approving deliberately also removes a risk: during the waiting period, anyone with access to the losing account can cancel the transfer, and an automatic completion gives them the full window to do so, which matters when the transfer is happening because a relationship ended.

After it completes, verify rather than assume

whois example.com | grep -iE 'registrar:|expir|status'
dig example.com NS +short
dig example.com MX +short

Four things change or can change: the registrar, the expiry date, which usually gains a year. The transfer lock, which is frequently off, and the nameservers, which some registrars reset to their own.

The nameserver reset is the one that causes an outage, and it happens at completion rather than at submission, so a transfer that appeared to go smoothly can take the site down hours later. What to check after transferring a domain sets out the full list.