Domain Transfer Checklist: Move Your Domain Without Downtime or Email Breakage

Overview

If you only remember one thing, remember this: a domain transfer is not the same as changing hosting. In most cases, you are moving registrar control of the domain name, not moving the website itself. That distinction is what prevents unnecessary downtime.

A typical domain transfer involves unlocking the domain at the current registrar, requesting an authorization code, starting the transfer at the new registrar, approving the request through email or account prompts, and then reviewing DNS and contact settings after completion. Source material used for this guide notes several common prerequisites: the domain should usually be older than 60 days, not expired or in redemption, and not blocked by registrar or transfer lock. It also notes that recent contact changes can trigger a transfer restriction, so timing matters.

Before you start, make sure you know which of these situations applies to you:

• You are moving the domain registration only and keeping the same hosting and DNS.
• You are moving the domain registration and changing DNS providers.
• You are moving the domain registration while using third-party email such as Microsoft 365 or Google Workspace.
• You are transferring a domain close to expiration.
• You are moving a production site where even brief email or web disruption matters.

The safest evergreen rule is simple: stabilize DNS first, transfer registrar second, and only then make optional cleanup changes. Bundling all changes into one maintenance window is how avoidable outages happen.

Core pre-transfer checklist

• Confirm the domain is eligible for transfer and older than any recent lock window.
• Check domain status in the registrar panel. Active or OK is generally what you want to see.
• Verify you can log in to the current registrar account.
• Verify you can access the registrant or admin email that receives approval messages.
• Export or copy all DNS records, including A, AAAA, CNAME, MX, TXT, SRV, and any custom records.
• Record current nameservers and note whether DNS is hosted at the registrar or elsewhere.
• Check email dependencies such as MX, SPF, DKIM, and DMARC records.
• Unlock the domain.
• Request the authorization or EPP code.
• Start the transfer at the new registrar and monitor for approval steps.

Checklist by scenario

This section breaks the process into common real-world cases so you can use only the steps that apply to your setup.

Scenario 1: Move domain registrar, keep the same website hosting and DNS

This is the lowest-risk transfer because your website and DNS routing do not need to change.

1. Open your DNS zone and document every record before touching the transfer.
2. Confirm your nameservers point to the existing DNS provider you want to keep.
3. Leave nameservers unchanged during the transfer.
4. Unlock the domain at the current registrar.
5. Obtain the EPP code.
6. Initiate the transfer at the new registrar.
7. Approve any confirmation emails or account notices quickly.
8. After completion, verify the nameservers are still the same and the domain resolved as expected.

Because the DNS host does not change, the website should continue working normally. This is the cleanest path to a domain transfer without downtime.

Scenario 2: Move domain registrar and switch DNS hosting

This is where most avoidable outages happen. The registrar transfer itself may be smooth, but the DNS handoff can break site resolution, mail delivery, or verification records if the new zone is incomplete.

1. Before transfer, recreate the full DNS zone at the new DNS provider.
2. Copy every record, not just the web records. That means MX, TXT, DKIM selectors, verification records, CAA, subdomain entries, and any service-specific records.
3. Review TTL values if your provider allows it. Lower TTLs can make later DNS changes less sticky, but plan them before the cutover, not during a crisis.
4. Test the new zone carefully.
5. Only after the new zone is complete should you consider changing nameservers.
6. If possible, separate the registrar transfer from the nameserver change by at least one working day so troubleshooting stays simpler.
7. After nameserver changes, monitor the website, login flows, API endpoints, and email delivery.

If you want the safest path, do not change nameservers on the same day you initiate the registrar transfer unless there is a strong reason. One change at a time is slower, but it is much easier to verify.

Scenario 3: Transfer a domain that handles business email

Email breakage is often more costly than temporary website issues, especially for small businesses, SaaS products, and client-facing operations.

1. Audit all mail-related records before transfer: MX, SPF, DKIM, and DMARC.
2. Check for provider-specific TXT records used by Microsoft 365, Google Workspace, or transactional mail services.
3. Document any autodiscover, mail, smtp, imap, or custom subdomain records.
4. Keep nameservers unchanged unless you have fully rebuilt the zone elsewhere.
5. Make sure the admin email used for transfer approvals is not dependent on the domain you are actively risking. If possible, have a secondary address available for account recovery.
6. After transfer completion, send and receive test messages from external providers.
7. Review spam authentication using the live DNS records, not what you think should be there.

A common failure pattern is preserving MX but forgetting SPF or DKIM, which leads to mail delivery problems that are less obvious than a hard outage. Successful transfer checklists treat email as a full system, not a single record.

Scenario 4: Transfer a domain close to expiration

This scenario needs extra caution. Source material indicates the domain should not be expired, in redemption, or pending deletion. If you are near the deadline, verify status first and avoid assumptions.

1. Check the exact expiration date and current domain status.
2. Review whether the current registrar has any holds or payment issues.
3. If transfer timing feels tight, renewing first may be safer than racing through an edge case.
4. Do not wait until the last day to unlock the domain or request the EPP code.
5. Watch your inbox for approval messages and respond promptly.

Transfer rules and timelines can vary by registry and registrar implementation, so the evergreen principle here is not to start late. Build a margin of safety.

