A poorly prepared domain name transfer results in lost emails, an inaccessible site, or a domain stuck in pendingTransfer status for days. The procedure itself is simple on paper: unlock, retrieve the EPP code, validate with the new registrar. The problem lies in the technical details that most guides gloss over, particularly the management of the DNS zone during the switch and the specifics related to country code extensions.
DNS Zone and Records to Back Up Before Domain Transfer
The transfer moves the administrative control of the domain, not the DNS zone itself. We regularly observe losses of MX or TXT records after migration because the zone hosted by the old registrar has not been duplicated at the new one before the switch.
Recommended read : Essential Steps to Connect a New Agent to the City of Marseille
Before any manipulation, export your entire DNS zone. Check each type of record: A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), and any SRV records. If your domain uses DNSSEC, disable it before initiating the transfer: an orphan DS record at the registry causes failed resolutions until the new registrar has republished its own keys.
Recreate all these records at the new provider or on a third-party DNS service (Cloudflare, Route 53) before triggering the transfer. Once the zone is ready on both sides, the administrative switch no longer impacts resolution. If you’re looking for how to transfer a domain name with Fireblog, you will find this DNS preparation logic applied step by step.
You may also like : Discover unique activities to try for an exciting free time
EPP Code, Unlocking, and WHOIS Protection: Technical Prerequisites for Transfer
Three locks block a transfer if you do not lift them in the correct order.
- The clientTransferProhibited status (or registrar lock) must be removed from the interface of your current registrar. As long as it is active, any transfer request is automatically denied by the registry.
- The EPP authorization code (or Auth-Code) is a one-time password linked to the domain. Its validity period varies by registrar, sometimes only a few days. Retrieve it when you are ready to initiate the procedure, not in advance.
- WHOIS privacy protection must be temporarily disabled. Several registrars mask the email address of the holder behind a proxy. The transfer validation email is sent to the WHOIS address: if it points to a privacy service that filters or redirects poorly, validation fails silently.
We recommend checking the public WHOIS of the domain after disabling the protection to confirm that the displayed email address is indeed the one you are checking. A validation email not received is the primary cause of aborted transfers.
The Sixty-Day Lock After WHOIS Change
The ICANN policy imposes a sixty-day lock after any change of holder on gTLDs (.com, .net, .org). If you have recently changed the name or email of the holder in WHOIS, the transfer will be denied during this period. Plan your contact updates well before migration, or make them afterward.
Domain Transfer by Extension: gTLD, ccTLD, and Special Cases
General articles describe a universal process. In practice, each type of extension follows its own transfer rules.
For gTLDs (.com, .net, .org), the process is standardized by ICANN: EPP code, request at the new registrar, confirmation email, then a delay of five to seven days during which the old registrar can approve or let the request expire. Explicit approval from the old registrar speeds up the procedure.
ccTLDs (country code extensions) follow different rules. The .fr, managed by AFNIC, uses an authorization code similar to the EPP code, but the procedure for changing the registrar goes through an Afnic Operation Request (DOA). The .uk operates with a tag system: you ask your current registrar to change the IPS tag to the new provider, without an EPP code. The .de (DENIC) requires an Auth-Code but with a distinct validation process.
These differences have a direct impact on timelines. A .com transfer generally takes less than a week. A ccTLD may require several weeks if identity or residency documents are required by the national authority.
Emails and SSL Certificate After the Switch
The domain transfer does not transfer your web hosting or your email. If your MX records pointed to the servers of the old registrar, your emails will stop working as soon as the DNS zone is modified. Ensure that the MX records point to your actual email provider (Google Workspace, Microsoft 365, dedicated server) and not to a service related to the outgoing registrar.
On the SSL side, a Let’s Encrypt certificate renews automatically if the DNS or HTTP validation is still functional. A paid certificate linked to the old host will need to be reissued or transferred. Check the expiration date and validation method before the transfer to avoid switching to unsecured HTTP.
Post-Transfer Domain Name Verification Checklist
Once the domain is displayed at the new registrar, the work is not finished. We find that most incidents occur within forty-eight hours after the switch, when no one checks anything anymore.
- Compare the active DNS zone with your initial backup. Each A, MX, CNAME, and TXT record must match exactly.
- Send a test email to and from each address linked to the domain to confirm the proper functioning of the MX records.
- Check the DNSSEC resolution if you have reactivated it: a tool like DNSViz can help identify a broken chain of trust.
- Reactivate the domain lock (clientTransferProhibited) and WHOIS protection at the new registrar.
- Ensure that the SSL certificate is valid and that your site responds well in HTTPS without certificate errors.
The transfer of a domain name remains an administrative operation, not strictly technical. What causes outages is the lack of DNS preparation beforehand and the forgetting of checks afterward. Prepare the zone beforehand, check everything afterward: between the two, the transfer itself takes only a few clicks.