Moving your website? The order that keeps your email and rankings

When your site moves to a new developer or a new host, the site is the part everyone looks at. Email is the part that hurts. If one DNS record gets lost on the way, messages stop going out or stop arriving, and often you only notice days later, when nobody connects it to the move any more.

I moved my own domain to a new DNS provider recently and went through the same list you will find below. You do not have to carry it out yourself. You only need to know what to ask for and in what order, so you can hold anyone to it.

Before anyone touches DNS: five questions

1. Where is the domain registered, and who has access to that account? (The registrar, not the host.)
2. Where does your email live? With the same company as the site, with Google, with Microsoft, somewhere else? If email stays where it is, the move has to leave it untouched.
3. Is there a copy of every DNS record as it stands today? If not, that is the first thing you ask for.
4. Which page addresses will change? If any do, who sets up the redirects?
5. What is the way back if something goes wrong?

If the developer has no clear answer to the third and the fifth, wait.

The order that keeps email alive

1. The full list of records, saved

The DNS zone is the list that tells the internet where your site is and where your email goes. For email, these matter most:

• MX: the servers that receive your mail;
• SPF (a TXT record): who is allowed to send on behalf of your domain;
• DKIM (also TXT, and long): the signature on the mail you send;
• DMARC (a TXT record on _dmarc): what other servers do with mail that fails those checks;
• verification TXT records for Google, Microsoft and other services.

Every one of them is copied exactly, character for character, before anything changes. A plain text copy that you keep too, not only the developer.

2. Email first, and checked

At the new DNS provider, the email records go in first and get compared against the saved list. One thing to watch: the automatic zone import many dashboards offer can skip records. A DKIM key, being long, is a classic casualty. The import looks complete, yet the one line that matters is missing. So ask for a line-by-line comparison, not an assurance that it imported fine.

Two more simple rules. A DKIM key is copied and pasted, never retyped from a screenshot: a single wrong character breaks it without any error message. And if the new provider offers a proxy (Cloudflare marks it with an orange cloud), email records such as mail stay DNS only. That proxy only carries web traffic, so your email app would no longer be able to connect.

If your domain has a strict DMARC policy (p=reject), a mistake here does not send your mail to spam. It gets rejected outright.

3. Lower the TTL in advance

TTL is how long other servers keep a DNS answer before asking again. Lower it a day or two before the move and the change reaches everyone faster, and so does any correction.

4. DNSSEC off before the nameservers change

If your domain uses DNSSEC, the signature registered at the registrar has to match your DNS provider. Switch providers with DNSSEC still on and networks that check the signature can refuse the domain entirely. It goes off before the switch and back on once the new provider is active.

5. Nameservers first, the site after

This is the trick. The nameservers change while the new zone is a faithful copy of the old one. At that moment nothing changes for visitors or for email, and that is exactly the point: the hardest step to undo changes nothing.

Only once the new provider confirms the zone is active do the site records (usually the bare domain and www) get pointed at the new host. A separate step, small and easy to reverse.

6. HTTPS before you announce anything

The security certificate has to be issued and checked on the new host, for the bare domain and for www, before you send the link to anyone. Otherwise your first visitor sees a security warning instead of your site.

The order that keeps Google on your side

Changing host is not the problem in itself. Addresses that disappear are.

• Keep page addresses the same wherever you can. Same address, same content, nothing to explain.
• Where an address does change, every old address gets a permanent redirect (301 or 308) to its new one. Not to the home page: to the matching page.
• One form of the domain: either with www or without, and the other one redirects to it permanently.
• In Google Search Console: the domain verified (the verification TXT is one of the records you saved in step 1), the sitemap submitted again, and indexing requested for the home page.

“The site is down!” on day one

Right after the switch you may see the old site, an error page or nothing at all, while the site is working perfectly. The router at home or in the office remembers the old DNS answer for a while, sometimes for hours.

Before you call anyone, open the site on your phone, on mobile data, with Wi-Fi off. If it works there, nothing is broken: your network is still looking at the old address. Restarting the router usually fixes it for every device in the building. For a while you may even see the old site on one page and the new one on the next. That is still lag, not a fault.

What to ask for, in short

• a full copy of the DNS zone, kept by you;
• email moved first and compared line by line;
• TTL lowered in advance;
• DNSSEC off before, on after;
• nameservers first, site after;
• a redirect for every old address;
• HTTPS ready before the announcement;
• Search Console updated.

If you want someone who does the move in this order and hands you the list of everything that was checked at the end, see how I handle migrations or write to me directly.