Domain transfer checklist: Auth Code, unlock and a move without DNS surprises

Imagine you rent an apartment. The building stays put. Your furniture, your mail, and your internet bill do not magically follow you when you change landlords. What you are really changing is who holds the lease paperwork, who renews it, who can approve a move-out, and who answers when the city asks who is responsible for that unit.

A domain transfer between registrars works the same way. The domain name itself is the address on the building. Your website files, email mailboxes, and hosting plan are the furniture and utilities. The registrar is the landlord who currently sponsors your registration with the registry. Moving to a new registrar means changing which company holds that sponsorship, not packing up your whole online life into a cardboard box.

This guide walks through the moving day checklist most domain owners actually need: the authorization (auth / EPP) code, the unlock step and the status called clientTransferProhibited, the common 60-day locks after create or transfer under ICANN’s Transfer Policy for many gTLDs, what travels with the domain versus what stays behind, DNS and nameserver risks while the move is in flight, and how country-code domains (ccTLDs) often differ from generic ones (gTLDs) at a high level. Timelines and exact screens vary by TLD and registrar; treat the rules below as the usual map for ICANN-governed names, then confirm details for your extension before you start.

If you manage domains at a registrar such as SoxDomains, the same ideas apply whether you are transferring in or preparing a domain to leave someday. The goal is a calm move, not a surprise lockout on moving day.

What “transfer” actually means

In registrar language, an inter-registrar transfer changes which accredited registrar is the “registrar of record” for your domain at the registry. You are not renaming the domain. You are not automatically moving your hosting. You are changing who can renew the name, who shows the domain in their customer panel, and who you ask for support about registration itself.

A short split that prevents confusion:

People say “I transferred my domain” when they mean three different projects: change registrar, change DNS host, and change web host. You can do one, two, or all three. Doing all three on the same afternoon without a plan is how weekends get ruined.

For more on how nameservers and propagation behave when the “lobby desk” changes, see Nameservers, glue, and DNS propagation. For the alphabet of A, MX, and TXT records, see DNS records explained.

The apartment-lease metaphor (and why it helps)

Keep this picture in your head while you click through panels:

• The building address = your domain name. It does not change when the landlord changes.
• The current landlord = your losing (current) registrar.
• The new landlord = your gaining (destination) registrar.
• The city / property registry = the TLD registry (and, for many gTLDs, the policy layer coordinated through ICANN).
• The move authorization form = the auth code (also called AuthInfo, EPP code, or similar).
• The deadbolt on the door = transfer lock / clientTransferProhibited.
• The “no moves for 60 days after signing” clause = the common post-create and post-transfer restrictions in ICANN’s Transfer Policy.
• The confirmation emails = the Form of Authorization (FOA) / transfer confirmation flow, proof that someone with authority said “yes, move this lease.”
• Furniture and utilities = hosting, email, CDN, and other services that are not the lease itself.

If something fails, ask which layer broke: paperwork (auth/unlock), waiting period (60-day style locks), confirmation (emails you never got), or utilities (DNS/hosting you accidentally unplugged).

Step one: confirm you can move at all

Before you request a code, check eligibility. For many gTLDs under ICANN’s Transfer Policy, a registrar may deny an inter-registrar transfer when the domain was created fewer than 60 days ago, or when it was transferred fewer than 60 days ago. There is also a common 60-day inter-registrar transfer lock after a Change of Registrant (a material change to registrant name, organization, or email, details are defined in the policy), unless your registrar offered an opt-out and you used it before that change.

That last point catches people who update contact details “so the transfer emails arrive,” then discover they just started a lock. Order of operations matters: get contacts and mailbox access healthy without unnecessary material registrant changes if a transfer is imminent, or ask your registrar how Change of Registrant interacts with locks for your TLD.

Other real-world blockers (high level):

• The domain is expired, or payment/dispute holds apply (expiration timelines are a whole separate topic, see domain expiration, grace, redemption, and pending delete).
• A dispute proceeding or court order blocks moves.
• A registry-level restriction is in place (sometimes shown as statuses such as serverTransferProhibited). That is different from the ordinary registrar lock you can usually turn off yourself.
• Your TLD is a ccTLD with its own transfer rules (more below).

If WHOIS or your registrar panel shows clientTransferProhibited, that often simply means the ordinary transfer lock is on, useful security by default, not necessarily a forever ban. If you see a server-side prohibited status you cannot clear, you may be waiting out a policy lock or a registry rule. When in doubt, ask the current registrar which status is blocking you and whether it is client-controlled.

The auth code: your moving authorization form

