Moving or Redesigning Your Website? Here’s How to Keep Your Email Working

Moving the website is the easy part. Making sure the email comes with it is the part that matters.

After 21 years of launching websites, the launch-day problem I worry about most has nothing to do with the website. It's email. A broken page gets noticed in minutes. Email that stops arriving can go unnoticed for days, and the whole time your customers think you're ignoring them.

The good news is that it's preventable. It just takes knowing where things can go wrong before anyone touches your domain.

Why could a website change affect email at all?

Because they share a domain. Your domain's DNS settings hold separate entries for each service: one set says where the website is, another set (the MX records) says which server accepts mail for you@yourbusiness.com, and a few text records vouch for the mail you send. The website and the email can sit with completely different companies. A website project only touches email when someone edits, moves or deletes those shared settings, which happens more often than you'd think.

What are the three ways email usually breaks during a website move?

1. The DNS moves and the email records stay behind

Some setups keep DNS where it is and just update the website entries. Others move the whole DNS zone to a new provider by changing the nameservers. That second route is fine, and often better, but the new provider needs a complete copy of your records. If the MX records are missing on the new side, mail servers can't find you and messages bounce. Cached DNS answers can also keep mail failing for a while even after the records are put back.

2. Your email was living on the old web host

This is the one that catches people. A lot of businesses got "free" email bundled with their hosting years ago, often on a cPanel plan. Nobody remembers that, so when the new site goes live and the old hosting gets cancelled, the mailboxes go with it. Sometimes years of saved messages too. Before cancelling anything, find out whether your inbox is on Google Workspace, Microsoft 365, or the server you're about to shut off.

3. Your website's own emails start landing in spam

Contact forms, order confirmations and password resets are sent by the website, not your inbox. When the site moves to a new server or platform, that mail comes from somewhere new. If your SPF record doesn't list the new sender, receiving servers have less reason to trust it. Gmail now requires everyone sending to its users to have SPF or DKIM set up, and bulk senders need SPF, DKIM and DMARC, so a missing entry here shows up fast as form leads sitting in spam folders.

What should you check before launching a new site?

This is roughly the checklist we run at Abra before any domain change:

1. Find out where your email actually lives. Look up the MX records, or just ask whoever set up your inbox. Write it down.
2. Export every DNS record. Not only the website ones. MX, SPF, DKIM, DMARC, and any verification records for tools like Google, Microsoft or your email marketing platform.
3. Compare old and new line by line. If DNS is moving to a new provider, check that every record made it across before switching nameservers. Automatic imports are helpful, but they can miss less common records.
4. Add the new site to your SPF record if the website sends its own mail, or route forms through a proper sending service.
5. Test right after launch. Send mail to the business address from an outside account, reply from it, and submit the contact form.
6. Keep the old host for a while. Don't cancel until email has been tested on the new setup. A month of overlap is cheap insurance.

How do you know if email already broke?

A few signs to watch for in the days after a launch:

• Customers mention emails you never got.
• People forward you "undeliverable" or "address not found" bounce messages.
• Contact form leads suddenly stop, or start showing up in spam.
• Your inbox goes quiet in a way that doesn't match a normal week.

If you see any of these, look at the MX and SPF records first. Most of the time the fix is a missing line, and it can be added back in minutes. The hard part is noticing.

Can I do this myself, or should my developer handle it?

Some of it you can absolutely do yourself, even if you've never opened a DNS panel:

• Find out who runs your email. Check your billing. If you pay Google or Microsoft for email, that's where it lives. If you don't pay anyone for it, it's probably bundled with your hosting.
• Make sure you can log in to your domain registrar. GoDaddy, Namecheap, Squarespace, wherever you bought the name. Lost logins are the most common thing that slows a launch down.
• Take screenshots of your current DNS records. Even if you don't understand them, a snapshot of how things looked before the change is useful if something goes wrong later.
• Test after launch. Email yourself from a personal account, reply back, and fill out your own contact form.

The record-by-record work is where it's worth having someone who does this regularly. Moving nameservers, comparing records, editing SPF and DKIM, and setting the TTL are all quick for someone who knows what they're looking at, and one wrong character can stop mail cold.

That part I'm happy to do for you. On every Abra launch we handle the DNS side ourselves, and if you're moving a site someone else built, we can check your setup before anything changes and make the switch for you.

Does this apply to Shopify and WordPress sites?

Yes. Neither platform hosts your email on its own, so the risk is the same: what happens to your DNS during the switch, and where your mail lived before. Connecting a domain to Shopify, for example, normally means updating a couple of website records rather than moving everything. That's the safer route, but it still needs someone to check that nothing else got edited along the way.

Planning a redesign or a host move and not sure where your email lives? Get in touch and we'll take care of it.

Sources

• Google, "Email sender guidelines" - SPF or DKIM required for all senders to Gmail, plus DMARC for bulk senders
• Cloudflare docs, "DNS quick scan" - automatic record imports and why to review them before changing nameservers