Disable Emails by 
WebAware replaces WordPress’s wp_mail() function with a no-op. Any code that routes outbound mail through wp_mail is silenced; any code that bypasses the function is not. That distinction is the whole story.
Active installs sit above 30,000, the rating is 5.0 across 20 reviews, and the current release (1.8.3, January 2026) tests against WordPress 7.0. The plugin requires WordPress 5.5 and PHP 5.6, ships under GPLv2-or-later, and is maintained by WebAware, an Australian developer. It is free and donation-supported; there is no paid tier.
How it works
The plugin’s includes/bootstrap.php defines wp_mail() only if WordPress has not already defined it. The replacement instantiates a private PHPMailerMock and calls its wpmail() method with the standard mail arguments. The mock accepts every PHPMailer call (addAddress, Subject, Body, AddAttachment) and never calls send(). The standard pre-send filters continue to fire against the mock: wp_mail, wp_mail_from, wp_mail_from_name, wp_mail_content_type, wp_mail_charset, and the phpmailer_init action all run as they would in core. Form plugins and other code that hooks the pre-send pipeline see what they expect to see.
The post-send actions are a different story. Core’s wp_mail() fires wp_mail_succeeded on a successful send and wp_mail_failed on a failure; the mock fires neither. The function simply returns true. Logger plugins that listen on wp_mail_succeeded or wp_mail_failed rather than on the wp_mail filter itself will not see the captured messages. The pairing with a logger that hooks wp_mail directly (covered below) sidesteps this; the pairing with a logger that listens on the result actions does not.
wp_mail() is a WordPress pluggable function, meaning the first definition wins. Whichever plugin happens to define it first claims the slot. That detail is the load-order trap covered below.
What it stops and what it does not
Anything that calls wp_mail() is captured: WordPress core notifications (password resets, new user emails, admin alerts), every major form plugin (Contact Form 7, Gravity Forms, WPForms, Fluent Forms), WooCommerce transactional flows, every SMTP plugin in the ecosystem, and the long tail of plugins that simply call the function and trust it.
Anything that bypasses wp_mail() is invisible to it. Three patterns commonly survive:
- A plugin that calls PHP’s
mail()directly. Rare in modern releases, but present in older or single-purpose plugins. - A plugin that bundles its own PHPMailer (or Symfony Mailer, or a vendor SDK) and ships outbound mail through its own pipeline. Marketing plugins that integrate with external services often work this way.
- A WordPress installation that has had
wp_mail()redefined upstream of Disable Emails by another pluggable-function competitor.
The plugin’s name oversells the contract slightly. The accurate framing is “Disable wp_mail.”
The pluggable race and mu-plugin mode
Because wp_mail() is pluggable, plugin load order decides whether Disable Emails wins. Standard plugins load alphabetically by directory name, and disable-emails usually resolves the race in its favour, but the moment another plugin defines wp_mail() from a higher-priority slot, Disable Emails is silently inert. The behaviour is the worst possible failure mode: the plugin still appears active, the settings page still loads, and mail still ships.
The fix is the must-use loader. Settings > Disable Emails exposes a single “Activate must-use plugin” button. The button writes a small PHP shim into wp-content/mu-plugins/ that includes the main plugin from the standard wp-content/plugins location. Must-use plugins load before normal plugins (and before network-activated plugins on multisite), so the pluggable definition fires first and no normal plugin can win the race. The mu-plugin mode also survives a database refresh, which is the point of installing the plugin in the first place: a development site cloned from production keeps wp_mail disabled even after the clone, with no post-clone activation step.
On a single-site install, the mu-plugin mode is the default recommendation. The cost is negligible.
Multisite
On a multisite network, the mu-plugin loader applies to every site on every network. The vendor’s readme states this explicitly. The failure mode is straightforward: a subsite that needed to send a notification goes silent with no warning, log entry, or admin notice. The site appears healthy because nothing errored; wp_mail returned true.
Before flipping the mu-plugin switch on a multisite, the question is not “does this dev subsite need mail off?” but “does every subsite on every network need mail off?” The answer is usually yes on a dedicated staging or development network and usually no on any network where at least one subsite is expected to send mail. If the answer is mixed, the standard plugin mode (activated per subsite) is the right default, with awareness that it loses the pluggable race to any earlier-loaded plugin.
When operators reach for it
Four situations recur:
- A staging or local environment cloned from a production database, where the goal is to stop WordPress emails before notifications fire to real recipients.
- A bulk data import (users, orders, posts) on a production-like site, where the import scripts trigger
wp_mailthousands of times. - A fresh subsite added to an existing multisite, where SMTP has not yet been configured and the default
wordpress@hostsender would otherwise leak. - A maintenance window where the site needs to stay online but silent for a few hours.
The common thread is that each environment is short-lived or contained. The plugin is not designed to be the permanent answer to “this site should never send mail”; that goal lives at the MTA or the host, where outbound ports can be blocked and no PHP-level toggle can be quietly undone by a plugin update.
Where it sits against alternatives
WP Mail SMTP, FluentSMTP, and Post SMTP each ship a “stop sending” or “test mode” option, but those plugins exist to send mail and the toggle is a side switch on a working configuration. Using the toggle as a long-term silencer means the mailer’s settings (provider credentials, From overrides, signing) sit one click away from active. Disable Emails inverts the default: the plugin’s whole purpose is the off state.
Host-level outbound blocks (closing port 25, 465 or 587 at the firewall, or running a captive MTA like Mailpit) catch every PHP sender regardless of which function it called. For a permanent “this host never delivers mail” guarantee, that is the correct layer. Disable Emails is the right answer when the host-level lever is not available (managed hosting, shared environments, multisite tenants without root) or when the operator wants wp_mail to report success rather than silently 5xx at the SMTP layer.
The closest sibling is Log Emails, from the same vendor. Log Emails records every wp_mail call to the database without disabling it, and it hooks the wp_mail filter rather than the post-send actions, so pairing it with Disable Emails yields the canonical “captured but not delivered” setup on a dev box: the form fires, the logger records the message body and headers, Disable Emails drops the send. Check & Log Email does the logging half with a richer admin UI and a resend action and hooks wp_mail in the same way; it pairs equally cleanly. Loggers that listen on wp_mail_succeeded or wp_mail_failed instead of on wp_mail are the ones that go quiet under this pairing, for the reasons spelled out in How it works.
Assessment
Disable Emails is the right install for a staging, development, or freshly imported WordPress environment that needs wp_mail silenced without disturbing the production mailer configuration. The plugin is free, narrowly scoped, and maintained, and the mu-plugin mode handles the load-order trap that defeats casual installs. Pair it with a logger that hooks wp_mail directly when the question is “what would have gone out?” and leave it alone when the question is “is this host capable of delivering mail at all?”
It is the wrong install for a site that needs a permanent guarantee against any outbound mail. A plugin update, a load-order shift, or a sender that bypasses wp_mail defeats it. For that requirement, the host’s firewall or a captive MTA is the correct layer. The plugin name promises more than wp_mail() can actually deliver, and the gap is where operators get into trouble.
Plugin data verified June 2026 against 
wordpress.org/plugins/disable-emails and the plugin source on the WordPress plugin SVN.