Introduction

A WordPress site can survive a host migration and still stop sending mail through WP Mail SMTP. Contact forms fail, password resets never arrive, and test emails start throwing connection or authentication errors even though the website itself looks healthy. That usually means the migration changed something around the mail path rather than the WordPress content: the SMTP host is wrong, saved credentials did not carry over cleanly, the new host blocks outbound SMTP, or the domain’s mail and TLS setup no longer matches the plugin configuration. Treat this as a mail transport problem anchored inside WordPress, not as a generic site migration issue.

Symptoms

  • WP Mail SMTP test emails fail after the site was moved to a new host
  • Contact form notifications, WooCommerce emails, or password reset messages stop arriving
  • The plugin reports connection failed, authentication failed, or TLS errors
  • WordPress works normally in the browser, but email sending breaks on the new server
  • The old host could send mail with the same plugin settings, but the new host cannot
  • Only the WordPress site is affected while other mailboxes or apps still send normally

Common Causes

  • The SMTP hostname, port, encryption mode, or mailer setting no longer matches the new environment
  • Saved SMTP credentials, app passwords, or API keys were lost, truncated, or invalid after migration
  • The new host blocks outbound SMTP ports or restricts remote mail connections
  • DNS, TLS, or the sending domain’s identity no longer lines up with the configured From address
  • The site moved to a different PHP, cURL, or OpenSSL environment that handles SMTP differently
  • The plugin configuration was partly restored, but constants or server-side secrets were not

Step-by-Step Fix

  1. Run a fresh WP Mail SMTP test email and read the exact debug output before changing settings, because the first useful split is whether the plugin cannot connect, cannot authenticate, or sends successfully but the message later fails delivery.
  2. Verify the configured mailer, SMTP hostname, port, encryption mode, and From address inside WP Mail SMTP, because migrations often preserve the plugin but leave it pointing at the old provider, old port, or old TLS expectation.
  3. Re-enter or regenerate the mail credentials if the plugin uses SMTP authentication, app passwords, or API keys, because copied secrets frequently break during migration even when the visible plugin settings still look correct.
  4. Check whether the new host allows outbound connections to the required SMTP or API endpoint, because many hosting providers restrict remote SMTP on common ports and this can make a previously working WP Mail SMTP setup fail immediately after cutover.
  5. Confirm the server can resolve and reach the configured mail host with the expected TLS behavior, because DNS resolution issues, missing CA trust, or TLS handshake problems on the new host can look like generic plugin failure from the WordPress side.
  6. Review the sending domain and From address alignment, including SPF, DKIM, and the identity expected by the mail provider, because a migrated site may keep using an old From address or domain that no longer matches the authenticated mail service.
  7. Check whether the site relies on environment constants, config overrides, or server-side secret injection for WP Mail SMTP settings, because the database copy may have migrated while the actual credentials stayed behind on the old host.
  8. Test with a clean alternate mailer path if needed, such as re-saving the current mailer or temporarily trying the provider’s supported integration, because that quickly separates plugin configuration corruption from a deeper host-level mail restriction.
  9. After each fix, retest the plugin, a live site email flow, and mailbox receipt, then document the final mailer settings and any host-specific SMTP restrictions, because WordPress mail problems tend to reappear on the next migration if the working path is not recorded.