Most gTLD transfers require an authorization code, you will hear auth code, AuthInfo, or EPP code. Same job: a secret string that proves the transfer request is coming from someone who can control the domain at the current registrar.

Under ICANN’s Transfer Policy requirements around AuthInfo and locks:

• AuthInfo codes should be unique per domain.
• If the registrar does not give you self-service tools, they generally must provide the AuthInfo and remove clientTransferProhibited within five calendar days of your request.
• Registrars should not make getting the code harder than changing ordinary contact or nameserver information.
• Payment disputes alone are not supposed to be a reason to refuse releasing the AuthInfo or removing the client transfer lock (with separate rules around unpaid periods and expiration).

Practical habits that save headaches:

1. Request or generate the code when you are ready to start, not weeks early. Some registrars rotate or expire codes; treat a stale code as suspect.
2. Copy it carefully. A single wrong character fails the transfer.
3. Do not paste it into public tickets, chat rooms, or screenshots you share widely. It is a key.
4. After a successful move, you usually do not need the old code anymore. At the new registrar, locks and codes are managed fresh.

Our FAQ summarizes inbound transfers this way: unlock at the current registrar, obtain the authorization (EPP) code, and start the transfer from your account, and notes that most gTLD transfers include a one-year renewal. That renewal point matches a widely known Transfer Policy effect: a completed holder-authorized inter-registrar transfer typically extends the registration term by one year, subject to the usual maximum unexpired term (commonly up to ten years). Exact billing display varies by registrar; read the order summary before you pay.

Unlock: turning off clientTransferProhibited

Think of registrar lock / domain lock as a deadbolt. On most domains it is on by default so a random transfer request cannot walk off with your lease. In EPP status language, that often appears as clientTransferProhibited.

To transfer out:

1. Sign in at the current registrar.
2. Find Transfer Lock, Registrar Lock, or Domain Lock (wording varies).
3. Disable it for that domain.
4. Confirm the status no longer blocks transfers (panel text or WHOIS status list).

ICANN policy expects registrars to let you remove clientTransferProhibited without absurd hoops, and within five calendar days if they lack a self-service unlock. After the transfer completes, turn a lock back on at the new registrar. Leaving the deadbolt open forever is not a lifestyle; it was a temporary moving-day necessity.

Do not confuse this with:

• Client hold or other statuses that can take the name offline.
• Registry / server transfer prohibited statuses tied to policy windows or registry rules.
• Privacy/proxy contact services (those affect what the public sees; they are not the same as transfer lock).

Approvals and FOA: the “both landlords check the form” stage

ICANN’s Transfer Policy describes a Form of Authorization (FOA) style confirmation flow so transfers are not silent. In plain terms:

1. You unlock and obtain the auth code at the losing registrar.
2. You start the transfer at the gaining registrar and enter the code (and pay if required).
3. Confirmations go out so the authorized contact can approve the move. Historically this involved standardized FOA messages; enforcement details and registrar UX have evolved, and ICANN has at times deferred certain enforcement pieces while policy review continues. What you experience in 2026 may be email links, panel approvals, or both.
4. The losing registrar is notified and has a window to respond. Under the published policy, failure by the registrar of record to respond within five calendar days to the registry’s transfer notification can result in a default approval.
5. When the registry completes the transfer, both registrars get notified, and the gaining registrar becomes registrar of record.

Your part: watch the email addresses on the domain contacts (and your registrar account email). If those mailboxes are dead, full, or filtered into spam, the move stalls even when the auth code was perfect. Fix mailbox access before moving day. Be careful about “fixing” contacts with material registrant changes that may trigger a Change of Registrant lock.

Also plan for duration. Many transfers finish in roughly several days once started; our FAQ gives a typical 5 to 7 day window depending on how quickly the current registrar releases the name. That is a practical range, not a guarantee for every TLD.

What moves with the domain vs what stays behind

This is the part the apartment metaphor exists for.

Usually moves (or is re-pointed with the registration)

• The domain name registration and remaining term (often plus the transfer-related year extension for eligible gTLDs).
• Your role as registrant (the person/organization the registration belongs to), you are changing landlords, not selling the apartment, unless you separately do a Change of Registrant.
• Registry-level nameserver delegation often remains whatever was set, so the internet may keep asking the same DNS hosts, if those hosts still serve your zone.

Usually does not move automatically

