Why Does WordPress Send So Many Emails? A Guide to Every Core Notification (And Which Ones You Need)

Your WordPress site sends emails. Sometimes, it sends a lot of emails. Password resets, comment moderation alerts, automatic update reports, data privacy confirmations,… the list goes on.

But what does WordPress actually send? When? And, more importantly, which ones do you actually need?

This guide documents every single email sent by WordPress core (based on the definitive wp_mail documentation), explains why each exists, and shows you exactly how to disable the ones you don’t want.

Table of Contents

  1. How WordPress Sends Emails (The Basics)
  2. Comment Emails
  3. Admin Email Change Notifications
  4. User Email & Password Change Emails
  5. Personal Data Request Emails (GDPR)
  6. Automatic Update Emails
  7. New User & New Site Emails (Multisite)
  8. Other Core Emails (Installation, Fatal Errors)
  9. How to Disable Any WordPress Email

1. How WordPress Sends Emails (The Basics)

All emails sent by WordPress go through the wp_mail() function. This is a pluggable function, meaning you can override it entirely with a custom plugin.

Global filters that affect every email:

FilterPurpose
wp_mail_fromChange the “From” email address
wp_mail_from_nameChange the “From” name
wp_mail_content_typeChange email format (text/html)
pre_wp_mailIntercept or prevent an email before it’s sent

Global actions:

  • phpmailer_init: Modify the PHPMailer object directly
  • wp_mail_succeeded: Run code after an email sends successfully
  • wp_mail_failed: Run code if an email fails

2. Comment Emails

Email #1: Comment Awaiting Moderation

When it sends: A visitor submits a comment that gets held for moderation.

Sent to: Site Admin + Post Author (if they can edit comments)

Subject: [Site Name] Please moderate: "Comment Title"

How to disable:

  • Uncheck “Email me whenever” → “A comment is held for moderation” in Settings → Discussion
  • Or return false from the notify_moderator filter
  • Or remove wp_new_comment_notify_moderator from the comment_post hook

Email #2: Comment Published

When it sends:

  • A comment is automatically approved
  • A user adds a note to a block (WordPress 6.9+ feature)
  • A previously moderated comment is approved

Sent to: Post Author

Subject: [Site Name] Comment: "Comment Title" (or Pingback/Trackback/Note variations)

How to disable:

  • Uncheck “Email me whenever” → “A comment is held for moderation” (yes, same setting)
  • Or return false from the notify_post_author filter
  • Or remove wp_new_comment_notify_postauthor from the comment_post hook

Verdict: Keep these if you run a blog with active commenting. Disable if comments are rare or spam-heavy.

3. Admin Email Change Notifications

Email #3: Admin Email Change Attempted

When it sends: Someone (usually an admin) tries to change the Administration Email Address in Settings → General.

Sent to: The proposed new email address (for confirmation)

Subject: [Site Name] New Admin Email Address

How to disable: Remove update_option_new_admin_email from the add_option_new_admin_email and update_option_new_admin_email hooks.

Verdict: Keep this. It prevents account takeover if an attacker gains admin access.

Email #4: Admin Email Changed (Confirmation)

When it sends: After someone clicks the confirmation link from the email above.

Sent to: The old admin email address (notification of change)

Subject: [Site Name] Admin Email Changed

How to disable: Return false from the send_site_admin_email_change_email filter.

Verdict: Keep this. You want to know if your admin email has been changed without your knowledge.

Emails #5 & #6: Network Admin Email Changes (Multisite Only)

Same as above, but for multisite network admin email. Disable similarly using send_network_admin_email_change_email filter.

4. User Email & Password Change Emails

Email #7: Password Reset Request

When it sends: A user clicks “Lost your password?” and submits their email.

Sent to: The user requesting the reset

Subject: [Site Name] Password Reset

How to disable:

  • Return false from the send_retrieve_password_email filter
  • Or return an empty message from the retrieve_password_message filter

Verdict: Keep this. If you disable it, users cannot reset their own passwords.

