What your mail records forget after a host move

Moving a website is the easy half. The mail is where the week goes sideways, and never on the day of the move. It goes sideways three days later, when someone says a customer never got the invoice. Here is what forgets to come along when you change hosts, in the order it bites.

The SPF record still points at the old host

Most small-business SPF records are one line an old web host handed them years ago, containing an include for that host. Move the site, cancel the old plan, and that include stops authorizing anything useful. Mail still flows, because the mailboxes did not move, but the alignment you had is gone.

The other half of the problem is that nobody ever removes anything, so the record accumulates: includes for providers the business stopped using years ago, and a lookup chain deep enough to blow the ten DNS lookup limit. Past ten lookups the record is a permanent error, and a permanent error is treated by some receivers as no record at all. That state can sit there for a year unnoticed, because most mail still gets through and the mail that does not is invisible to the sender by definition.

Rule I now follow: after any host move, rewrite SPF from scratch instead of editing it. List the systems that are actually allowed to send as that domain today. Usually that is the mail provider, and sometimes the website, and that is the whole list.

The website is a sender, and everybody forgets it

Contact forms, order confirmations, password resets, appointment reminders. All of that is mail, sent from the new web server, usually with a from address at the client's domain. On the old host it may have been authorized by that host's SPF include. On the new one, it is not authorized by anything.

This is the most common post-migration complaint I get, and it does not present as a mail problem. It presents as "we stopped getting leads from the website." The form works. The mail is filed as spam or dropped. On the fleet I run, site mail goes out through the mail provider with real credentials rather than straight off the web server, so the sending identity is the same before and after a move. That one decision removes a whole category of migration bug.

DKIM does not travel

DKIM keys live with the provider that signs the mail, published in DNS as a selector record. Move providers and the old selector is meaningless. Move hosts but not mail and DKIM should survive untouched, which is exactly why it gets clobbered: DNS lands in a new zone, whoever retypes it skips the long ugly TXT record, and nobody spots it, because unsigned mail is not bounced mail.

Check the selector by name after every DNS change. Not the mail flow, the record itself. Unsigned mail looks fine from the inside.

DMARC turns a warning into a rejection

SPF and DKIM failures are soft. DMARC is where they become visible. If the domain has p=quarantine or p=reject and the migration broke alignment, you moved from "some mail looks slightly suspicious" to "our invoices are rejected at the gateway."

On the reporting I watch, one domain pushing roughly 40,000 messages a month still fails alignment on about one percent of them, which is small enough to ignore under a monitoring policy and large enough to mean rejected invoices under an enforcing one. If you are moving a domain that already publishes a policy, drop it to p=none for the duration of the move, keep the reporting address, and read the aggregate reports for a week before you put the policy back. That is not a workaround, it is what the monitoring mode is for. You get to see every system sending as your domain, including the two nobody remembered.

TTLs decide how long the pain lasts

Lower the TTL on your mail records to 300 seconds a day or two before the move, and put it back afterwards. Skip it and a mistake made at 9am is still served from somebody's resolver cache at dinner. Cheapest item on the list, most often skipped, because it has to happen before the day everybody is paying attention.

What I do now

The mail portion of a move is five things: rewrite SPF from the current list of senders, confirm the DKIM selector resolves after the DNS change, route website mail through the mail provider rather than the web server, set DMARC to none with reporting on for the move week, and pre-lower TTLs. It takes under an hour planned, and most of a week unplanned.

You can check the public half of this yourself, free, with the email check tool at redcyfer.com/tools/email-check/. It reads SPF, DMARC and whether your domain is spoofable, which is enough to tell you if something got left behind.

If it did get left behind and you would rather not spend the week on it, deliverability rescue is $499 flat, and business email setup is $299 plus $10 per mailbox. On a Care plan at $149 a month, DNS and business email are looked after as part of the plan, which is the version I prefer, because the fix for this problem is somebody checking the records on the day they change.