Moving a domain: pre-flight check and step-by-step plan

Changing registrar, DNS host or e-mail provider goes wrong in the same few places: an expiry date that is too close, a transfer lock, DNS that disappears with the old registrar, a DS record left behind, long TTLs, a forgotten DKIM key. Enter the domain and this page checks those points on live public data, gives you the steps in order, and compares the result afterwards.

The checks read public registration data, DNS and the website's certificate from our server at the time shown. The page cannot see your registrar account, cannot unlock or transfer anything, and does not know records that are not visible from outside. A check that fails is shown as "could not be checked", never as fine.

What are you changing?

The check always looks at the registrable domain (example.com, not www.example.com): a move concerns the whole zone.

Step-by-step plan: Changing registrar

0 of 8 steps done

Your ticks, the chosen scenario and the pre-flight values are kept in this browser only (local storage). They are not sent to us, do not follow you to another device, and disappear when you clear the site data.

Post-move check

When the move is done, run the checks again. Each value is compared with the pre-flight run stored in this browser.

Run the pre-flight check first: there is nothing to compare with yet.

Watch this change

A watch in the workspace re-checks a record against the value you expect and reports how many of the measured resolvers return it, for example "9 of 12 resolvers". It needs an account.

Open the watch wizard

Step-by-step plan

How to transfer a domain to another registrar
  1. Check expiry and renew if it is close. Start with at least 15 days left. If the pre-flight check shows less, renew at the current registrar first.
  2. Decide where DNS will live. If the nameservers belong to the current registrar, set up the zone at the new DNS host and switch nameservers before the transfer (see the DNS scenario). If DNS is a separate service, leave it alone.
  3. Make sure you can read the registrant e-mail. Approval and confirmation messages go to the contact address on the registration. Update it first if it is an old mailbox, and mind that some registrars lock the domain for 60 days after such a change.
  4. Switch off the registrar lock. In the current registrar's panel: "transfer lock", "registrar lock" or "domain lock". The status clientTransferProhibited disappears from the registration data afterwards; run the check again to see it.
  5. Request the auth code. Also called EPP code or transfer code. It is issued by the current registrar, is valid for a limited time and works like a password for the domain: do not send it to anyone but the new registrar's order form.
  6. Start the transfer at the new registrar. Order the transfer there and enter the auth code. For most generic TLDs a transfer includes a one-year renewal that is added to the current expiry date.
  7. Approve, or wait out the five days. The current registrar may ask you to confirm. If nobody objects, a generic TLD transfer completes on its own after five days. Do not change contacts or nameservers while it is pending.
  8. Afterwards: lock again and verify. Switch the registrar lock back on at the new registrar, check auto-renew and contact details, then run the post-move check below.
How to change DNS host without downtime
  1. Export the complete zone. Use the export function of the current DNS host if there is one. The pre-flight check only sees the common record types at the domain itself: subdomains, DKIM selectors, SRV and verification TXT records are not visible from outside.
  2. Lower the TTLs a day ahead. Set the records you are about to move to 300 seconds at the current host, then wait at least as long as the old TTL.
  3. Recreate every record at the new DNS host. Copy values exactly, including MX priorities and the quotes of long TXT records. Do not change anything else in the same step.
  4. Compare answers before switching. Query the new nameservers directly (dig @new-nameserver example.com MX) and compare with the current answers. They should be identical.
  5. If DNSSEC is on: remove the DS first. Delete the DS record at the registrar and wait for its TTL to pass. Switching nameservers under an old DS makes the domain fail for validating resolvers.
  6. Change the nameservers at the registrar. Enter all nameservers of the new host. The TLD's own NS TTL applies here, often a day or two, and you cannot lower it.
  7. Keep the old zone running. Leave the old zone untouched for at least 48 hours: resolvers that still hold the old delegation must keep getting correct answers.
  8. Sign again and raise the TTLs. If you use DNSSEC, enable signing at the new host and publish the new DS at the registrar. Raise the TTLs to their normal values once everything is stable, then run the post-move check.
How to move a domain's e-mail to another provider
  1. List what sends and receives mail today. MX, SPF, DMARC and every DKIM selector, plus other systems that send with your domain: newsletters, invoicing, the website's contact form. Each of them must still pass SPF or DKIM afterwards.
  2. Lower the MX TTL a day ahead. Set it to 300 seconds at your DNS host and wait at least as long as the old TTL.
  3. Create mailboxes and aliases at the new provider. Every address that receives mail today must exist before the MX change, otherwise mail to it bounces. Verify the domain at the new provider with the TXT record it gives you.
  4. Publish the new DKIM key. Add the new provider's DKIM record next to the old one. Different selectors do not conflict, so both can stay during the change.
  5. Switch the MX records. Replace the old MX records with the new provider's, exactly as its setup guide lists them, priorities included. Do not mix two providers' MX records.
  6. Update SPF, then look at DMARC. Add the new provider's include to the single SPF record and remove the old one when nothing sends through it any more. Keep the DMARC policy as it is during the move; read the reports for a week before tightening it.
  7. Keep the old mailboxes for a while. Sending servers retry and caches expire at different times: mail can still arrive at the old provider for a few days. Move the stored mail, then cancel.

Setup guides for the new e-mail provider

The exact MX, SPF and DKIM records of common providers, with a check of your domain against them.

Terms and tools for this move

Questions about moving a domain

Does a registrar transfer cause downtime?

Not by itself. A transfer changes who manages the registration, not where DNS is answered. Downtime happens when the nameservers belong to the old registrar and are switched off when the domain leaves. Move DNS first, or confirm that the old registrar keeps serving the zone.

What is the 60-day transfer lock?

For generic TLDs, registrars refuse transfers during the first 60 days after a domain is registered and during the 60 days after a previous transfer, as ICANN's Transfer Policy provides. Some registrars also lock a domain after a change of the registrant's details. Country-code TLDs have their own rules.

Which status codes stop a transfer?

clientTransferProhibited is the registrar lock: you switch it off in the current registrar's panel. serverTransferProhibited, pendingTransfer, pendingDelete and redemptionPeriod are set at the registry and only end with the process behind them.

How long should I wait after lowering a TTL?

At least as long as the old TTL. A resolver that fetched the record just before your change keeps the old TTL until it runs out; only then does it pick up the short one.

Why does DNSSEC matter when I change nameservers?

The DS record at the parent zone names the keys of the current DNS host. New nameservers sign with other keys, or not at all. While the old DS is still published, validating resolvers treat every answer as forged and the domain fails for their users. Remove the DS first, switch, then publish the new one.

Will I lose e-mail while MX records change?

Sending servers retry for days when a destination does not answer, so short gaps rarely lose mail. Mail is lost when an address does not exist at the new provider yet, or when the old mailboxes are cancelled before caches have expired. Create every address first and keep the old provider for a few days.

Is my checklist stored on your servers?

No. The ticks and the pre-flight values stay in your browser's local storage. The lookups themselves run on our server like every other lookup on this site.

May we count visits with Google Analytics? It sets cookies and sends usage data to Google. Nothing loads unless you allow it. Cookie details