Email #8: User Resets Their Password (Notification to Admin)

When it sends: A user successfully resets their password via the “Lost your password?” flow.

Sent to: Site Admin

Subject: [Site Name] Password Changed

How to disable:

  • Remove wp_password_change_notification from the after_password_reset hook
  • Or overwrite the pluggable wp_password_change_notification() function

Verdict: Optional. Useful for security monitoring, but noisy on large sites.

Email #9: User Changes Their Password (While Logged In)

When it sends: A logged-in user changes their password from their profile screen.

Sent to: The user themselves

Subject: [Site Name] Password Changed

How to disable: Return false from the send_password_change_email filter.

Verdict: Keep this. Users should know when their password has been changed (in case it wasn’t them).

Email #10: User Attempts to Change Email Address

When it sends: A logged-in user tries to change their email address on their profile screen.

Sent to: The proposed new email address (for confirmation)

Subject: [Site Name] Email Change Request

How to disable: Remove send_confirmation_on_profile_email() from the personal_options_update hook.

Verdict: Keep this. Email change confirmation prevents account hijacking.

Email #11: User Changes Email Address (Confirmation)

When it sends: After the user clicks the confirmation link from the email above.

Sent to: The user’s old email address (notification)

Subject: [Site Name] Email Changed

How to disable: Return false from the send_email_change_email filter.

Verdict: Keep this. Tells the user their email has changed (in case it was fraud).

5. Personal Data Request Emails (GDPR)

Email #12: Export or Erasure Request Created

When it sends: An admin creates or resends a personal data request from Tools → Export/Erase Personal Data.

Sent to: The requester’s email address

Subject: [Site Name] Confirm Action: Export Personal Data (or Erasure)

How to disable: Unknown, may require removing the admin pages entirely.

Verdict: Keep this. Required for GDPR compliance.

Email #13: User Confirms Request

When it sends: The user clicks the confirmation link from the email above.

Sent to: Site Admin (single site) or Network Admin (multisite)

Subject: [Site Name] Action Confirmed: Export Personal Data

How to disable: Remove _wp_privacy_send_request_confirmation_notification() from the user_request_action_confirmed hook.

Verdict: Keep this. Admins need to know when a request is ready to process.

Email #14: Admin Sends Export Link

When it sends: An admin clicks “Send Export Link” next to a confirmed export request.

Sent to: The requester’s email address

Subject: [Site Name] Personal Data Export

How to disable: Remove wp_privacy_send_personal_data_export_email() from the wp_privacy_personal_data_export_page hook.

Verdict: Keep this. Required to fulfill the request.

Email #15: Admin Fulfills Erasure Request

When it sends: An admin clicks “Erase Personal Data” or “Force Erase Personal Data” next to a request.

Sent to: The requester’s email address

Subject: [Site Name] Erasure Request Fulfilled

How to disable: Remove _wp_privacy_send_erasure_fulfillment_notification() from the wp_privacy_personal_data_erased hook.

Verdict: Keep this. Required for GDPR compliance.

6. Automatic Update Emails

Email #16: Automatic Plugin/Theme Update Results

When it sends: Background automatic updates for plugins/themes complete, either successfully or with failures.

Sent to: Site Admin (single site) or Network Admin (multisite)

Subject: Varies:

  • [Site Name] Some plugins and themes have automatically updated
  • [Site Name] Some plugins have failed to update
  • (and similar variations)

How to disable: Return false from auto_plugin_update_send_email or auto_theme_update_send_email filters.

Verdict: Keep failure emails, disable success emails. You need to know when updates fail. You don’t need to know when they work.

Email #17: Automatic Core Update Results

When it sends: Background automatic updates for WordPress core complete, success or failure.

Sent to: Site Admin or Network Admin

Subject: Varies:

  • [Site Name] Your site has updated to WordPress X.X
  • [Site Name] WordPress X.X is available. Please update!
  • [Site Name] URGENT: Your site may be down due to a failed update

