Switching off WordPress emails looks like one job and turns out to be three. An admin and their users get around twenty automatic emails between them: a password reset, a new user welcome, a comment notification, a plugin-update summary, and the rest. Some are safe to turn off and the site keeps working. Several are the only way the admin finds out that an auto-update failed, a plugin updated itself overnight, or someone changed the admin address. A handful, with the password reset chief among them, are the only way users and the admin get back in when something goes wrong.
The job before any filter or plugin is sorting those three groups, so the ones you want quiet stay quiet and the ones standing between a locked-out user and their account stay on.
Safe to drop (notifications-only).
- Comment moderation.
- Comment-approved notifications to the post author.
- The new user admin notification (admin side only).
The site works fine without them; the admin finds out through the dashboard.
Drop with awareness (administrative).
- Automatic update result emails (plugin, theme, core; success and failure share one filter per category).
- Admin email change confirmations.
- Site admin email change notifications.
- The “Login Details” email to a new user, but only on sites where staff create every account (no public registration, no WooCommerce). The
wp_send_new_user_notification_to_userfilter is global, so dropping it on a site with self-service signup breaks onboarding; on a staff-only install, the user still gets credentials through whatever channel staff already use.
These exist so a site owner notices invisible changes, or so a new user gets their password. Suppressing them is a policy choice, not an optimisation. On a single-admin site where you check the dashboard every day, dropping the update notifications is reasonable. On a site that runs background auto-updates on behalf of a client, you want them.
Never drop by default (recovery-critical).
- Password reset requests.
- User-initiated email change confirmations.
- The Recovery Mode fatal-error email.
- GDPR export and erasure confirmations.
The password reset email is a single point of failure for every account on the site; suppress it and the only way back in is WP-CLI or direct database access. The Recovery Mode email carries the login link that lets you fix a fatal error without SSH. The GDPR confirmations are legally significant: if a data export request cannot be confirmed, the request stalls on the user’s side and the clock keeps running on yours.
The full catalog of core emails and the filters that control each one names every filter below. If you are asking the opposite question, enabling notifications WordPress is not sending answers it in the same shape.
Three ways to suppress, ranked by blast radius
Per-event filter in a mu-plugin. The precise option, with no plugin dependency. Each core email has a short-circuit filter named in the catalog (send_retrieve_password_email, send_password_change_email, send_email_change_email, wp_send_new_user_notification_to_admin, auto_plugin_update_send_email, auto_core_update_send_email, among others). Return false from the one you want to kill. One file at wp-content/mu-plugins/np-silence-emails.php:
<?php
// Suppress the three admin-side notifications a solo operator rarely needs;
// leave the recovery-critical filters alone.
add_filter( 'wp_send_new_user_notification_to_admin', '__return_false' );
add_filter( 'auto_plugin_update_send_email', '__return_false' );
add_filter( 'auto_theme_update_send_email', '__return_false' );The mu-plugin location matters: it loads before normal plugins, it cannot be deactivated through the admin UI, and it survives any plugin update or database refresh. Nothing else runs; nothing is at risk of winning a load-order race against it. This is the right default for a production site that wants a specific set of emails off and the rest left alone.
Disable Emails. The blunt option. Replaces wp_mail() with a no-op; everything that routes through the function is silenced. Correct when the site is a staging box, a demo install, or a build where mail must never leave the server. The password reset email goes with everything else, so while the plugin is active, account recovery is the dashboard “set password” link rather than an emailed reset. The plugin ships a must-use loader (Settings > Disable Emails > “Activate must-use plugin”) that handles the pluggable-function race; turn it on. The plugin dossier covers the must-use mode, the multisite behaviour, and the one failure mode (a plugin that bypasses wp_mail() entirely).
An SMTP mailer with per-email controls. The option readers tend to assume all three market leaders offer. In practice, only WP Mail SMTP ships it, at WP Mail SMTP > Settings > Email Controls, and only on the paid tier; the free version does not include the tab. The toggles call the same core filters a mu-plugin would, from the plugin UI rather than a PHP file. FluentSMTP and Post SMTP do not currently ship an equivalent control; their alert settings concern delivery failures, not core-email suppression. If you already run FluentSMTP or Post SMTP and do not want a second plugin, the mu-plugin above is the right setup, not a plugin switch.
Two asymmetries that bite
wp_mail() is pluggable, which cuts both ways. All three paths above hook wp_mail() or its pre-send pipeline. A plugin that calls PHP’s mail() directly, or bundles its own PHPMailer, or opens an SMTP socket, is invisible to any of them. The pattern most likely to bypass is a plugin that writes mail through a provider SDK (SendGrid, Mailgun, or Postmark client libraries); some older form plugins and a few membership plugins fit the same shape. If “no outbound mail” is the goal rather than “no WordPress core mail”, the correct layer is the host (block the outbound ports) or a captive relay (Mailpit, a dev-mail catcher that accepts SMTP locally and never forwards), not a PHP toggle.
Empty recipients vs. short-circuit. You can “disable” an email by filtering its recipient list to an empty array, or by returning false from one of the send_* filters above, or by returning early from the pre_wp_mail filter (WordPress 5.7+). The first still builds the message and runs the pre-send filters; only the delivery is dropped. The second two skip the body of the mail function entirely, before wp_mail() is even called in the send_* case or before wp_mail() does any real work in the pre_wp_mail case. The per-email send_* filters are the right default for suppression; recipient-array filtering is interesting only when the goal is to redirect, not suppress.
The question before the question
If the reason to disable is “my inbox is full of WordPress noise”, suppression is rarely the right fix. Change the admin email to one that routes to a shared inbox or a label-and-archive rule. Narrow who gets each notification (the admin-side registration email takes a filter that lets you return a different recipient). Add an SMTP relay with logging so you can see what fires and decide per-event. Suppression is appropriate for a staging environment, a single-admin site that lives in the dashboard, or a specific-event allergy; for every other case, the right fix is routing or scope, not silence.