Article image
How to Transfer a Domain Name from an Agency to a Client (Step-by-Step)
Managing digital assets is one of the most common administrative headaches in web design and development. Whenever a project wraps up, or a client decides to bring domain management in-house, someone has to hand over the keys cleanly. Get it wrong and you risk website downtime, lost email, or even losing the domain to a squatter during the handoff window.
This guide walks through the full transfer process, the ICANN rules that govern it, and what's changed recently — including a couple of policy shifts that most older guides on this topic haven't caught up with yet.
- Understanding the Anatomy of a Domain Transfer Before getting into the steps, it's worth clarifying what "transferring a domain" actually means, because the phrase covers two different actions:
Inter-Registrar Transfer (moving to a new registrar): The agency holds the domain at Registrar A (say, GoDaddy), and the client wants it managed at Registrar B (say, Namecheap or Cloudflare). This moves both technical and billing control between two competing companies and is tightly regulated by ICANN.
Change of Registrant (account push): Agency and client use the same registrar. The agency simply pushes the domain from its account to the client's account. Ownership details change, but the domain stays with the same registrar.
This guide focuses mainly on the inter-registrar transfer, since it's the more complex of the two and the one with real regulatory teeth.
- ICANN Policy Updates You Need to Know (2024–2026) ICANN's rules around domain ownership and transfers have gone through real changes in the last two years. Here's what's actually in effect right now, and what's still on the way.
The "Organization" field now determines legal ownership
This is no longer an upcoming change — it's active. Under ICANN's Registration Data Policy, which took full effect on August 21, 2025, if the Organization field in a domain's registrant contact details contains a company name, that organization is considered the legal owner (the "Registered Name Holder") of the domain — overriding whatever individual name appears in the First/Last Name fields.
Agency takeaway: if you registered a domain on a client's behalf and put your own agency name in the Organization field, your agency is the legal owner of record, not the client — regardless of what your contract says. That's a real liability if a dispute ever comes up. Check the Organization field on every client domain you manage: it should contain the client's legal business name, or be left blank if the domain is meant to be owned by an individual.
As part of the same policy, registrars now collect and retain a much smaller set of contact data (often just the Registrant contact), and ICANN's WHOIS lookup system has been superseded by RDAP (Registration Data Access Protocol) as the standard way to query registration data.
EPP codes are being replaced by Transfer Authorization Codes (TAC)
This is the update most existing guides miss. Under the ICANN Transfer Policy that took effect November 19, 2024, the old-style EPP/auth code — a static password that could sit unchanged in a registrar dashboard for years — is being phased out in favor of a Transfer Authorization Code (TAC).
Key differences:
A TAC is generated on demand, not stored indefinitely. You request it right before you need it.
It has a capped lifespan — typically up to 14 days — and is stored by the registry only as a one-way hash.
It's meant for a single transfer and expires automatically once used or once the window closes.
Functionally, a TAC does the same job an EPP code always did: it proves to the new registrar that the transfer is authorized. The practical takeaway for agencies is timing — don't generate the code weeks in advance the way you might have with an old EPP code. Generate it only once the client is ready to enter it at the new registrar, or it may expire before they get to use it. Many registrar dashboards still label the field "EPP code" or "Auth code" out of habit, so don't be thrown if you see the old terminology.
The 60-day lock rule is still active — but change is coming
The rule agencies have worked around for years is still in force: you generally cannot transfer a domain if:
It was registered less than 60 days ago.
It was transferred to a new registrar less than 60 days ago.
The registrant's contact info (Name, Organization, or Email) was changed in the last 60 days — unless the registrar offers an opt-out and you use it before making the change.
What's new: in early 2025, ICANN's GNSO Council voted (at the ICANN 82 meeting) to eliminate the 60-day Change-of-Registrant lock entirely and replace it with a shorter, mandatory 30-day (720-hour) lock applied uniformly to new registrations and post-transfer domains. This has been approved at the policy level, but as of mid-2026 it has not yet been implemented — registrars are still expected to need time to roll it out, and estimates at the time of approval put full implementation at least 18 months out. In practice, treat the 60-day rule as still binding today, but keep an eye on registrar announcements over the next year, since the shorter window is coming.
-
Pre-Transfer Checklist: Preparing for the Handoff
For the Agency (the releasing party)
Audit the contract. Confirm invoices are settled before releasing the domain, but don't hold it hostage if the contract already specifies client ownership.
Check expiration dates. Domains within about 7 days of expiration, or already expired, generally can't be transferred. Renew first if needed (and bill the client), so the domain doesn't lapse mid-transfer.
Confirm the administrative/registrant email is accessible. Transfer confirmations go here, and a dead inbox is one of the most common reasons transfers stall or fail.
For the Client (the receiving party)
Choose a registrar — Namecheap, Cloudflare Registrar, Squarespace Domains (which absorbed Google Domains in 2023), GoDaddy, and others are all common choices.Set up a payment method. The receiving registrar will charge a transfer fee, and for most gTLDs (.com, .net, .org) that fee bundles in a mandatory one-year extension of the registration — though this is capped at a 10-year total term, and some country-code domains (like .uk or .lt) don't add a year at all, since they follow their own registry rules rather than ICANN's.
Step-by-Step: How to Transfer a Domain from an Agency to a Client
Phase 1: The Agency's Responsibilities
Step 1 — Update the contact information. Log into the registrar dashboard and update the Registrant and Administrative contact to the client's details. If the registrar offers an "opt out of the 60-day lock" option, select it before saving — otherwise this change alone will re-trigger the lock.
Step 2 — Remove domain privacy (WHOIS/RDAP protection). The gaining registrar needs to verify the owner's identity during the transfer, so temporarily disable privacy protection.
Step 3 — Unlock the domain. Registrars apply a "Registrar Lock" (technically clientTransferProhibited) by default to prevent unauthorized transfers. Find the domain lock setting and toggle it off.
Step 4 — Generate the authorization code. Request the transfer/auth code — you may see it called an EPP code, Auth-Info code, or Transfer Authorization Code (TAC) depending on the registrar. If it's issued as a TAC, remember it may expire in as little as 14 days, so generate it close to when the client will actually use it, and send it to them securely.
Phase 2: The Client's Responsibilities
Step 5 — Initiate the transfer at the new registrar. The client enters the domain name in their new registrar's "Transfer Domain" tool, which checks that the domain is unlocked and eligible.
Step 6 — Enter the authorization code. The client pastes in the code the agency provided.
Step 7 — Pay the transfer fee. For most gTLDs, this includes the one-year extension mentioned above.
Step 8 — Approve the confirmation emails. The gaining registrar emails the client to confirm the transfer request; the losing registrar emails the agency (or updated admin contact) that a transfer has been requested. Agencies can often speed this up by manually approving the release from their dashboard's "Pending Transfers" menu — this can bring completion time down to well under a day at some registrars. If nobody acts, the transfer typically auto-completes after 5 to 7 days, per ICANN policy.
- Alternative Method: The "Account Push" (Internal Transfer) If EPP/TAC codes and multi-day waits feel like overkill, an internal account push is the faster route — provided agency and client are willing to use the same registrar.
Pros:
Fast — completes in minutes rather than days.
No ICANN transfer fee or mandatory one-year renewal.
Bypasses the 60-day lock — pushes aren't inter-registrar transfers, so the lock doesn't apply.
Cons:
The client is stuck using the agency's registrar of choice, at least initially.
It doesn't decouple technical infrastructure if the agency was relying on registrar-specific nameservers.
- What to Expect During the Process Will the site go offline? No — a domain transfer doesn't touch DNS records or nameservers by default. The domain just changes which dashboard manages it; routing stays the same. The one exception: if the agency was using the losing registrar's default nameservers and those get torn down on exit, DNS can break. Migrating to a neutral DNS provider (like Cloudflare) before the transfer avoids this entirely.
How long does it take? If the agency approves manually, transfers can complete in well under a day at many registrars. Left untouched, ICANN policy allows the transfer to sit pending for 5 to 7 days before it auto-completes.
- Operational Best Practices for Agencies
Adopt a "client-owned, agency-managed" policy. The cleanest way to avoid transfer headaches altogether is to never own the client's domain in the first place. Have the client register it under their own name and card, then grant the agency delegated access or add them as a collaborator. This removes the agency's legal exposure entirely — and sidesteps the Organization-field ownership question described above.
Spell out ownership in the contract. A standard clause: "Upon final payment, the Client assumes 100% legal ownership of the domain name. The Agency agrees to initiate a domain transfer or account push within 5 business days of the Client's written request."
Track your assets before, during, and after handoffs. Spreadsheets get unwieldy fast once you're managing dozens of client properties. Keeping a clear log of who legally owns each asset versus who's paying for renewal — including 60-day lock expiry dates and Organization-field settings — saves a lot of pain when it's time to hand something over.
- Conclusion Transferring a domain from agency to client comes down to a handful of moving parts: unlocking the domain, generating the right code (EPP or TAC, depending on your registrar), respecting the 60-day lock while it's still in force, and getting the client's confirmation emails handled promptly. The policy landscape has shifted meaningfully since 2024 — the Organization field now legally determines ownership, auth codes are moving to a short-lived TAC model, and the 60-day lock itself is slated for replacement, even if that hasn't landed yet. Staying current on these details, and keeping your client contracts and domain records clean, is what keeps a routine handoff from turning into a legal headache.
Top comments (0)