Inventory email before you touch DNS

The worst migration I've cleaned up didn't break the website. The site came up on the new server in about twenty minutes, looked perfect, and passed every page check. What broke was email. Someone switched the nameservers before anyone wrote down the mail records, and for roughly six hours every message to the company bounced or vanished. Invoices, password resets, a supplier quote. Nobody noticed until a customer called to ask why their order confirmation never arrived.

Since then I follow one rule on every move, big or small: inventory email before you touch DNS. The website is the part everyone watches. Mail is the part that fails quietly.

Why email breaks during a WordPress migration

On a lot of small and mid-size sites, the domains's DNS zone does three jobs at once. It points the website at a server, it tells the world where to deliver mail, and it vouches for who is allowed to send mail on your behalf. When you move a WordPress site, you usually only think about the first job.

The trouble starts when the migration includes a nameserver change. New nameservers mean a new DNS zone, and if that zone doesn't contain the old mail records, your MX, SPF and DKIM simply stop existing the moment the change propagates. The website works. Email doesn't. And because DNS caches unevenly, some senders still reach the old mailbox for a while, which makes the problem look random and harder to diagnose.

The three records I write down first

MX (mail exchanger). This tells other servers where to deliver mail for your domain. If it points at Google Workspace, Microsoft 365 or the old host's mail server, copy every MX record with its priority exactly as it is. Missing one priority level is enough to cause intermittent failures.

SPF (a TXT record starting with v=spf1). This lists which services may send mail as your domain. Contact forms, invoicing tools and newsletter platforms are often included here. If the new zone drops a service from SPF, that tool's mail starts landing in spam or getting rejected, usually without an error anyone sees.

DKIM (a TXT or CNAME record under a selector like google._domainkey). This is the signature receiving servers use to trust your mail. DKIM records are long, easy to truncate when copied, and specific to each sending service. I copy them from the provider's dashboard, not from a screenshot.

While I'm there I also note any DMARC record, autodiscover or autoconfig entries for mail clients, and verification TXT records for things like Search Console or Microsoft 365. Those rarely cause an outage, but losing them costs someone an afternoon later.

How I test the inventory before cutover

Writing records down isn't enough. Before switching anything, I recreate them in the new DNS zone and check them against the new nameservers directly, not through my own cached resolver. Then I send a test message from an outside address, one that has nothing to do with the domain, and confirm it arrives. I also send a message from the domain to an outside inbox and look at the headers to make sure SPF and DKIM both pass.

If the contact form or WooCommerce sends transactional mail through an SMTP service, I submit one real form on the staging copy too. Forms are where clients notice silence first.

The cutover order that keeps mail alive

Once mail is protected, the rest of the move becomes much calmer. This is the order I use:

1. Clone and verify. The new server runs a full copy of the site, and I check logins, checkout, forms and media on a temporary URL or a hosts-file override.

2. Protect mail. MX, SPF and DKIM are recreated and tested in the new zone, as above.

3. Ready SSL. The certificate is issued or ready to issue on the new side, so visitors never see a browser warning after the switch.

4. Lower TTL. A day or two before the move, I drop the TTL on the records that will change, often to 300 seconds, so the switch propagates in minutes instead of hours.

5. Switch DNS. Only now. It's the last move, not the first.

6. Same-day checklist. Send and receive mail, submit a form, log into wp-admin, place a test order if there's a shop, and confirm scheduled tasks like backups and cron jobs are running on the new server.

What this changes for the client

When the inventory happens first, the visible part of a migration is usually a short window, often measured in hours rather than a lost weekend. The long outages I've seen almost never came from moving files or databases. They came from discovering, after DNS had already flipped, that mail or SSL wasn't ready on the other side.

If you're planning a move and you're not sure what your DNS zone is quietly doing today, start there. Export the zone, list the mail records, and test them before anyone touches a nameserver. It's the least exciting step of the whole project, and it's the one that keeps the phone from ringing.