• Website files, databases, CMS installs on the old host.
• Email accounts and message history on the old mail platform.
• DNS zone editing if DNS was a free add-on at the old registrar: the records may keep answering for a while, but you can lose the control panel (or the zone entirely) when the old account is closed. Export or recreate the zone before you burn bridges.
• Registrar-specific extras: proprietary site builders, bundled forwarding rules that lived only in the old panel, one-click “email forwarding” that was not real MX hosting, and similar convenience features.
• Account billing history at the old company (keep invoices for your records).

Things people forget until something breaks

• Scheduled renewals / auto-renew at the old registrar, turn them off after a successful transfer so you do not pay for a name you no longer manage there (and confirm auto-renew at the new home).
• DNSSEC state: if the domain was signed, a clumsy cutover can create validation failures. If you use DNSSEC, treat transfer + DNS changes as a coordinated project, not two casual clicks.
• External services that verified the domain via DNS TXT or email (newsletters, SaaS admin panels). The domain still exists; your proof records must still exist too.

DNS and nameserver risks during a transfer

A clean registrar transfer should not require changing nameservers. Many successful moves leave NS records alone: the lease changes hands; the lobby desk keeps working.

Risks appear when people combine moves:

Risk 1: Changing nameservers and registrar on the same day. Now you have two clocks, transfer approval and DNS delegation/cache. If either path is wrong, symptoms look like “the transfer broke my site” when the real issue was an empty new zone or a deleted old zone.

Risk 2: Assuming “DNS at the registrar” travels as a product. Sometimes the gaining registrar will show blank DNS until you recreate records. Sometimes the old registrar’s DNS keeps answering until you change NS or they retire the zone. Verify with lookups from more than one resolver after the transfer completes.

Risk 3: Pointing NS at the new registrar before the zone is ready. Build the zone first. Only then change delegation. That advice is the same whether or not a transfer is happening.

Risk 4: TTL and “propagation” anxiety. If you did not change nameservers, do not expect a global DNS storm from the transfer alone. If you did change nameservers, wait for caches sensibly and keep the old authoritative DNS alive until traffic has moved. Deeper detail lives in the nameservers and propagation guide.

Risk 5: Email. MX records and provider settings are independent of which registrar holds the name. Still, if MX lived only in a DNS panel you are about to lose access to, copy them first. Transfer day is a bad day to discover your mail DNS was a house of cards.

A calm strategy many operators use:

1. Export a full copy of DNS records (screenshot + text export).
2. Confirm website and mail work before starting the transfer.
3. Transfer the domain without changing nameservers.
4. After the gaining registrar shows the domain as active, verify NS and key records still match your notes.
5. Only later, on purpose, migrate DNS or hosting if you still want to.

gTLD vs ccTLD: same idea, different rulebooks

gTLDs (generic top-level domains) such as many .com / .net / new generic endings are generally under ICANN consensus policies, including the Transfer Policy concepts above: AuthInfo, client transfer lock rules, FOA-style confirmations, and the familiar 60-day denial reasons around recent create/transfer (and Change of Registrant locks). For background on how ICANN and IANA fit the wider address book, see ICANN and IANA: the internet’s address book.

ccTLDs (country-code top-level domains) such as .hn, .gt, .uk, and many others are run by national or territorial registries. Some mimic EPP auth-code transfers. Others use emails, signed forms, registrar-to-registrar tickets, or registry portals with local rules. Waiting periods, required documents, trustee/local presence requirements, and whether a transfer includes an extra year can all differ.

High-level habits that still help for ccTLDs:

• Ask both registrars for that TLD’s transfer steps, not a generic .com tutorial.
• Confirm unlock + auth/token requirements for that registry.
• Confirm whether contact updates have special locks.
• Confirm whether DNS must be changed as part of the process (sometimes yes, often no).
• Budget extra calendar time when paperwork or manual review is involved.

We support transfers for gTLDs and many ccTLDs; the client area and support path are still the right place to confirm extension-specific transfer behavior before you unlock anything.

Change of Registrant vs change of registrar (do not mix them up)

Two different moves share the word “transfer” in casual speech:

• Inter-registrar transfer = new landlord (this article).
• Change of Registrant = new tenant name on the lease (material change to registrant identity/contact as defined in policy).

ICANN’s Transfer Policy treats Change of Registrant as its own process with confirmations and, by default, a 60-day inter-registrar transfer lock afterward, with a possible opt-out before the change if the registrar offers it. If your real goal is “move to another registrar,” do the inter-registrar transfer first when that order avoids an avoidable lock, policy text even advises registrants toward that sequencing unless they opted out of the lock.

Selling a domain to someone else may involve both steps eventually. Plan the order; do not invent a custom sequence under time pressure.

A practical checklist you can reuse

