June 2026: New and refreshed site!

Download Now

nanoPost

The WordPress Email Authority

Every Email WordPress Sends (and How to Control Each One)

·

WordPress core sends email in response to roughly twenty distinct events: comments awaiting moderation, password resets, new user registrations, automatic update results, GDPR data requests, and several others. Every one of these emails passes through the pluggable wp_mail() function, which means every one of them is routable through an SMTP plugin and controllable via filters.

This reference documents each email, its trigger, its default recipients, and the hooks that control it. The underlying data is drawn from John Blackbourn’s johnbillion/wp_mail repository (GPL-licensed, updated for WordPress 7.0); nanoPost adds operator context — which emails matter for deliverability, which ones generate support tickets, and which ones you can safely suppress.

How WordPress email works

All outgoing email from WordPress core (and well-behaved plugins) passes through wp_mail(), a pluggable function defined in wp-includes/pluggable.php. When you install a mailer plugin like WP Mail SMTP or FluentSMTP, that plugin replaces wp_mail() to route messages through your configured SMTP relay or API. Plugins that call PHP’s mail() directly bypass this — they are the common source of confusion when “some emails work and some don’t.”

Global hooks that apply to every wp_mail() call:

Hook Type Purpose
wp_mail filter Modify the entire email array (to, subject, message, headers, attachments)
pre_wp_mail filter Short-circuit sending entirely (return non-null to prevent send)
wp_mail_from filter Override the From address
wp_mail_from_name filter Override the From name
wp_mail_content_type filter Override content type (text/plain vs text/html)
wp_mail_charset filter Override character set
phpmailer_init action Direct access to the PHPMailer instance before send
wp_mail_succeeded action Fires after successful send
wp_mail_failed action Fires after failed send (carries WP_Error)

The wp_mail_failed action is what email logging plugins hook into to detect delivery failures. If your SMTP relay rejects a message, this is where the error surfaces in WordPress.

Comments

Awaiting moderation

Sent when a comment, pingback, or trackback requires approval.

  • To: Site admin + post author (if they can edit comments)
  • Subject: [%1$s] Please moderate: "%2$s"
  • Function: wp_notify_moderator() (pluggable)
  • Filters: comment_moderation_recipients, comment_moderation_subject, comment_moderation_text, comment_moderation_headers
  • Disable: Return false from notify_moderator filter; remove wp_new_comment_notify_moderator from comment_post hook; or set Discussion settings to not email on moderation

Operator note: On sites with active comment sections, moderation emails can be the highest-volume core email. If you moderate via the WordPress admin rather than email, disabling these reduces noise without operational cost.

Comment published

Sent when a comment is automatically approved, a note is added (WP 6.9+), or a previously moderated comment is approved.

  • To: Post author
  • Subject: [%1$s] Comment: "%2$s" (also Pingback/Trackback variants)
  • Function: wp_notify_postauthor() (pluggable)
  • Filters: comment_notification_recipients, comment_notification_subject, comment_notification_text, comment_notification_headers
  • Disable: Return false from notify_post_author filter; remove wp_new_comment_notify_postauthor from comment_post hook

Password and account changes

Password reset request

Sent when a user clicks “Lost your password?” or an admin sends a reset link.

  • To: User requesting the reset
  • Subject: [%s] Password Reset
  • Function: retrieve_password()
  • Filters: retrieve_password_title, retrieve_password_message, retrieve_password_notification_email
  • Disable: Return false from send_retrieve_password_email

Operator note: This is the single most important transactional email for user experience. If password reset emails don’t arrive, users cannot recover their accounts. This email alone justifies configuring a proper SMTP relay on every WordPress site. Route it through SMTP2GO, Postmark, or any authenticated relay — never rely on PHP mail() for this.

Password changed (notification to admin)

Sent to the site admin after a user resets their password.

  • To: Site admin
  • Subject: [%s] Password Changed
  • Function: wp_password_change_notification() (pluggable)
  • Filters: wp_password_change_notification_email
  • Disable: Remove wp_password_change_notification from after_password_reset hook

Password changed (notification to user)

Sent to the user when they change their own password while logged in.

  • To: User
  • Subject: [%s] Password Changed
  • Function: wp_update_user()
  • Filters: password_change_email
  • Disable: Return false from send_password_change_email

Email change request

Verification email sent to the proposed new address when a user tries to change their email.

  • To: Proposed new address
  • Subject: [%s] Email Change Request
  • Function: send_confirmation_on_profile_email()
  • Filters: new_user_email_content
  • Disable: Remove send_confirmation_on_profile_email() from personal_options_update hook

Email change confirmed

Notification sent after the user confirms the new email address.

  • To: User
  • Subject: [%s] Email Changed
  • Function: wp_update_user()
  • Filters: email_change_email
  • Disable: Return false from send_email_change_email

Admin email changes

Site admin email change attempt

Verification email when changing the site admin email in Settings > General.

  • To: Proposed new admin email
  • Subject: [%s] New Admin Email Address
  • Function: update_option_new_admin_email()
  • Filters: new_admin_email_subject, new_admin_email_content

Site admin email changed

