Transferring a domain to a new registrar does not have to interrupt your website or email. This guide provides a practical domain transfer checklist covering preparation, registrar lock, authorization codes, DNS and email continuity, verification, rollback planning, and the recurring checks that help prevent future ownership or renewal problems.
Overview
A domain transfer moves management of a domain name from one registrar to another. It is different from moving the website itself to a new hosting provider. A registrar controls the domain registration, renewal, contact details, transfer settings, and often the DNS management interface. Your website files, database, mailboxes, and hosting account may remain exactly where they are.
That distinction is central to transferring a domain without downtime. In many setups, a registrar transfer does not change the domain’s nameservers or DNS records. If the existing DNS zone remains active and the records are not modified, visitors and mail systems can continue using the same destinations while the transfer is processed. However, DNS arrangements differ, and an unmanaged transfer can still expose gaps if records exist only inside the old registrar account.
Before starting, identify which provider currently manages each part of the setup:
- Registrar: the company holding the domain registration.
- DNS provider: the service answering queries for records such as A, AAAA, CNAME, MX, TXT, and CAA.
- Hosting provider: the service running the website, application, or server.
- Email provider: the service handling mailboxes and delivery.
If you are also moving the website, treat that as a separate migration project. The cloud hosting migration checklist for WordPress and business websites can help you plan the hosting side without confusing it with the registrar transfer.
What to track
1. Transfer eligibility and account access
Confirm that you can sign in to the current registrar and access the administrative contact email associated with the domain. Review the domain’s status, expiration date, ownership information, and transfer settings. Registrars and domain extensions can apply different eligibility rules, including restrictions related to recent registration, previous transfers, or changes to registrant information. Check the current registrar’s instructions rather than assuming every domain follows the same process.
Make sure the domain is not subject to a legal, payment, or account dispute. Resolve any issue before beginning. Also verify that the destination registrar supports the domain extension and that you understand whether the transfer process includes a renewal or creates a separate renewal charge.
2. Registrar lock and authorization code
Most domains have a transfer lock that prevents unauthorized moves. The current registrar may label it as registrar lock, transfer lock, or a similar setting. Record its current state, disable it only when you are ready to submit the transfer, and re-enable it if the transfer is cancelled or postponed.
You will usually need a domain transfer authorization code, sometimes called an EPP code or transfer code. Request it through the current registrar’s control panel or support process. Treat the code like a credential: share it only with the intended destination registrar, do not publish it in a ticket or public document, and request a new code if you believe it has been exposed.
3. DNS records and nameservers
Export or document the complete DNS zone before making changes. At minimum, record:
- A and AAAA records for the website or server
- CNAME records for subdomains and hosted services
- MX records for email delivery
- TXT records for SPF, DKIM, DMARC, verification, and security services
- CAA records, if used to control certificate issuance
- Nameservers, TTL values, redirects, and any DNS-specific forwarding settings
A DNS zone export is useful, but also keep a readable copy because some providers use different import formats. The managed DNS setup guide explains how these records fit together and what to review when changing DNS providers.
4. Email continuity
Do not assume that email is protected merely because the website loads. Check the MX records and document the email provider’s required SPF, DKIM, and DMARC records. If mailboxes are hosted with the old registrar or a related service, confirm whether they will remain active after the domain transfer and whether billing or account ownership must be handled separately.
Before starting, send and receive test messages using more than one mailbox if possible. Keep copies of important messages and confirm who controls the administrative email used for transfer notifications. Never change MX records as part of the registrar transfer unless you are deliberately moving email.
5. Monitoring and recovery access
List the people who can approve, cancel, or troubleshoot the transfer. Confirm access to the old registrar, new registrar, DNS provider, hosting control panel, and email administration account. Arrange basic monitoring for the website and email, and retain a backup of the website and database if a hosting move is happening at the same time.
Cadence and checkpoints
Use this sequence to transfer the domain in a controlled way:
- Several days before submission: map the registrar, DNS, hosting, and email relationships. Export DNS records, verify account access, and note renewal and expiration information.
- Immediately before submission: confirm the administrative email, unlock the domain if required, obtain the authorization code, and verify that the destination registrar accepts the domain extension.
- At submission: enter the domain and authorization code carefully. Check the destination account for spelling, ownership details, renewal settings, and DNS configuration. Do not change nameservers unless you have prepared and tested the replacement DNS zone.
- While pending: monitor transfer messages, the domain status, website availability, and email delivery. Do not make unrelated DNS or hosting changes during this window unless they are urgent and documented.
- After completion: sign in to the new registrar, confirm that the domain is present, review lock status and renewal settings, and verify the nameservers and DNS records. Test the root domain, common subdomains, HTTPS, inbound email, outbound email, and any essential verification records.
- After stabilization: remove unnecessary access at the old registrar, store the new account and recovery details securely, and update internal documentation.
Transfer timing varies by registrar, domain extension, approval method, and account status. Use the status shown by the providers as the source of truth instead of planning around a fixed timeline. If a confirmation email arrives, inspect its destination and instructions carefully before approving or cancelling anything.
How to interpret changes
A successful registrar transfer should leave the website and email destinations unchanged. If the website stops loading, compare the active nameservers and A or AAAA records with your documented baseline. If only a subdomain fails, inspect its CNAME or individual address record rather than changing the entire zone.
If inbound email fails, compare the MX records first. If messages are accepted but authentication warnings appear, review SPF, DKIM, and DMARC records. A registrar transfer does not normally require new email authentication records, so an unexpected change often indicates that the DNS zone was replaced, incompletely copied, or moved to a different DNS provider.
Changes can also be caused by cached DNS answers. Check the authoritative nameservers and records, then allow for normal resolver caching before concluding that every user is affected. Do not repeatedly edit records without recording each change; that can make diagnosis harder.
If the transfer is rejected, review the stated reason rather than repeatedly resubmitting it. Common areas to investigate include a still-locked domain, an incorrect or expired authorization code, an inaccessible approval email, an eligibility restriction, or a mismatch in account information. Policy details differ by registrar and domain extension, so follow the applicable provider’s documented resolution path.
For rollback, preserve the original DNS provider and hosting account until the new setup has been verified. If the domain transfer itself cannot be reversed immediately, keep DNS pointed at the known-good service and use the new registrar’s support process. If nameservers were changed and the new zone is faulty, restore the documented original nameservers only when you are certain the old DNS zone is still active.
When to revisit
Review the domain transfer record monthly or quarterly, and revisit it immediately after an ownership change, website migration, email-provider change, DNS redesign, or registrar account change. The goal is not to repeat the transfer; it is to keep the conditions that make a future transfer safe and recoverable.
At each review, check the following:
- Domain expiration and auto-renewal settings
- Registrar lock and account recovery methods
- Administrative contact details and approval email access
- Current nameservers and the location of the authoritative DNS zone
- Website, email, certificate, and DNS monitoring
- Recent backups and the location of the DNS export
- Whether former staff, vendors, or old systems still have account access
Update this article’s checklist or your internal runbook when your registrar changes its transfer workflow, pricing presentation, approval process, security requirements, or domain-extension support. Also refresh it when your DNS, hosting, or email architecture changes. For related setup work, see the guide on registering a domain and connecting it to cloud hosting and the instructions for pointing a domain to web hosting.
The practical rule is simple: document the working DNS and email configuration before the transfer, change one control plane at a time, verify every dependency afterward, and retain a recovery path until the new registrar and DNS arrangement have proved stable.
