Keeping email working when a domain moves

Why email breaks first

A website failure is loud and recoverable. Visitors see an error, somebody reports it, and once the pointing is fixed the same pages return. Email failure is quieter and more damaging. Messages sent while the records are wrong are either bounced back to the sender or delivered to a mailbox nobody is watching, and neither can be retrieved later by fixing the configuration. A small charity that loses a week of email loses grant correspondence, membership enquiries and donations, and only finds out when somebody asks why they were ignored.

Email is also more fragile because more records are involved. A website needs one record pointing at one server. Email needs a record naming the mail servers, plus several text records that other mail systems consult to decide whether a message is genuine. Any of those can be lost in a move, and the failures they cause look nothing alike.

What controls delivery

The record that routes incoming mail is the MX record, which names the servers permitted to accept mail for the domain. It is entirely independent of the website, which is why a choir can have its site with one company and its mail with another and nothing about the domain minds.

Alongside it sit the authentication records, published as text on the domain:

• SPF lists which servers are allowed to send mail claiming to be from the domain.
• DKIM publishes keys that let a receiving system verify a message was signed by the sending system.
• DMARC states what a receiving system should do when the first two checks fail, and where to send reports.

These are invisible when correct. When they are wrong, outgoing mail from a village foundation starts landing in spam folders or is rejected outright, and the cause is not obvious from the sending side, because the message appears to have left successfully.

Before the move

The preparation is a written inventory, made before anything is touched and kept where more than one person can find it. Record the current nameservers. Record every DNS record on the domain, including the ones nobody recognises, since services often plant a text record to prove control and will break when it disappears. Note which company actually provides the mailboxes, which is frequently not the company that provides the website. Note where each mailbox is read from, and whether any addresses are forwarders rather than real mailboxes.

Then check where the notifications will go. If the contact address for the registrar account is at the domain being moved, a mistake in the move can prevent the arrival of the very messages needed to correct it. Setting the account contact to an address at an unrelated provider is a small change that removes an entire category of disaster, as noted in the registrant contact.

During the move

The key principle is to move one thing at a time. A change of registrar, done properly, does not touch DNS at all: the nameservers travel with the record and mail keeps flowing throughout, as described in transferring to another person. Trouble arises when the nameservers are changed at the same time, because the new provider starts with a default set of records that will not include the mail configuration unless somebody copies it across.

Where nameservers do have to change, recreate every record at the new provider first, verify them, and only then repoint. Lowering the record lifetimes a day or two beforehand shortens the window in which some senders use the old answers and others the new, which is the caching behaviour explained in DNS in plain English.

After the move

Checking properly takes a few minutes and is worth doing the same day. Send a message from an outside account to each address on the domain and confirm it arrives in the expected mailbox rather than an old one. Send a message from each address to an outside account and confirm it arrives in an inbox rather than a spam folder. Look up the domain's MX and text records and compare them line by line against the inventory. Ask one person on a different mail provider to do the same, since one system may accept what another rejects.

Keep the old mailboxes running for a while after a move. Mail that arrives at the old destination is recoverable while it exists and gone once it is deleted.

The archive

Mailboxes hold years of an organisation's memory, and moving providers can quietly end access to it. Before the old service is cancelled, export or migrate the stored mail, and confirm the export opens. Old messages are frequently the only surviving record of who agreed what, which is exactly the material a committee needs when reconstructing a domain's history, as in committee handover.