Override the Default WordPress Email Sender Name and Address

WordPress often sends mail using a generic sender name and the server’s default address. A consistent sender improves recognition, but the address should belong to the site’s domain and be configured with the correct SPF, DKIM, and DMARC records.

Add this snippet to a child theme’s functions.php file or a site-specific plugin.

The snippet

add_filter( 'wp_mail_from', function( $from_email ) {
  $site_host = wp_parse_url( home_url(), PHP_URL_HOST );
  $site_host = preg_replace( '/^www\\./i', '', (string) $site_host );
  $address   = 'wordpress@' . $site_host;

  return is_email( $address ) ? $address : $from_email;
} );

add_filter( 'wp_mail_from_name', function( $from_name ) {
  return wp_specialchars_decode( get_bloginfo( 'name' ), ENT_QUOTES );
} );

The sender address is generated from the site’s configured home URL rather than hard-coding a domain that could differ between staging and production. The sender name uses the site title and decodes entities so names such as Bonny & Co. display correctly in mail clients.

Use a fixed address when needed

If the site has a dedicated mailbox, replace the address callback with a validated fixed address:

add_filter( 'wp_mail_from', function( $from_email ) {
  $address = 'notifications@example.com';
  return is_email( $address ) ? $address : $from_email;
} );

Do not use a visitor-supplied email address as the From header. Use Reply-To for customer replies instead, because user-controlled sender headers can cause spoofing and deliverability problems. The WordPress wp_mail() reference documents the mail API and its limitations.

Test messages through the actual transactional flows used by the site, including password resets, contact forms, WooCommerce notifications, and scheduled tasks. For reliable delivery, configure domain authentication and consider a transactional mail service rather than relying only on PHP’s local mail transport.