How to move a domain without taking email down

The new site is ready, the server is up, an evening is picked for the switch. The domain is pointed at the new place, the site loads, the job looks finished. The next morning somebody calls to say no email has arrived for two days. This scenario plays out far more often than people expect, and the cause is always the same: the domain is treated as one thing that moves as a unit.

A zone is one file, its records are separate jobs

A domain’s DNS zone lives in one place, and the records inside it do jobs that have nothing to do with each other.

Address records, meaning A, AAAA and CNAME, take a browser to the site. MX records say who receives the mail. Inside the TXT records sit SPF and DKIM, and without those two the mail you send lands in the recipient’s spam folder rather than their inbox.

In a site migration, the only group that needs to change is the address records. The other three need no touching, and when they are touched nobody notices right away.

How the mistake happens

Most hosting panels offer a “connect your domain here” button, and that button hands the whole zone to the new provider. The new zone opens with default records: the address record is right, and the MX record is either empty or pointing at the provider’s own mail service.

The result is silent. The site works, nobody suspects anything, incoming mail is refused or goes nowhere, and none of it is discovered until a customer says “I wrote to you and never heard back”.

The right order

Export the existing zone first. Download every record as JSON or a zone file and keep it somewhere. This step takes five minutes and it is the only part of the process that is reversible.

Lower the TTLs. At least twenty-four hours before the switch, drop the TTL on the address records to three hundred seconds, because TTL tells a resolver how long to keep the answer in cache and leaving it high means some visitors will keep seeing the old server for hours after the change. A small number makes the switch quick.

Change only the address records. Do not hand over the zone; update the records one at a time. If a new provider really is needed, copy every record into the new zone exactly first, then change the name servers.

Verify, then raise the TTL back. Once the switch has settled, see with your own eyes that the MX and TXT records are in the list, then put the TTL back to its old value.

The right tool for verification

Checking with dig can mislead here. If the records sit behind a proxy, the query returns a plausible answer under any condition.

The certain information lives in the provider’s record list. After the switch, open that list and count three things: how many MX records are there, is the SPF TXT record present, are the domain verification records in place. If the counts match what they were before, the job is done.

The one sentence for the client

When you share the migration plan, add this line: the email records will not be touched, and after the switch a test message will be sent and received.

That sentence does two jobs at once. It makes the scope of the work explicit, and it makes sure you actually run that test.