Migrations

Migrate email hosting without breaking WooCommerce order emails

A cutover plan for moving business email providers that keeps WooCommerce order confirmation, shipping, and password-reset emails flowing through the MX and SMTP transition.

Works with Claude / GPT88 uses 3.9

The prompt

migrations-email-hosting-without-breaking-woocommerce-emails
I'm moving [clientsite.com]'s business email from [Google Workspace] to
[Microsoft 365], and the same domain's WooCommerce store depends on transactional
emails (order confirmation, shipping notice, password reset) going out reliably
through [WP Mail SMTP configured against the old Google Workspace SMTP relay]. I can't
have a gap where either inbound business email or outgoing store emails stop working.

Plan this migration so store email delivery survives the provider switch, covering the
parts a generic "how to change email providers" guide won't mention:

1. Two separate things that both depend on the same domain: clarify that MX record
   changes affect INCOMING mail (support@clientsite.com), while WooCommerce's
   transactional emails depend on the OUTGOING SMTP relay configured in WP Mail SMTP
   (or whichever plugin), which is a completely separate setting that won't update
   itself when MX records change.
2. SPF/DKIM/DMARC sequencing: explain the order to update these authentication records
   so outgoing WooCommerce emails don't start landing in spam mid-transition (old
   provider's SPF include still needed until the plugin's SMTP relay is actually
   switched, new provider's DKIM selector needs to be added before that relay goes
   live, not after).
3. The stale-config trap: since WP Mail SMTP or similar plugins often store the old
   provider's SMTP username/password/API key directly in plugin settings (not tied to
   DNS at all), explain why DNS propagating correctly gives false confidence that
   everything is fine when the plugin itself is still authenticating against the old,
   soon-to-be-disabled provider.
4. Verification before and after cutover: the specific test (placing a real test order
   with a real personal email address, checking it doesn't land in spam, checking
   headers for correct SPF/DKIM pass) to run both right before and right after
   switching the plugin's SMTP relay, so a break is caught within minutes instead of
   from a customer support ticket about a missing order confirmation.

Tell me the safe order of operations across DNS, plugin settings, and old-provider
decommissioning so nothing goes dark during the switch.

The part people get wrong here is assuming MX record changes and WooCommerce email delivery are the same problem. They’re not, and the plugin’s SMTP credentials are the one setting that DNS propagation checks will never reveal is broken.