A domain transfer is the process of moving a domain name registration from one domain registrar to another, changing the company responsible for managing the domain’s registration records, renewal billing, and registrant account while keeping the domain name itself unchanged. The domain name, example.com: remains the same. The registrant, the owner, remains the same. Only the registrar of record changes.

Domain transfers happen for several reasons, dissatisfaction with the current registrar’s pricing, features, or support; consolidating a portfolio of domains across multiple registrars into one account; switching to a registrar with better security features; or as part of a domain acquisition where the seller’s registrar differs from the buyer’s preferred registrar. Whatever the reason the transfer process follows a standardised procedure defined by ICANN, the Internet Corporation for Assigned Names and Numbers, that applies across all accredited registrars.

A domain transfer is distinct from a domain migration: which refers to moving a website from one domain name to another. A transfer keeps the same domain name but moves the registrar. A migration keeps the same registrar but changes the domain name. Both are common domain management operations but they address completely different situations.

How domain transfers work

The domain transfer process follows a standardised procedure defined by ICANN’s Inter-Registrar Transfer Policy, ensuring consistency across the hundreds of accredited registrars worldwide. The process involves several steps and takes a minimum of five days to complete for most gTLD domains.

Step 1, verify transfer eligibility: before initiating a transfer several conditions must be met. The domain must be at least 60 days old from initial registration or the most recent transfer, ICANN’s 60-day lock policy prevents rapid-fire transfers that could facilitate fraud. The domain must not have a transfer lock applied by the current registrar, the registrar lock or clientTransferProhibited status must be removed by the current registrar before the transfer can proceed. The domain must not be expired or in redemption status.

Step 2, obtain the authorisation code: the domain owner requests an authorisation code, also called an EPP code, auth code, or transfer key, from the current registrar. This code is a unique string that authenticates the transfer request, proving the person initiating the transfer has legitimate access to the domain. Registrars are required by ICANN to provide auth codes to registrants upon request within five days. Some registrars provide the code instantly through their control panel. Others require a support request and manual processing.

Step 3, initiate the transfer at the gaining registrar: the domain owner submits a transfer request at the new registrar, the gaining registrar, providing the domain name and the authorisation code. The gaining registrar verifies the auth code against the current registrar’s records through the EPP protocol.

Step 4, transfer approval: the current registrar, the losing registrar, receives notification of the transfer request. Under ICANN policy the losing registrar has five days to approve or reject the transfer. Transfers are automatically approved if the losing registrar does not explicitly reject them within the five-day window, silence means consent. The losing registrar can reject a transfer only for legitimate reasons, invalid auth code, existing transfer lock, domain in redemption status. They cannot reject a legitimate transfer simply because they want to keep the domain.

Step 5, transfer completion: once approved the transfer completes and the domain moves to the gaining registrar’s system. The gaining registrar becomes the registrar of record. The domain’s registration is renewed for one year as part of the transfer, ICANN requires gaining registrars to add one year to the domain’s registration period as part of the transfer process. The total registration period cannot exceed ten years.

Timeline: the entire process takes a minimum of five days from initiation to completion for most gTLD domains. Many transfers complete faster, within one to two days, if the losing registrar approves promptly rather than waiting for the five-day window. Some registrars have expedited transfer processes that complete within hours.

Transfer locks

Transfer locks are security mechanisms that prevent unauthorised domain transfers, protecting domain owners from having their domains moved to other registrars without their knowledge or consent.

Registrar lock, clientTransferProhibited: the standard transfer lock applied by registrars. When this status is active the registrar will not process outbound transfer requests for the domain. The domain owner must log into their registrar account and explicitly remove the lock before a transfer can be initiated. Most reputable registrars apply this lock by default and recommend keeping it active unless a transfer is being initiated.

Registry lock, serverTransferProhibited: a stronger lock applied at the registry level by the TLD registry operator rather than by the registrar. Registry locks require additional verification steps, typically involving the registry operator directly rather than just the registrar, before they can be removed. Registry locks are available for high-value domains through premium registrar services and provide significantly stronger protection against DNS hijacking and domain theft. Changes to a registry-locked domain require manual verification processes that are difficult for attackers to circumvent even if they compromise the registrar account.