How to disable: Return false from the auto_core_update_send_email filter.

Verdict: Keep failure/urgent emails, disable success emails. The “URGENT” email is critical, it means your site may be down.

Email #18: Full Debug Log (Development Only)

When it sends: You’re using a development version of WordPress, it’s not under version control, and an update completes or fails.

Sent to: Site Admin or Network Admin

Subject: [Site Name] Background Update Failed or Background Update Finished

How to disable: Return false from the automatic_updates_send_debug_email filter.

Verdict: Disable this unless you’re actively developing WordPress core.

7. New User & New Site Emails (Multisite Only)

Emails #19–24: Multisite User and Site Creation Notifications

WordPress Multisite sends a complex web of emails when:

  • An existing user is invited to a site
  • A new user is invited to join a site
  • A new user account is created
  • A user activates their account
  • A new site is created
  • A user registers for a new site
  • A user activates their new site

How to disable most of them:

  • Uncheck “Skip Confirmation Email” when adding users (to send or not send)
  • Filter the registrationnotification option value
  • Return false from specific filters like wpmu_signup_user_notification, wpmu_welcome_user_notification, newblog_notify_siteadmin, etc.

Verdict for most site owners: These are essential for multisite user management. Disable only if you have a custom onboarding flow.

8. Other Core Emails

Email #25: New WordPress Installation

When it sends: WordPress is initially installed.

Sent to: Site Admin

Subject: New WordPress Site

How to disable: Overwrite the pluggable wp_new_blog_notification() function.

Verdict: One-time email. No need to disable, you only see it once.

Email #26: Fatal Error (Recovery Mode Not Active)

When it sends: A fatal error occurs in a plugin or theme, and Recovery Mode is not active.

Sent to: Site Admin (or the email defined in RECOVERY_MODE_EMAIL constant)

Subject: [Site Name] Your Site is Experiencing a Technical Issue

How to disable:

  • Define WP_DISABLE_FATAL_ERROR_HANDLER as true
  • Or return false from the wp_fatal_error_handler_enabled filter

Verdict: DO NOT DISABLE. This email tells you your site is broken. You need it.

9. How to Disable Any WordPress Email

You have several methods, from simplest to most advanced.

Method 1: Dashboard Settings (Easiest)

Settings → Discussion → “Email me whenever”, uncheck options for comment emails.

Method 2: Use a Plugin

Plugins like “Disable Emails” or “Email Control” let you block specific email types via UI.

Method 3: Return False from a Filter (Most Common)

Add to your theme’s functions.php or a custom plugin:

php

// Disable password change notification to admin
add_filter('send_password_change_email', '__return_false');

// Disable automatic update success emails (keep failures)
add_filter('auto_plugin_update_send_email', function($send, $type, $data) {
    return $type === 'fail' ? $send : false;
}, 10, 3);

Method 4: Remove the Action

php

remove_action('comment_post', 'wp_new_comment_notify_moderator');

Method 5: Overwrite the Pluggable Function (Advanced)

Create a file in wp-content/mu-plugins/disable-emails.php:

php

<?php
function wp_new_user_notification($user_id, $deprecated = null, $notify = '') {
    // Do nothing, email never sends
}

Final Thoughts

WordPress sends emails for good reasons: security, user management, legal compliance, and site reliability. But not every site needs every email.

Start with these changes:

  1. Disable automatic update success emails (keep failures)
  2. Disable admin notifications for password changes (unless you’re a high-security site)
  3. Keep all security-related emails (admin email changes, fatal errors, password resets)

And remember: all emails pass through wp_mail(). A single filter can catch them all:

php

add_filter('pre_wp_mail', function($null, $atts) {
    // Log, modify, or block every email
    return $null;
}, 10, 2);

Now you know exactly what WordPress is sending, and how to stop it when you need to.

Was this post helpful?
Buy us a coffee!
Categories: How-to & Tutorials
Tags:

Free eBook!

Subscribe to our newsletter to receive it free!