Confirmation to the old address after the change completes.

  • To: Previous admin email
  • Subject: [%s] Admin Email Changed
  • Function: wp_site_admin_email_change_notification()
  • Filters: site_admin_email_change_email
  • Disable: Return false from send_site_admin_email_change_email

New users

New user created (single site)

Two emails from wp_new_user_notification() (pluggable):

To site admin:

  • Subject: [%s] New User Registration
  • Filter: wp_new_user_notification_email_admin
  • Disable: Return false from wp_send_new_user_notification_to_admin

To new user:

  • Subject: [%s] Login Details
  • Filter: wp_new_user_notification_email
  • Disable: Return false from wp_send_new_user_notification_to_user

Operator note: The “Login Details” email to new users is the second-most important transactional email after password resets. On WooCommerce sites, this is the account-creation email customers receive at checkout. If it doesn’t arrive, customers assume registration failed.

Personal data requests (GDPR)

Export/erasure request created

Sent when an admin creates a data export or erasure request.

  • To: Requester’s email
  • Subject: [%1$s] Confirm Action: %2$s
  • Function: wp_send_user_request()
  • Filters: user_request_action_email_subject, user_request_action_email_content, user_request_action_email_headers

User confirms request

Notification to site admin (or network admin on Multisite).

  • Subject: [%1$s] Action Confirmed: %2$s
  • Function: _wp_privacy_send_request_confirmation_notification()
  • Filters: user_request_confirmed_email_to, user_request_confirmed_email_subject, user_request_confirmed_email_content

Data export link sent

  • To: Requester
  • Subject: [%s] Personal Data Export
  • Function: wp_privacy_send_personal_data_export_email()

Erasure completed

  • To: Requester
  • Subject: [%s] Erasure Request Fulfilled
  • Function: _wp_privacy_send_erasure_fulfillment_notification()

Operator note: GDPR emails are legally significant. If a data export request email doesn’t arrive, the user cannot confirm the request and the process stalls. These should always route through an authenticated SMTP relay, not PHP mail().

Automatic updates

Plugin/theme update results

Sent after background plugin or theme updates complete or fail.

  • To: Site admin (or network admin on Multisite)
  • Subjects: Success: [%s] Some plugins were automatically updated; Failure: [%s] Some plugins have failed to update
  • Function: WP_Automatic_Updater::after_plugin_theme_update()
  • Filter: auto_plugin_theme_update_email
  • Disable: Return false from auto_plugin_update_send_email or auto_theme_update_send_email

Core update results

  • Subjects: Success: [%1$s] Your site has updated to WordPress %2$s; Critical failure: [%1$s] URGENT: Your site may be down due to a failed update
  • Function: WP_Automatic_Updater::send_email()
  • Disable: Return false from auto_core_update_send_email

Operator note: The “URGENT: Your site may be down” email is the one you do not want to miss. Ensure your admin email address is current and routed through a working relay. Failed update notifications are operationally critical — they tell you the site may be serving errors.

Fatal errors (Recovery Mode)

Sent when a fatal error occurs in a plugin or theme and Recovery Mode is not active.

  • To: Site admin (or value of RECOVERY_MODE_EMAIL constant)
  • Subject: [%s] Your Site is Experiencing a Technical Issue
  • Function: send_recovery_mode_email()
  • Filters: recovery_mode_email, recovery_email_support_info, recovery_email_debug_info
  • Disable: Define WP_DISABLE_FATAL_ERROR_HANDLER as true

Operator note: This email contains the recovery mode login link. If it doesn’t arrive, the admin must access recovery mode via WP-CLI or direct file editing. Route through SMTP.

Other core emails

Initial installation

  • To: Site admin
  • Subject: New WordPress Site
  • Function: wp_new_blog_notification() (pluggable)
  • Filter: wp_installed_email

Site deletion request (Multisite)

  • To: Site admin
  • Subject: [%s] Delete My Site
  • Disable: Not possible

Multisite-specific emails

Multisite adds additional emails for site creation, user invitations, and activation flows. Network admin email change follows the same pattern as site admin email change with update_network_option_new_admin_email() and the new_network_admin_email_content filter. New site registration uses wpmu_signup_blog_notification() and wpmu_welcome_notification(). Refer to the full multisite documentation for the complete hook reference.

The emails that matter most

For a typical WordPress site with an SMTP relay configured, all of these emails flow through the relay transparently. The ones that generate the most support tickets when delivery fails:

  1. Password reset requests — users locked out of accounts
  2. New user / WooCommerce account creation — customers assume registration failed
  3. WooCommerce order confirmations — not core, but the single most important email on commerce sites (handled by WooCommerce, not core, but still routed through wp_mail())
  4. Contact form submissions — not core, plugin-generated, but the email most site owners test first
  5. Recovery mode / fatal error notices — operational alerts that prevent extended downtime

If your SMTP relay is working and your admin email is current, the rest of WordPress core email is operational noise. The high-priority items above justify the five-minute SMTP setup that most sites skip.

Email reference data from johnbillion/wp_mail (GPL, updated for WordPress 7.0). Operator context and editorial notes by nanoPost, verified June 2026.