The DNS checklist I run so a WordPress to Astro move never breaks client email

The scariest part of moving a client off WordPress isnt the rebuild. Its cutover day, when you touch their DNS and their email quietly stops working at 4pm on a Friday.

I've done enough of these WordPress to Astro moves now that I run the same checklist every time. Nothing fancy. It just stops me from being the guy who broke the bakery's inbox.

Why email breaks during a website move

Most small business clients have their domain at some registrar, the website at a cheap WordPress host, and email at Google Workspace or Microsoft 365. Three different companies, one DNS zone.

The website only needs two records. Email needs a handful of others. The problem is that a lot of hosts and registrars have a "connect your domain" button that helpfully wipes every record it doesnt recognise. That's how MX records disappear.

So the whole job is: change the website records, touch nothing else.

Step 1: screenshot the zone before you touch it

Before anything, I export or screenshot the full DNS zone. Every record. I drop it in the client folder with the date.

Then I sort it into two piles:

• Website: the apex (example.com) and www. Usually an A record pointing at the old WordPress host and a CNAME or A on www.
• Email and everything else: MX, the SPF TXT, DKIM (TXT or CNAME), DMARC TXT, plus random verification TXT records for Google, Facebook, whatever.

Pile two does not get touched. Ever. If I'm not sure what a record does, it goes in pile two.

Step 2: get the new site live on a preview URL first

The Astro build gets deployed and checked long before DNS day. I deploy with the CLI:

npm run build
npx novence deploy ./dist --json

That gives me a *.novence.ai preview URL that isnt indexed, so I can send it to the client, run through the redirects and forms, and not worry about Google picking up a half finished site.

Cutover day should be boring. If you're still fixing layout bugs on cutover day you're doing it in the wrong order.

Step 3: attach the domain and let the host tell you the records

I dont type DNS records from memory. I attach the domain and copy exactly what comes back:

npx novence domains add www.clientsite.com.au

For Novence that prints a www CNAME to fallback.novence.ai, and then you do one thing for the apex: either an ALIAS on @ to the same target, or a URL redirect from the apex to https://www.clientsite.com.au/.

Small but important: the apex cant be a plain CNAME if the domain also has MX records. That's a DNS rule, not a host thing. If the registrar doesnt support ALIAS or ANAME, use the forward to www and move on.

Step 4: edit two records at the registrar, by hand

At the registrar I:

1. Change the www record to the new CNAME.
2. Change or replace the apex A record with the ALIAS or the forward.
3. Delete the old WordPress host's A records for those two names only.

That's it. I dont click any wizard, I dont "import" a template, and I dont let the new host manage the whole zone unless the client actually wants that.

Then I compare the zone against my screenshot from step 1. Every MX, SPF, DKIM and DMARC record should be byte for byte the same.

Step 5: test mail both ways

Once DNS resolves and HTTPS is issued, I test email in two directions:

• Send from my personal Gmail to [e-mail]. Incoming works, so MX is fine.
• Ask the client to reply from that address back to me. Outgoing lands in my inbox and not spam, so SPF and DKIM are fine.

Takes two minutes. I do it while still on the call with them so they see it working.

If incoming fails, the website can stay on the new host. Go back to Google Admin or the Microsoft 365 setup page, copy the MX records they publish, and put back whatever went missing. Dont try to roll back the whole site in a panic.

Step 6: check the domain status, then the boring stuff

npx novence domains status

I wait until it stops asking for more DNS changes, then:

• Load the apex and www, with and without https, and make sure they all land on one canonical URL.
• Spot check a few old WordPress URLs to confirm the 301s from /_redirects fire on the real domain, not just the preview.
• Submit the sitemap in Search Console for the real domain.

Step 7: leave the old host running for a week

I dont cancel the old WordPress hosting on cutover day. DNS caches, someone has a bookmark to /wp-admin, the client remembers a PDF that was only ever on the old server. A week of overlap costs a few dollars and has saved me more than once.

After the week I grab a final backup of the old site and the database, then cancel.

The short version

• Screenshot the zone.
• Website records are www and the apex. Everything else is someone elses problem and you leave it alone.
• Get the host to print the records, dont guess them.
• No "connect domain" wizards.
• Test mail in and out before you hang up.

The rebuild is where you show off. Cutover is where you keep the client. If you're moving a pile of WordPress sites over, having all of them on one host with the same domain flow makes this checklist really repetable, which is the whole point.