Moving Your Website Without Breaking Your Email

The new website goes live on a Thursday evening. It looks great, every page loads, and the team goes home happy. Friday morning the phones are quiet in a strange way, and by ten o’clock someone notices that nobody has received an email since last night. Customers have been writing in. Their messages are bouncing, or worse, vanishing.

Nothing was wrong with the website. A website and an email system usually live under the same domain name, and the move touched something it should never have touched. We have moved a lot of domains, and the lessons are consistent.

Your domain holds two systems, not one

Your domain’s DNS is the address book that tells the internet where everything lives. It holds the records for your website, and it also holds the records for your email:

• MX records, which route incoming mail to your inbox provider
• SPF, DKIM and DMARC records, text records that prove your outgoing mail is really from you
• Autodiscover records, which help Outlook and other mail apps set themselves up
• Verification records for Google, Microsoft and other services you have connected

A website move only needs the website records to change, usually one or two entries for your main address and the www version. Everything else should stay exactly as it is. Most email outages after a launch come from someone changing, deleting or failing to copy a record that had nothing to do with the website.

Take a snapshot before anything moves

Before a single record changes, write down every DNS record on the domain: its name, type and value. A spreadsheet or a plain text file is fine.

After the move, compare the new records to your snapshot. The website records should be different. The mail records should be identical, character for character. If an MX record, a DKIM key or a TXT record is missing or changed, you have found the problem before your customers do.

If you are moving DNS to a new provider, for example to Cloudflare for speed and security, import every record and check the import against your snapshot before switching nameservers. Automatic imports are helpful, but they are not perfect. A missing MX or TXT record is the most common cause of a dead inbox the morning after.

Sending and receiving are different jobs

Your website probably sends email: contact form notifications, order confirmations, sign-in codes. That is sending. Your inbox is receiving. They can use completely different services, and it is better when they do.

The trap is turning on a service that routes incoming email for your domain when all you needed was a way to send notifications. Some of those services take over your MX records when you enable them, which quietly redirects your real inbox. Read what a service will change before you click enable.

A cleaner approach is to send website notifications from a subdomain set up only for that purpose. The records for that sending service live on the subdomain, so they never touch the mail setup your team relies on every day.

The old server may be doing more than you think

Many businesses have had the same host for years, and over time it picks up other jobs. The old server might also run a mail server, a control panel, an admin login for some other system, or a subdomain an employee still uses every week. Nobody remembers until it stops working.

Look at every record that points at the old host, and ask what each one is for. Watch especially for records that were set up as aliases of your main address rather than pointing to the server directly. When the main address moves to the new host, those aliases follow it, and the service behind them breaks without anyone touching it. If a record should keep pointing at the old server, pin it there on purpose before you switch.

Do it in the right order

A calm launch follows the same sequence every time:

1. Build and test on a staging address that is not your real domain, so nothing public changes while you work.
2. Take the DNS snapshot and confirm who owns each record.
3. Move only the website records.
4. Check both versions of your address, with and without www. One should load the site and the other should redirect to it.
5. Check https everywhere, including plain http links, which should redirect to the secure version.
6. Compare the mail records to your snapshot.
7. Send a test email in and out from an outside account, and confirm both arrive.

Two more rules save a lot of trouble. First, do not turn on DNSSEC, a security setting that signs your DNS records, in the middle of a registrar or nameserver move. If the signing details at your registrar do not match your new DNS provider, the whole domain can stop resolving for anyone whose internet provider checks those signatures, and that means your website and your email go down together. Turn it on later, once everything has settled. Second, keep the old host alive, and paid, for a short overlap. If something goes wrong, you can point the records back while you sort it out.

Tell the people who own your email

Your email may be managed by an IT person, an outside provider or the company you bought it from. They need to know what is changing before it happens, and just as important, what is not changing. A short note works: “We are moving the website on Thursday evening. Only the website records will change. Your MX, SPF and DKIM records will stay exactly as they are. Here is what we will check afterward.”

That note lets them flag anything you did not know about, and if something does break, they already know the timeline and can help rather than guess.

Plan it like it matters

A website move is a small project with a large blast radius. If your domain carries anything your business depends on, treat the cutover as its own plan, with a snapshot, an order of steps and a way back. Our piece on your website after launch covers what to keep an eye on once the new site is live.

If you are planning a new site and want the move handled carefully from start to finish, take a look at our websites and solutions work.