You keep your email working when changing web host by understanding that your website and your email are separate services connected only through DNS, and by changing only the records that point to your web host while leaving your email records untouched. This separation is the whole insight, and missing it is why people are blindsided when their site moves fine but the email goes dark. Your website is reached through address records, the A or CNAME records that say where the site lives, and your email is routed by MX records that say where mail should be delivered. Moving your web host means updating the address records to point at the new server, but it does not require changing the MX records, and the danger is precisely that, in the move, the MX records get overwritten, dropped, or not carried over, which silently stops email. So the rule is simple: change the website records, keep the email records. WPBuildAI handles the website side, returning your URL list for the site move, while email continuity is this DNS task to plan alongside it.

Keep the web move and the mail move on separate checklists, because the search side has its own paperwork: Google’s June 2026 guidance expects Change of Address requests for all subdomains and both the www and non-www variants of the old domain, which is easy to forget while you are focused on MX records.

Website and email are different services

Start with the mental model, because everything follows from it. People often assume their web host and their email are one thing, since they may have set them up together, but technically they are separate services that your domain points to through DNS, the system that maps your domain to the servers behind it, as the DNS glossary entry describes. Your domain has different records for different purposes: address records for the website, mail records for email. Changing where your website is hosted is a change to the website records only. The email can keep being delivered by the same provider as before, completely unaffected, as long as its records are left in place. Internalizing that these are two independent services sharing one domain is what makes keeping email working straightforward.

How email routing actually works

Email is routed by MX records, which stand for mail exchange and tell sending mail servers where to deliver mail for your domain, as described in the MX record reference. When someone emails you, their mail server looks up your domain’s MX records and delivers to whatever mail host those records name. Crucially, that mail host is independent of your web host: your site can be on one server while your email is handled by a completely different provider, all under the same domain, because the MX records point mail one way and the address records point the website another. So keeping email working through a web host change is, at its core, about leaving the MX records pointing where they already point, so mail keeps flowing to the same place regardless of where the website now lives.

The two situations, and what changes in each

There are two common scenarios, and the right action differs. In the first, you switch web hosting but keep the same DNS provider. Here you change only the address records to point at the new web server, and you leave the MX records exactly as they are, so email is untouched. This is the simpler and safer case. In the second, you also move your DNS to a new provider, often because the new web host wants to manage your DNS. This is the riskier case, because the new DNS starts empty, and you must copy every existing record to it, including all MX records and any related mail records, before switching, or email breaks the moment DNS moves. The rule for the second case is total: bring everything, not just the website records, because the new DNS knows nothing your old one knew until you recreate it.

The classic mistake: dropping MX when moving DNS

The single most common way email breaks is moving DNS without carrying the MX records. It happens because the focus is on getting the website live, so the address records are set up carefully on the new DNS while the MX records, which have nothing to do with the website, are forgotten. The website works perfectly, so the move looks successful, and then incoming email quietly stops because mail servers can no longer find a valid MX record, or find one pointing at the wrong place. The fix and the prevention are the same: before switching DNS, list every record at the old provider, including MX and any mail authentication records, and recreate all of them at the new provider. Treat the MX records as first class items of the move, not as website afterthoughts.

Lower time-to-live and verify

As with any DNS change, timing and verification matter. Lower the time-to-live on your records a few days before the move, so any change propagates quickly and the window of inconsistency is short, the same idea as in a zero-downtime website migration and explained in the time-to-live reference. Then, after the change, verify email explicitly: send a message to your address from an outside account and confirm it arrives, and send one from your address and confirm it goes out. Do not assume email works because the website does; they are separate, so test them separately. Verifying both directions of mail after the change is what turns hoping email survived into confirming it did, before any missed message goes unnoticed.

Keep this separate from the SEO side of the move

It is worth placing this correctly relative to the rest of a migration. The website side, the URLs, redirects, content, and metadata, is what affects your SEO, and a host change that keeps the same domain and URLs is largely neutral for search, as covered in does changing hosting affect SEO. Email continuity is a parallel, separate concern: it does not affect your rankings, but it absolutely affects your business if it breaks. So plan them side by side without conflating them: handle the URLs and redirects for SEO, and handle the DNS records for email, recognizing they are different tasks that happen to occur during the same move. WPBuildAI returns the URL list for the website side so that part is covered, while the MX and DNS work is the email side you manage in parallel.

Steps to keep email working through a host change

  1. Identify where your email is hosted and what MX records you have.
  2. Decide the scenario: web host only, or DNS provider change too.
  3. Web host only: change just the address records, leave MX alone.
  4. DNS change too: copy every record, including all MX, to the new provider.
  5. Lower time-to-live a few days before, so changes propagate quickly.
  6. Verify mail after: send to and from your address to confirm both work.

Worked example: a host move that kept email alive

Imagine a business moving its website to a faster host that also offered to manage DNS. Knowing email and website are separate, the team first lists every DNS record at the current provider, noting the MX records pointing at their email service and the related mail authentication records. They lower the time-to-live a few days ahead. When they set up the new DNS, they recreate every record, the new address records for the website and, crucially, the exact same MX and mail records, before switching DNS over. After the switch they point the website records at the new host, then test email by sending a message in and out, confirming both work. The website moves and the email keeps flowing, because the MX records were treated as essential cargo, not left behind, the kind of completeness that defines a careful migration overall.

Limitation: this is DNS, not an SEO fix

It is honest to bound this clearly. Keeping email working is a DNS task, separate from the SEO work of a migration, so doing it perfectly protects your mail but does nothing for your rankings, and doing the SEO work perfectly does nothing for your email. They must both be handled, but they are different jobs. This page also covers the routing of mail through MX records; it does not cover migrating mailboxes or changing email providers, which is a further project of moving the actual messages and accounts. If you are also changing who hosts your email, that is a separate migration of its own. Here the goal is narrower and vital: when you move your web host, do not let your existing email stop working, by leaving the MX records intact.

Common mistakes

  • Assuming web host and email are one service that moves together.
  • Moving DNS to a new provider without copying the MX records.
  • Focusing on the website records and forgetting mail records exist.
  • Not lowering time-to-live, so a misstep propagates slowly and painfully.
  • Declaring success because the website works, without testing email.

Key points

You keep your email working when changing web host by treating website and email as separate services joined by DNS, and changing only the website address records while leaving the email MX records alone. If you switch web hosting but keep DNS, change just the address records; if you also move DNS providers, copy every record, including all MX records, to the new DNS, because the classic failure is dropping MX while focusing on the website. Lower your time-to-live beforehand so changes propagate quickly, and verify mail in both directions after the move rather than assuming it survived. Keep this DNS task separate from the SEO side of the migration: it protects your mail, not your rankings, and both must be handled. WPBuildAI handles the website side, returning your URL list for the site move, while email continuity is this DNS task to plan alongside it. Send your web address for a free analysis.

Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.