Scenario 5: Transfer a domain used by a WordPress site

If the site is already running and you are only changing registrar, the transfer should not affect WordPress by itself. Problems usually come from DNS changes, SSL edge cases, or misdirected subdomains.

1. Confirm the web root records for the main domain and www are documented.
2. Check any subdomains used for staging, CDN, API, or login flows.
3. Verify SSL renewals are not tied to a service you plan to remove during the same window.
4. If you also plan to move hosting, split that into a separate project.
5. After transfer, test the homepage, admin login, forms, checkout, and password reset emails.

If you are also preparing a hosting move, keep the registrar transfer isolated first. A registrar change is simple; combining it with a site migration turns it into a broader infrastructure change.

What to double-check

This is the part many guides shorten too much. Transfers usually fail or cause disruption because one small dependency was never inventoried. Use this section as your final review before you click anything irreversible.

1. Domain eligibility and lock status

Check whether the domain is subject to a transfer lock due to recent registration, a previous transfer, or registrant contact updates. The source material highlights a 60-day policy window that commonly affects transfers. If a transfer is blocked, do not keep retrying blindly. Confirm the reason first.

2. Access to approval email

You need reliable access to the contact address that will receive transfer notices. If that mailbox is on the same domain and already fragile, fix that first or ensure you have an alternative recovery path.

3. Full DNS inventory

Do not stop at A and MX records. Many production domains also rely on TXT records for verification, CNAMEs for subservices, SRV records for communications tools, and CAA policies for certificate issuance. Missing any of these may not cause an obvious outage right away, but it can break renewals, integrations, or mail trust.

4. Nameserver strategy

Decide in advance whether nameservers will stay the same. If yes, your transfer risk is lower. If no, build and verify the replacement zone first. Never use transfer day to discover what records your SaaS stack actually needs.

5. WHOIS and contact details

After the transfer completes, review registrant and contact information for accuracy. This is not only an administrative step. Correct contacts matter for future renewals, security notices, and dispute handling.

6. Renewal and billing settings

One reason people move domain registration is to avoid poor renewal pricing or hidden account friction. Once the domain lands at the new registrar, confirm auto-renew preferences, payment methods, and any bundled extras you do or do not want.

7. Post-transfer validation

Once the transfer is done, validate the domain like an operator, not just as a casual visitor:

• Load the apex domain and www.
• Check critical subdomains.
• Send and receive test email.
• Inspect live DNS answers from the intended nameservers.
• Confirm SSL still works and certificates can renew.
• Review account ownership and domain lock settings at the new registrar.

Common mistakes

The biggest transfer issues are rarely exotic. They come from mixing too many changes, skipping record audits, or assuming the registrar and DNS provider are the same thing.

Changing registrar, DNS, hosting, and email all at once

This creates too many moving parts. If something breaks, it becomes difficult to isolate whether the cause is registrar approval, nameserver propagation, missing records, web server config, or mail authentication. Prefer a staged rollout.

Forgetting non-web DNS records

People remember the main website records and forget everything else. That includes DKIM selectors, domain verification TXT records, CAA, and subdomains used by third-party services. Those omissions often surface days later.

Starting a transfer without inbox access

Transfer workflows commonly depend on email confirmation. If you cannot reliably receive those messages, the process may stall or fail at the worst moment.

Transferring a domain in a restricted state

If the domain is too new, recently modified, expired, or otherwise locked, the transfer may not proceed. Check status first. Source material consistently points to the importance of active status, unlocked state, and transfer eligibility.

Assuming nameserver changes are required

Often they are not. If your DNS is already hosted where you want it, leaving nameservers alone reduces risk substantially. A domain transfer can be administrative only.

Ignoring post-transfer hardening

Once the domain arrives, relock it at the new registrar, review account security, and verify contact data. A finished transfer should end with tighter control than before.

When to revisit

This checklist is worth revisiting anytime your domain setup or business risk profile changes. Registrar policies, control panels, and approval workflows can shift over time, so even experienced teams benefit from a fresh pass before acting.

Come back to this process in these moments:

• Before renewal season, when you are reviewing pricing and consolidating vendors.
• When moving to a new DNS provider or introducing fast nameservers.
• Before a website migration without downtime, so registrar and hosting changes stay separate.
• When changing business email hosting setup or adding new mail security records.
• After team turnover, to confirm domain ownership, contacts, and registrar access still reflect reality.
• Whenever you update registrant details and want to avoid running into transfer timing restrictions.

For the most practical next step, use this action list before your next transfer:

1. Inventory the current registrar, DNS host, web host, and email provider.
2. Export the full DNS zone and store it where the team can reach it.
3. Confirm who controls the approval inbox and account MFA.
4. Decide whether nameservers will stay or change.
5. Schedule the transfer during a normal support window, not before a holiday or launch.
6. Run post-transfer validation on web, email, SSL, and subdomains.
7. Relock the domain and document the final setup.

A clean domain transfer is usually uneventful, and that is exactly the goal. If you treat the move as a controlled registrar change rather than an excuse to redesign your whole stack, you can usually preserve uptime, protect email, and end up with a simpler domain and hosting arrangement.