60-day lock: ICANN requires all domains to be locked for 60 days following a transfer, the transferProhibited status is automatically applied for 60 days after a transfer completes. This prevents rapid successive transfers that could be used to obscure the domain’s trail during fraudulent activity. The 60-day lock also applies for 60 days after initial registration.

Removing locks for legitimate transfers: when initiating a legitimate outbound transfer the domain owner logs into their registrar account and removes the registrar lock. Most registrars provide a straightforward interface for this. The lock must be removed before requesting the auth code and before the gaining registrar initiates the transfer. After the transfer completes the gaining registrar typically applies a new lock, and the 60-day lock is applied automatically.

Transfer costs

Domain transfers involve specific cost considerations that differ from standard registration and renewal fees.

One-year renewal included: ICANN requires that all gTLD domain transfers include a one-year renewal, the gaining registrar adds one year to the domain’s existing registration period as part of the transfer. The cost of this renewal is typically included in the transfer fee charged by the gaining registrar. The transfer effectively prepays one year of renewal at the gaining registrar’s renewal rate.

Transfer fees: gaining registrars typically charge a transfer fee that covers the mandatory one-year renewal. Transfer fees vary by TLD and registrar, for .com domains common transfer fees range from $8 to $20 depending on the registrar. Some registrars charge higher transfer fees, particularly for certain TLDs or when transferring domains with premium pricing. Cloudflare Registrar is notable for charging at-cost transfer prices, no markup above the registry’s wholesale rate.

Registry lock and redemption fees: domains in redemption status cannot be transferred, they must be recovered through the redemption process at additional cost before a transfer can be initiated. Premium domain status may carry elevated transfer fees that match the elevated registration and renewal fees.

Free transfer promotions: some registrars offer promotional free transfers, waiving the transfer fee to attract new customers. These promotions still include the mandatory one-year renewal, the registrar absorbs that cost as a customer acquisition expense. Free transfer promotions can make switching registrars economically attractive.

Domain transfers and DNS

A domain transfer moves the registration to a new registrar but does not automatically change the domain’s DNS configuration. Understanding this distinction prevents common DNS-related problems during transfers.

DNS is independent of the registrar: a domain’s DNS zone: the collection of DNS records that define where the domain’s traffic goes, is hosted on nameservers. These nameservers may be the registrar’s nameservers, a separate DNS provider’s nameservers, or custom nameservers. The registrar stores the domain registration record and maintains the nameserver assignment, the NS records that tell the DNS system which servers are authoritative for the domain. The nameservers themselves hold the actual DNS records.

Nameservers transfer with the domain: when a domain transfers to a new registrar the nameserver assignment transfers with it. If the domain was using ns1.currentregistrar.com and ns2.currentregistrar.com as nameservers before the transfer those nameservers remain assigned after the transfer, unless the gaining registrar or the domain owner changes them.

This means DNS continues to function without interruption during and after the transfer, the nameservers and their DNS records are unchanged by the transfer itself. A website hosted at the domain continues to be accessible. Email continues to be delivered. Redirect rules configured through the domain’s DNS continue to function.

The nameserver continuity risk: the one scenario where DNS can be disrupted during a transfer is when the domain was using the current registrar’s own nameservers for DNS. If the gaining registrar does not support importing those records or if the DNS zone at the old registrar is deleted when the domain transfers DNS records may be lost.

Best practice is to migrate DNS to a dedicated DNS provider, Cloudflare, Route 53, Google Cloud DNS, before initiating the transfer. With DNS on a separate provider independent of either registrar the transfer has no effect on DNS continuity.

DNS migration before transfer: for domains using registrar-provided DNS the recommended approach is to migrate DNS to an independent provider first, adding all existing DNS records at the new provider and changing the nameserver assignment to point to the new provider’s nameservers. After DNS is stable on the independent provider initiate the registrar transfer. The transfer then has no DNS implications, nameservers and their records are unchanged.

Domain transfers and redirect management

