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.
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.