How to move a website to new hosting without your email going down

Short answer: you can move a website without touching your email, because the site and the mail use separate DNS records. Change only the A or CNAME record for the site and leave the MX, SPF, DKIM and DMARC records alone. First check that the MX record doesn’t point at the domain itself and that SPF doesn’t rely on +a.

A domain’s website and its email are separate records in DNS, and they move separately. When you move the site you change only the record pointing at the web server; the mail records stay exactly as they are. Problems almost never come from the move itself — they come from two details that sit unnoticed for years: the MX record pointing at the domain itself instead of at a mail server, and an SPF record that relies on +a. Both work flawlessly while the domain points at the old host, and both break the moment you repoint it.

Why email goes down at all

DNS is the domain’s directory. It holds separate lines for different services:

• an A or CNAME record for the site itself — “when someone opens tcp.bg, send them to this server”;
• an MX record for mail — “messages for @tcp.bg are delivered to this server”;
• TXT records (SPF, DKIM, DMARC) that prove messages from the domain are genuine;
• records for webmail, cPanel, FTP and other supporting services.

Moving the site touches only the first line. Email keeps working because the MX record points somewhere else. That is the theory, and most of the time it holds.

The two cases where it doesn’t are common on older hosting accounts:

The MX record points at the domain itself. Instead of mail.yourdomain.com, it simply says yourdomain.com. While the domain points at the old server, which also hosts the mail, everything is fine. The second you repoint the domain to the new site, sending servers start delivering messages to your new web server — which does not accept mail.

The SPF record uses +a. That means “allow whatever server the domain points to”. After the move that server is a different machine, so SPF starts authorising the wrong one while the real mail server is left unauthorised. Your outgoing mail begins landing in spam folders.

What should you check before touching anything?

1. Export the full record list from the current DNS. Don’t trust memory — a zone typically holds 20 to 30 lines, and one forgotten subdomain stops working the moment you switch.
2. Look at what the MX record points to. If it points at the domain itself, change it to mail.yourdomain.com first and wait a day before moving the site.
3. Read the SPF record. If it contains +a, replace that with the mail server’s actual IP address.
4. Check the mail apps. In Outlook or on a phone, the incoming and outgoing server should be mail.yourdomain.com, not the bare domain. If it’s the bare domain, mail stops the instant you move — because of the phone’s settings, not DNS.
5. Lower the TTL on the records you plan to change to five minutes, at least a day ahead. TTL is how long the world remembers the old answer. With a 24-hour TTL, a mistake gets fixed tomorrow.

The move itself

Order matters:

1. Put the site on the new server and confirm it works — easiest with a temporary address, or your own computer’s hosts file.
2. Issue the SSL certificate for the new server before switching. Change the record while the certificate is still being issued and visitors get a security warning.
3. Change only the A or CNAME record for the domain and for www.
4. Leave MX, webmail, cPanel, FTP and the TXT records exactly as they are.
5. Check the site from an outside network — mobile data does the job — then immediately send a test message to and from an address on the domain.

The first 24 hours

DNS does not change everywhere at once. Providers hold the old answer for different lengths of time, so for a day part of the world sees the new site and part sees the old one. That is normal and not a reason to panic.

The unpleasant exception is a provider that mixes old and new answers — it remembers the old MX record but looks the domain up afresh. Messages then head for the wrong server. Sending servers retry over the following hours, so mail isn’t lost, but it can be delayed. That is precisely why the first item on the checklist above is to fix the MX record before the move rather than during it.

For that first day, two things are worth watching: whether the site opens from several different networks, and whether mail is arriving as usual.

Is it even worth moving the email too?

Usually not. Email is rarely the reason for changing hosting, and migrating it carries a real risk of lost messages and days of fiddling with settings on everyone’s phone. The calmest approach is to move the site to where it will run faster and leave the mail where it is. The two don’t need to live on the same server — and mostly they’re better off not doing so.

When we moved the site of the accounting firm Troya Consult, the mail stayed with the old provider and didn’t stop for a minute, even though the site changed both its server and its DNS provider.

Short checklist

• Full list of DNS records exported and saved
• MX points at a mail subdomain, not the bare domain
• SPF without +a, using a specific IP
• Mail apps set to mail.yourdomain
• TTL lowered in advance
• New site live with a valid SSL certificate before the switch
• Only the site and www records changed
• Test message both ways immediately afterwards

If that checklist reads like work you’d rather not do, it is part of building a website with us. We move the domain and the site; your only job with the email is confirming that messages still arrive.