Migrating a WordPress multisite installation from one server to another can be a complex process. Between database updates, URL rewrites, file permissions, and reconfigurations, there’s a lot that can go wrong. But one of the most elusive and frustrating issues site administrators often run into post-migration is the sudden, unexplained failure of email notifications—particularly in multisite networks using subdomains.
TL;DR
If you’ve migrated a WordPress multisite installation using subdomains and suddenly your email notifications stop working, the problem may lie in a forgotten constant in wp-config.php. Email delivery on your subdomain sites might be hampered if a multisite configuration constant isn’t properly defined or adjusted. This article explores how a missing or misconfigured DOMAIN_CURRENT_SITE setting can disrupt email functionality and how correcting it brings your notifications back to life.
Understanding the Problem: Email Notifications Vanish Post-Migration
Everything appeared to go smoothly. The database was migrated, files and media transferred, URLs updated, plugins reactivated—and the sites loaded just fine on the new host. But then came the discovery: contact forms on subdomain sites weren’t sending emails anymore. Admin notifications didn’t arrive. Password reset emails, comment alerts—gone into the void.
Several tests confirmed it wasn’t a problem with the hosting provider’s email server, nor was it a plugin conflict. The issue was specific to the subdomains within the multisite setup. Main site emails still worked, further deepening the mystery.
So, what changed during migration that disrupted WordPress’s ability to send emails? The answer lay—as it often does—with a single line in wp-config.php.
Why WordPress Needs Proper Multisite Constants
When you set up a WordPress multisite network, especially one using subdomains (e.g., site1.example.com, site2.example.com), WordPress relies on constants in wp-config.php to determine network behavior. These constants include:
DOMAIN_CURRENT_SITEPATH_CURRENT_SITESITE_ID_CURRENT_SITEBLOG_ID_CURRENT_SITE
Out of these, DOMAIN_CURRENT_SITE plays a crucial role in identifying which domain the main site (and by extension, all sub-sites) exist under. If this constant is improperly set—or omitted entirely following a migration—email functions for subdomain installations may silently fail.
How the Multisite Constants Affect Email Functions
WordPress uses the wp_mail() function, which in turn uses the PHPMailer class. When constructing email headers, PHPMailer often includes the server’s name or hostname as the sending domain. If WordPress hasn’t properly identified a subdomain through its configuration, it might default wrong values that break SPF, DKIM, or DMARC validations—causing mail servers to reject the emails altogether.
What’s worse: there are no outright failure messages. The wp_mail() function still returns true, and the plugins think their job is done, when in reality, the messages vanish into ether.
email failed notification wordpress
Common Migration Oversights
Most WordPress migrations focus on:
- Exporting and importing the database
- Transferring files via FTP or SSH
- Updating hard-coded URLs in the database
- Resetting file permissions
But very few check whether wp-config.php still includes the vital multisite constants that provide context to the entire network. Even hosting migration tools may overlook or fail to properly rewrite those entries.
The Fix: Adjusting DOMAIN_CURRENT_SITE
In one specific multisite migration (from SiteGround to Cloudways), the issue ultimately traced back to this line in wp-config.php:
define('DOMAIN_CURRENT_SITE', 'old-domain.com');It was still pointing to the original domain used during the network’s initial setup. Since the new environment used network.example.com, WordPress didn’t recognize the subdomains as belonging to the same network, causing internal confusion that impacted mail generation parameters.
The fix?
define('DOMAIN_CURRENT_SITE', 'network.example.com');After adjusting this and clearing the object cache, all subdomain-based email notifications resumed functioning as expected. Password resets reached users. Contact form submissions delivered instantly. Even admin emails for new plugin installations worked again.
A Checklist to Prevent This Problem
When migrating a multisite network—especially one using subdomains—be sure to follow this additional step-by-step checklist:
- Open
wp-config.phpand review the multisite constants. - Ensure
DOMAIN_CURRENT_SITEreflects your new domain or subdomain. - Confirm that
PATH_CURRENT_SITEis correct (usually just ‘/’ unless you’re using a nested install). - Use tools like
WP Mail LoggingorCheck Emailplugin to test actual email delivery. - Double check your SPF, DKIM, and DMARC DNS records for your domain so your emails aren’t being flagged.
wp config file multisite constants
Other Potential Contributors
While a misconfigured wp-config.php is a primary cause, it isn’t the only one to monitor during a migration:
- Incorrect SMTP settings: If your server needs SMTP, incorrect plugin settings may cause silent drops.
- Changed server IP addresses: May interfere with SPF records tied to original sending domains.
- Missing cron jobs: WordPress uses WP-Cron for scheduling—email jobs may never run if WP-Cron fails.
Lessons Learned
Migrations are never quite as simple as a copy-paste operation. Particularly within WordPress multisite networks that use subdomains, there’s a hidden web of dependencies and configuration flags that make things tick behind the scenes. The beauty of WordPress is its flexibility, but that flexibility means responsibility when moving environments.
Email failures after migration are often brushed off as plugin issues or misconfigured mail servers. But as we’ve uncovered, sometimes the fix is as simple as correcting one critical constant that tells WordPress who it is and where it belongs.
Wrapping It Up
If you’re facing WordPress email issues after moving a multisite with subdomains, don’t lose hours troubleshooting plugins or server settings right away. Instead, open your wp-config.php, look for the DOMAIN_CURRENT_SITE constant, and make sure it’s pointing to the correct hostname for your new environment.
Email reliability is more than a convenience—it’s a necessity for user trust, security, and operational continuity. Ensuring your multisite configuration is precise is the first step toward keeping that trust intact every time you hit “Send.”