Print this, paste it into a ticket, or keep it next to your password manager.

A. A week before (or the day before, if you are disciplined)

• ☐ Confirm the domain is eligible (not inside a create/transfer/Change-of-Registrant lock window for your TLD).
• ☐ Confirm the domain is not expired and billing is clear at the current registrar.
• ☐ Confirm you can log into the current registrar and the gaining registrar.
• ☐ Confirm you can read email for the registrant/admin contacts (and account email).
• ☐ Export DNS records; note current nameservers.
• ☐ Confirm website and email work; take quick screenshots of key panel settings.
• ☐ Decide: transfer only, or transfer + DNS/hosting migration later.
• ☐ If DNSSEC is enabled, read your DNS host’s transfer guidance first.

B. Moving day at the losing registrar

• ☐ Disable registrar / client transfer lock (clientTransferProhibited).
• ☐ Generate or request the auth / EPP / AuthInfo code.
• ☐ Store the code somewhere private and temporary.
• ☐ Do not delete the account, DNS zone, or hosting yet.

C. At the gaining registrar

• ☐ Start the transfer for the correct TLD spelling.
• ☐ Enter the auth code exactly.
• ☐ Complete payment / review the term extension shown at checkout.
• ☐ Watch for confirmation emails or panel approvals; act promptly.
• ☐ Keep an eye on spam folders for a few days.

D. After success

• ☐ Verify the domain appears in the new registrar panel.
• ☐ Re-enable transfer lock at the new registrar.
• ☐ Verify nameservers and critical DNS records still match your export.
• ☐ Set or confirm auto-renew and correct contacts at the new home.
• ☐ Disable auto-renew for that domain at the old registrar (once you are sure the transfer finished).
• ☐ Only then schedule any DNS or hosting migration, as a separate project.
• ☐ Update documentation: where the domain lives now, who pays for it, where DNS is edited.

E. If something sticks

• ☐ Re-check lock status and auth code validity.
• ☐ Re-check 60-day (or TLD-specific) windows.
• ☐ Re-check contact email delivery.
• ☐ Ask the current registrar what reason they would give for a denial.
• ☐ Ask the gaining registrar what their panel shows for the transfer state.
• ☐ Avoid rapid registrant edits “just to try something” without understanding Change of Registrant locks.

Common myths, cleared gently

“Transferring will take my site down.” Not if DNS and hosting stay put. Downtime usually comes from changing or deleting DNS/hosting in parallel, not from the lease paperwork alone.

“I need to point the domain at the new registrar’s nameservers to transfer.” Often false for standard gTLD transfers. Auth code + unlock + approvals are the core. Nameserver changes are optional and separate unless your specific TLD process says otherwise.

“WHOIS privacy prevents transfers.” Not inherently. Privacy/proxy may affect which emails are visible, but registrars still have ways to reach the account holder. Follow your registrar’s transfer instructions for private contacts.

“If I ignore the confirmation emails, nothing happens.” Do not count on that. Policy includes default-approval behavior when the losing registrar does not respond in time, and gaining-side confirmations may still be required depending on implementation. Read the messages; do not ghost your own move.

“All domains follow the same 60-day rules.” Many ICANN gTLDs share the familiar create/transfer/Change-of-Registrant themes in the Transfer Policy. ccTLDs and some special cases differ. Policy reviews can also change future requirements; always verify current rules for your name.

Soft landing: choosing where the lease lives

People transfer registrars for ordinary reasons: clearer pricing, better DNS tools, support in their language, consolidating a portfolio, or leaving a panel they have outgrown. Whatever the reason, the technical move is the same: eligibility, unlock, auth code, confirmations, verify DNS, re-lock.

If you are consolidating names, including regional and international extensions, into one place to renew and manage DNS, a registrar built around straightforward domain management (such as SoxDomains) is the kind of “new landlord” the checklist above is written for. Use the FAQ for transfer basics, then treat this article as the longer moving-day briefing.

Closing: pack the paperwork, leave the furniture until you mean to

Domain transfers feel scary because the domain is the front door of the business. The fear shrinks when you separate lease paperwork from furniture. Get eligibility right. Unlock on purpose. Guard the auth code like a key. Answer confirmations. Leave DNS alone unless you have a second plan. Re-lock when you arrive. Migrate hosting and mail later, with their own checklist.

That is the whole apartment move: change landlords without throwing your couch out the window.

When you are ready, run the checklist once with a low-stakes domain if you have one, or go slowly on the production name with DNS exported and mailboxes open. Future you will be grateful you treated transfer day like a planned move, not a surprise eviction.