A domain transfer moves the registration record for a domain — who the registrar of record is — from one registrar to another. It's a completely separate operation from moving where a domain is hosted or where its email is handled, and confusing the two is the source of a lot of unnecessary anxiety during what is, done correctly, a fairly routine process. Once a domain has moved, its DNS records are managed the same way as any other domain — see A Practical Guide to DNS if that side of things is unfamiliar. It's also worth distinguishing a transfer from a lapse: a transfer is a deliberate, controlled move between registrars, while what happens when a domain expires is a very different, unplanned situation with its own recovery process.

What a domain transfer actually moves

Every registered domain has a registrar of record — the company accredited to manage its registration with the relevant registry. Transferring a domain changes that registrar, typically to consolidate domains under one account, take advantage of different renewal pricing, or move to a provider offering better account tools. It does not, by itself, change where the website is hosted, where email is delivered, or any of the domain's DNS records — those are controlled separately and, depending on how the transfer is configured, can be left completely untouched.

The EPP code: what it is and where to get it

An EPP code — short for Extensible Provisioning Protocol (EPP) code, also called an authorization code or transfer key — is a unique code generated by the current registrar that proves the person requesting the transfer actually controls the domain. EPP is the standard protocol registrars use to communicate with domain registries, and the code takes its name from that protocol; the concept itself is simpler than the name suggests — it functions as a one-time password for moving a specific domain. It's a standard security measure required across virtually all gTLDs. To obtain one, log into the domain's current registrar account, locate the domain's management page, and request or reveal the EPP code — most registrars generate this on demand or display it directly, sometimes with a short delay for security reasons. The new registrar will ask for this code as part of initiating the transfer.

Registrar lock and why it exists

Domains are protected by a registrar lock (technically clientTransferProhibited) by default, which blocks transfer requests entirely regardless of whether a valid EPP code is presented. This exists specifically to prevent unauthorized transfers — domain hijacking is a real and historically significant threat, and the lock is the first line of defense against it. Before a transfer can proceed, the lock has to be removed from the domain's current registrar account; this is almost always a toggle in the domain management interface, and it's the single most common reason a transfer request stalls immediately after being submitted.

Pre-transfer checklist

Working through this before initiating a transfer avoids the vast majority of delays:

  • Confirm the domain is at least 60 days past its initial registration or last transfer — ICANN policy blocks transfers inside that window regardless of anything else being correctly configured.
  • Remove the registrar lock at the current (losing) registrar.
  • Confirm the registrant contact email address on file is current and actually monitored — the mandatory approval email goes here, not to whichever address initiated the transfer.
  • Retrieve the EPP code and note it down accurately — a single mistyped character is a common, entirely avoidable failure point.
  • Disable WHOIS/ID privacy temporarily if the current setup obscures the registrant contact in a way that could delay the approval email reaching a real inbox (this varies by registrar).

The transfer process, step by step

The general sequence is consistent across registrars, even though interfaces differ: unlock the domain and retrieve the EPP code at the current (losing) registrar; initiate the transfer at the new (gaining) registrar, providing the domain name and EPP code; confirm the transfer via an approval email sent to the domain's registrant contact address — this step is mandatory under ICANN policy and can't be skipped; and wait out the transfer window, which is typically five to seven days unless the losing registrar approves it sooner, or the gaining registrar's account owner explicitly approves an early transfer where that's an available option. Domains registered or transferred within the last 60 days are generally ineligible for another transfer, another ICANN-mandated safeguard against abuse.

What happens if authorization is delayed

If the approval email is never actioned — because it went to an unmonitored inbox, was missed, or the registrant simply hasn't responded — most registries apply a default outcome after the standard transfer window elapses, which for many gTLDs means the transfer proceeds automatically unless the losing registrar explicitly denies it, though the exact default can vary by registry and registrar policy. In practice this means an ignored approval email doesn't necessarily block a transfer indefinitely, but it does mean the transfer's timing becomes unpredictable rather than completing promptly — which matters if a migration or cutover was planned around a specific date. Monitoring the registrant contact inbox actively during the transfer window, rather than assuming a delay is harmless, is the practical safeguard. If a transfer needs to be actively stopped — a mistaken request, for instance — that has to be done explicitly at the losing registrar before the window closes; a delay alone isn't a cancellation.

What happens to DNS during a transfer

By default, a domain's nameservers — and therefore its DNS records — stay exactly as configured before the transfer, unless deliberately changed. This means a website and email can, and usually should, keep working without interruption throughout a transfer, provided the nameservers aren't also being changed at the same time. Combining a registrar transfer with a nameserver change in the same window is possible but adds unnecessary risk; the safer sequence is to complete the registrar transfer first, confirm everything is stable, and only then change nameservers if that's also part of the plan. It's worth explicitly verifying DNS continuity after the transfer completes, not just assuming it — a quick dig example.com NS +short immediately after confirms the nameservers are still exactly what they were before, and that the new registrar hasn't applied any default nameservers of its own during the move, which some registrars do unless told otherwise.

Avoiding the most common transfer problems

Most failed or delayed transfers come down to a short list of avoidable issues: the domain is still locked at the losing registrar; the EPP code was mistyped or has expired (some registrars time-limit them); the approval email went to an out-of-date or unmonitored registrant contact address; or the domain falls inside the 60-day post-registration or post-transfer restriction window. Checking the domain's current status, contact details and lock state before initiating a transfer, using the checklist above, resolves the large majority of these before they become a problem. ANYSRV's own domain transfer process follows this same standard flow.

After the transfer completes

Once a transfer finishes, a short verification pass avoids discovering a problem later rather than immediately: confirm the domain shows the correct new registrar in a WHOIS lookup; re-enable the registrar lock at the new registrar, since it's usually off by default immediately after a transfer completes and leaving it off unnecessarily extends the window during which another transfer could be initiated; verify the registrant, admin and technical contact details carried over correctly, since some registrars reset these to placeholder values rather than preserving them; and confirm the renewal date reflects any renewal period added as part of the transfer, which most registrars include automatically but is worth checking rather than assuming. None of these steps affect whether the site or email is working — they're account hygiene, not connectivity — but skipping them is how a domain ends up unexpectedly unlocked, or with contact details pointing at an old email address, for months before anyone notices.