Advanced
Lesson 2 of 14 · ~10 min

Registrar transfer mechanics

The pre-flight + sequence + the two 60-day ICANN locks. Knowing the steps turns a transfer into a deterministic checklist.

Registrar transfers fail at predictable steps: the admin contact email is dead, the domain is inside the 60-day lock window, the auth code has a typo, the domain is still locked. Knowing the sequence (including the pre-flight checks) turns a what could go wrong task into a deterministic checklist.

Most failed transfers come down to a step that wasn’t checked before submitting.

The sequence

  1. 1. Confirm the admin contact email is live (at losing registrar)

    The transfer approval email at most registrars goes to the admin contact. A dead email stalls the transfer at the approval step. If it needs updating, update now and wait a few hours for any registry verification.

  2. 2. Confirm the domain is outside the 60-day post-registration / post-transfer lock

    ICANN policy: a domain cannot be transferred for 60 days after registration, and for 60 days after a previous transfer. If the domain is inside that window, the transfer can’t be initiated until the window passes.

  3. 3. Disable WHOIS privacy if the losing registrar requires it

    Many registrars require privacy off for transfers because the proxy email interferes with the approval flow. Check the losing registrar’s documentation.

  4. 4. Unlock the domain

    Remove the clientTransferProhibited status in the losing registrar’s panel. WHOIS should now show ok (or no client locks).

  5. 5. Request the auth code

    Get it from the losing registrar’s panel. Save securely; treat like a password.

  6. 6. Initiate the transfer at the gaining registrar

    Provide the domain name and the auth code. The gaining registrar charges for the transfer (usually one year of renewal is added to the existing expiry).

  7. 7. The losing registrar emails the admin contact for approval

    The admin contact clicks the approval link. Email delivery here is where most transfers stall; if no email within 30 minutes, check the admin contact in WHOIS.

  8. 8. Wait the 5-day window

    ICANN policy gives the losing registrar up to 5 days to release. Some registrars expedite (hours rather than days) if the gaining-side request is approved.

  9. 9. Transfer completes, post-transfer cleanup

    Domain appears in the gaining registrar’s panel. The gaining registrar applies its own registrar lock. Verify the four contacts (registrant, admin, tech, billing) carried over correctly, and the 60-day post-transfer lock now applies.

The two 60-day ICANN locks

Surface these during quoting, not after
  • Post-registration lock. A newly-registered domain cannot be transferred for 60 days after first registration. Blocks the register at the cheapest, immediately transfer arbitrage pattern.
  • Post-transfer lock. After a successful registrar transfer, the domain cannot be transferred again for 60 days. Blocks domain-hijacking schemes that depend on rapid registrar churn.

Both are at the policy level, not the registrar’s discretion. You cannot bypass.

If a client expects to transfer a recently-registered or recently-transferred domain immediately, surface the lock during quoting. We can prepare the paperwork now; the transfer can be initiated on [date 60 days from registration / transfer].

What this is NOT

  • “Skipping the admin contact check is fine if the transfer’s been done before.” Always confirm. Email addresses go stale; this is the most common failure mode.
  • “The auth code is long-lived; reuse it.” Usually consumed on transfer or regenerated by the panel. If a transfer doesn’t start within a few days, request a fresh code.
  • “Once the transfer is initiated, it’s irreversible.” Until the 5-day window completes, the losing registrant can deny approval and stop the transfer. After completion, transferring back requires another full transfer cycle.

When to escalate

  • The domain is business-critical and the client hasn’t sign-offed on a maintenance window. Transfers shouldn’t cause downtime (DNS doesn’t change unless explicitly moved), but unexpected issues can.
  • The domain has DNSSEC enabled (lesson 06 covers the safe-disable requirement). Transferring with DNSSEC on can break the zone at validating resolvers.
  • The losing registrar is unresponsive or refuses to release. Sometimes registrars resist competitive transfers; the dispute path is ICANN’s Transfer Dispute Resolution Policy and is well above helpdesk scope.
  • The client asks for a change of registrant as part of the transfer. Change of registrant has its own 60-day lock and shouldn’t be combined without senior coordination.

Decision walkthrough

Approval email missing
A transfer stalled at step 7. The client says they never received the approval email; it's been an hour. The Cloudflare side reports 'pending; awaiting approval at losing registrar.'
What's the diagnostic step?
Next lesson →