How to Handle Email Hosting When Migrating Your WordPress Site

Email almost never lives inside your WordPress installation, which is the most useful fact to hold on to before a move. Mail routing is controlled by DNS records (MX, SPF, DKIM), while your pages are served by A records, so the two can travel separately. Handling email hosting when migrating your WordPress site comes down to knowing which records to change and which to leave completely alone.

We move hundreds of sites a month, and broken email causes more panic than broken pages. The fix is almost always preparation rather than technical wizardry.

Why Email Breaks During a Migration

Mail goes missing for one of three reasons, and none of them involve your theme or database. Either the MX records were overwritten when DNS was repointed, or the mailboxes were sitting on the old host’s server and got deleted with the account, or the authentication records (SPF, DKIM, DMARC) were left behind so mail started landing in spam.

The dangerous scenario is the second one. If your mailboxes live in the old host’s cPanel, cancelling that account destroys the mail store, and there is usually no backup after 14 to 30 days. That’s a data loss problem, not a DNS problem.

Find Out Where Your Email Actually Lives

Before touching anything, look up the current MX records for the domain using a tool like MXToolbox or a dig MX yourdomain.com command. The answer tells you exactly who handles mail today.

• MX points to google.com or aspmx.l.google.com: you’re on Google Workspace, and the migration barely affects you.
• MX points to mail.protection.outlook.com: Microsoft 365 is handling mail, same story.
• MX points to mail.yourdomain.com or the old host’s server name: your mailboxes live on the hosting account you’re about to leave, and they need to be moved first.
• MX points to a provider like Zoho, Fastmail or Rackspace: third-party mail, safe to leave untouched.

Write the records down in a plain text file, including priorities, plus every TXT record for SPF, DKIM selectors and DMARC. Screenshots of the old DNS zone have saved more migrations than any plugin.

Moving Mailboxes off the Old Host Without Losing History

If your mail sits on the old shared server, treat the mailbox transfer as its own project and finish it before the site moves. Give yourself a week of overlap where both accounts are active.

1. List every mailbox, alias, forwarder and catch-all rule in the old control panel, along with quota usage.
2. Create matching mailboxes at the new destination, whether that’s Google Workspace, Microsoft 365, or a dedicated mail host.
3. Copy mail over IMAP, never POP. Tools like imapsync, the Google Workspace data migration service, or a desktop client with both accounts connected will copy folders and read states.
4. Verify message counts folder by folder before you cancel anything. A 10 GB mailbox usually takes 2 to 6 hours to sync on a normal connection.

Keep the old hosting account alive for at least 14 days after the switch. Stragglers always appear, usually an archive folder nobody mentioned.

Keep MX Records Pointed at Mail While the Site Moves

The cleanest migrations change one record: the A record for the root domain and the www CNAME. Everything else in the zone, MX included, stays exactly as it was.

Two habits make this painless. First, manage DNS at a neutral provider (your registrar or Cloudflare) rather than at whichever host currently serves the site, so changing hosts never means rebuilding a zone from memory. Second, drop your TTL to 300 seconds about 24 hours before the cutover, then raise it back to 3600 once things settle.

Related reading: Integrating Autonomous AI Agents into Your WordPress Site.

Related reading: Bedrock and Roots: Modern WordPress Stack Hosting Requirements.

If your new host insists on changing nameservers, recreate the MX and TXT records in the new zone before the nameserver update goes live. That ordering detail is the difference between zero bounced mail and a morning of angry phone calls. Our team does this step manually on every managed WordPress migration and confirms mail delivery before declaring the move finished.

Should Email and Hosting Share a Server?

We advise against it, and not because we want to sell you something else. Mail on a shared web server inherits that server’s IP reputation, so one spammy neighbour can dent your delivery rates for weeks.

Separating the two also makes future moves trivial. When mail lives with a dedicated provider, switching web hosts becomes a single A record change with no mailbox migration attached. Most small teams pay somewhere between $6 and $8 per user per month for hosted business email, which is cheaper than one afternoon of lost orders.

That separation is part of why affordable WordPress hosting often skips mailboxes entirely and focuses resources on PHP workers, caching and backups instead.

Transactional Email From WordPress After the Move

Receipts, password resets and contact form notifications are a separate system from your inbox. WordPress sends them through PHP’s mail() function by default, which many hosts block or rate-limit, so these are the messages that quietly vanish after a migration.

Route them through authenticated SMTP instead. An SMTP plugin connected to a sending service (Postmark, SendGrid, Amazon SES, Brevo or your Google Workspace account) takes about 10 minutes to configure and gives you delivery logs.

• Add the sending service to your SPF record with the provider’s include mechanism, and publish their DKIM keys.
• Set DMARC to p=none first, read the reports for a week or two, then tighten to quarantine. The guidance at dmarc.org explains the policy stages well.
• Send a test of every automated email after cutover: registration, password reset, order confirmation, form notification.

Sites that depend on automated mail feel this hardest. Course platforms and subscription sites send enrolment and renewal notices constantly, which is why course hosting setups and membership site hosting should have SMTP configured on day one rather than after the first complaint.

What to Test in the First 48 Hours

Propagation with a 300 second TTL usually resolves within 15 minutes to 4 hours, though stubborn corporate resolvers can cache for a day. Use that window actively.

• Send mail to and from every mailbox, including one external address like a personal Gmail account.
• Check the message headers on a received email to confirm SPF and DKIM both pass.
• Submit every form on the site and confirm the notification arrives, not just the success message.
• Test webmail login, plus mobile and desktop clients using ports 993 (IMAP) and 587 (SMTP submission).
• Review the old host’s mail queue for anything still being delivered there.

If you’re also changing registrars in the same week, read our walkthrough on transferring a domain and hosting at the same time, because the 60 day registrar lock adds constraints worth knowing about. Building the site locally first? The steps in moving a localhost WordPress site to a live server pair well with this one.

Frequently Asked Questions

Will My Email Stop Working if I Change WordPress Hosts?

No, as long as the MX records stay pointed at your current mail provider, email keeps flowing with zero interruption. Only the A record for your website needs to change, and mail routing ignores A records entirely.

How Long Is Email Down During a DNS Change?

With the TTL lowered to 300 seconds beforehand, most domains complete the switch in 15 minutes to 4 hours. Mail sent during that window is normally queued and retried by the sending server for up to 72 hours rather than lost.

Can I Move Mailboxes to Google Workspace During the Migration?

Yes, and the data migration service copies IMAP mail at roughly 1 to 5 GB per hour per account. Run it while the old host is still active, verify folder counts, then update MX records using the values in Google’s MX record documentation.

Why Did Contact Form Emails Stop After I Migrated?

Roughly nine times out of ten the host blocks PHP’s built-in mail function, so notifications never leave the server. Installing an SMTP plugin and connecting an authenticated sending account fixes it in about 10 minutes.

Do I Need to Recreate SPF and DKIM Records at the New Host?

Only if you also moved the DNS zone, in which case every TXT record must be copied across manually. Missing DKIM keys are the usual reason mail suddenly lands in spam a day or two after a migration.

Move Your Site With Mail Intact

Send us your current MX and TXT records and we’ll map the whole cutover before anything changes, including mailbox transfers if your email still lives on the old server. Our migration team handles the DNS sequencing and tests delivery both ways before we call the job done.