Domain transfers affect redirect management configurations in ways that depend on where the redirect infrastructure is hosted relative to the registrar.

Registrar-hosted forwarding breaks on transfer: if domain forwarding is configured through the current registrar’s forwarding service, entering a destination URL in the registrar’s forwarding control panel, that forwarding configuration does not transfer to the new registrar. The forwarding is a service of the current registrar, not a portable DNS configuration. After the transfer the domain no longer has forwarding configured and visitors receive errors rather than being redirected.

The solution is to migrate from registrar-based forwarding to DNS-based redirect management before initiating the transfer. Connecting the domain to a dedicated redirect management platform, through DNS record changes, establishes a redirect configuration that is independent of the registrar and transfers seamlessly with the domain.

DNS-based redirects survive transfers: redirect configurations implemented through DNS records, A records pointing to redirect management infrastructure, CNAME records for subdomains pointing to the redirect service, survive domain transfers without any disruption. The DNS records are hosted on nameservers that are unaffected by the registrar change. All redirect rules configured through the redirect management platform continue functioning exactly as before.

This is one of the key advantages of dedicated redirect management platforms over registrar-based forwarding, independence from the registrar means redirect configurations are portable and survive registrar changes, nameserver changes, and all other administrative changes.

Transfer and SSL certificates: SSL certificates for redirect infrastructure are not affected by domain transfers. Certificates are issued for domain names, not registrar accounts. A certificate provisioned for example.com by the redirect management platform continues to be valid regardless of which registrar holds the domain’s registration.

ccTLD transfer considerations

Domain transfers for country code TLDs, ccTLDs, follow different procedures than gTLD transfers because ccTLDs are managed by national registries that each set their own transfer policies.

Different policies per ccTLD: each ccTLD registry defines its own transfer process. Some ccTLDs follow procedures similar to gTLD transfers. Others require entirely different processes, fax-based authorisation, notarised documentation, in-person verification, or other requirements reflecting the national registry’s preferences and legal requirements. Understanding the specific ccTLD transfer procedure before initiating is essential.

Some ccTLDs prohibit or restrict transfers: certain ccTLD registries do not permit transfers between registrars in the standard sense, the domain must be registered through accredited local registrars and may not be transferable to international registrars. Other ccTLDs require the registrant to meet local presence requirements, if the acquiring registrant does not meet the requirements the transfer may not be permitted.

Alternative to transfer, change of registrant: for ccTLDs with restrictive transfer policies the practical alternative is a change of registrant, updating the registrant contact information in the WHOIS record to reflect the new owner, rather than a technical transfer between registrars. The registrar remains the same while the registrant changes. This approach works for domain acquisition scenarios but does not address the goal of consolidating domains at a preferred registrar.

Preparing for a domain transfer

Successful domain transfers require preparation to avoid disruption and ensure all configurations survive the transfer.

Audit current DNS configuration: document all DNS records currently associated with the domain, every A record, AAAA record, CNAME record, MX record, TXT record, NS record, and any other record types. This documentation ensures DNS records can be recreated accurately at the new provider if needed.

Migrate DNS to independent provider if using registrar DNS: as described above this is the most important preparation step for domains using registrar-provided DNS. Migrating DNS before the transfer ensures continuity regardless of what happens to the old registrar’s DNS service for the domain.

Verify registrar contact information: transfer-related notifications, auth codes, approval requests, are sent to the registrant contact email on file. Ensure this email address is current and accessible before initiating the transfer.

Check and remove transfer lock: verify the transfer lock status in the current registrar’s control panel. Remove the lock before requesting the auth code.

Check domain expiry date: transfers add one year of renewal. If the domain expires in less than one year the transfer extends it. If the domain expires in more than one year the transfer still adds exactly one year, a domain expiring in two years that transfers will expire in three years after the transfer. Timing the transfer relative to the renewal date affects the total cost and extension period.

Allow adequate time: initiate transfers well before any critical dates, domain expiry, planned website launches, campaign go-live dates. The transfer process takes five or more days and unexpected complications, incorrect auth codes, registrar delays, WHOIS inaccuracies, can extend the timeline.