WordPress’s default From: address is [email protected], not the administrator email. The administrator email is where WordPress delivers system mail; it has nothing to do with what appears in the From: header of outgoing messages. Two filters, wp_mail_from and wp_mail_from_name, set that header and sender name before every message leaves the server. Any plugin or snippet that changes the From address or sender name hooks one or both.
The right place to set those values, for a site that already sends through an authenticated SMTP relay, is the SMTP plugin’s “From Email” override: the same plugin already controls the delivery pipeline, and setting the From there keeps the sender address aligned with the signing domain. If the site does not have an SMTP plugin (it should, for deliverability reasons), a small mu-plugin using the two filters is the correct path. A dedicated From-override plugin is a third option, documented here for completeness, but it solves only the From header and does nothing for delivery.
All three paths carry the same constraint: the From address must sit on a domain the sending pipeline can authenticate. Setting From: [email protected] while sending through an SMTP relay authenticated for a different domain breaks DKIM alignment, and a receiver enforcing DMARC will quarantine or discard the message. That constraint governs all three paths equally.
What WordPress actually sends by default
In wp_mail() (wp-includes/pluggable.php), the default From address is constructed as wordpress@ plus the host portion of network_home_url(), with a leading www. stripped. The default From name is the string WordPress. On a site at https://www.example.com, the defaults are [email protected] and WordPress. Both values are filterable: wp_mail_from and wp_mail_from_name run before the message is handed to the mailer, so a single add_filter() call on either replaces the default for every message sent through wp_mail().
A global add_filter( 'wp_mail_from', ... ) applies to all mail sent through wp_mail(), including new-user notifications, password resets, and comment notifications. There is no category of core WordPress mail that bypasses the filter by setting a fixed From before it runs. If a specific message type still shows the old address after the filter is in place, check the filter priority; another plugin may be applying a From with a higher priority number later in the same hook.
Path A: The SMTP plugin’s From Email override
WP Mail SMTP‘s override fires after every other filter, which means WooCommerce order emails and contact form plugins that set their own From can’t override it.
WP Mail SMTP. Go to Settings > WP Mail SMTP > Settings. The “From Email” and “From Name” fields set the global sender details. Check “Force From Email” to make the override authoritative across all plugins; without it, plugins that set their own From header at the message level will override the global setting for their own messages.
FluentSMTP. Open the FluentSMTP dashboard and edit the active connection. The “From Email” and “From Name” fields are in the connection’s sender settings. FluentSMTP also provides a “Force From Email” checkbox that overrides per-plugin From values site-wide, behaving the same way as WP Mail SMTP’s equivalent. If the site uses connection routing with multiple connections, configure the From on each.
Post SMTP. The From address and From name are set in Post SMTP’s settings: the “Sender Email” and “Sender Name” fields. Post SMTP applies the sender override via the wp_mail_from filter; it does not expose a separate per-connection force toggle equivalent to WP Mail SMTP’s.
The alignment constraint. The From address must sit on a domain the sending pipeline can authenticate. If the site sends through Postmark with DKIM configured for example.com, the From address can be anything @example.com (hello@, notifications@, noreply@) and alignment holds because the organisational domain matches under DMARC’s relaxed mode. Setting the From to an address on a different domain ([email protected]) while authenticated for example.com breaks alignment; a DMARC receiver enforcing p=quarantine or p=reject will quarantine or discard the message. See the DNS setup guide for WordPress email for SPF, DKIM, and DMARC configuration.
Path B: A mu-plugin with wp_mail_from and wp_mail_from_name
For sites where the SMTP plugin’s From field is managed by a different team (agency templates, environments where configuration doesn’t persist), the filter approach is cleaner than a UI override.
The snippet belongs in wp-content/mu-plugins/, not the active theme’s functions.php. A theme switch removes any customisation in functions.php silently; a mu-plugin survives theme changes, child-theme misconfiguration, and plugin deactivation. A single file is enough:
<?php
/**
* Override wp_mail() From address and From name.
* Placed in wp-content/mu-plugins/ so it survives theme switches.
*/
add_filter( 'wp_mail_from', function ( $original ) {
$override = '[email protected]';
return is_email( $override ) ? $override : $original;
} );
add_filter( 'wp_mail_from_name', function ( $original ) {
return 'Example Site';
} );The is_email() check on wp_mail_from is a safety net: if the hardcoded address contains a typo, the filter returns the original value and mail continues to send rather than being constructed with a malformed From: header.
This snippet applies the same constraint as Path A: [email protected] must be on a domain the sending pipeline can authenticate. The snippet changes the From: header only; it does not configure the sending route or the DKIM signature. If the site routes through PHP’s mail() or an unauthenticated relay, changing the From address does not help delivery and may worsen it by misaligning the envelope sender domain. Configure an authenticated SMTP relay first; see checking that WordPress can send email and the DNS setup guide.
For the broader question of where to put custom code in WordPress, adding custom code to WordPress covers the options and trade-offs.
Path C: A dedicated From-override plugin
Several plugins on the WordPress plugin directory exist solely to set wp_mail_from and wp_mail_from_name through a settings UI. They are the right pick for the small population of sites that want a UI-controlled From and either do not have an SMTP plugin or have a specific reason not to use the SMTP plugin’s From field.
Before installing one, check three things: the plugin’s “Last updated” date on WordPress.org (a plugin not updated in over a year may carry PHP compatibility issues or hook mismatches against recent WordPress versions), the active install count (choose a plugin with at least 10,000 active installs and an update within the past 12 months), and the implementation approach. A plugin that hooks wp_mail_from and wp_mail_from_name is doing the right thing; a plugin that replaces wp_mail() wholesale is overreaching and can break compatibility with other plugins. The changelog or plugin source will show which approach it takes.
Path C carries the same alignment constraint as Paths A and B. A dedicated From-override plugin provides no help with deliverability; it changes the header only.
The alignment constraint
Changing the From: to [email protected] while the signing domain is example.com produces a misaligned DKIM signature. A receiver enforcing a p=quarantine or p=reject DMARC policy for newbrand.com will quarantine or discard the message, and the delivery failure may be silent (no bounce, no error) because DMARC policy enforcement does not require the receiver to send a failure report.
To verify alignment after any change, send a test message to a fresh 
Mail-Tester address and read the report. Mail-Tester checks SPF, DKIM, and DMARC alignment in one pass and makes misalignment visible before it affects real recipients. If the From change needs to move to a domain the current provider is not configured to sign, consult the provider’s DKIM setup documentation: Postmark, SMTP2GO, and SendGrid each publish per-account DKIM selectors under different configuration paths.
Verdict
For most WordPress sites, the From change belongs in the SMTP plugin’s settings. WP Mail SMTP and FluentSMTP expose a “Force From Email” toggle that makes the override authoritative across every sending plugin on the site; Post SMTP applies the override at the filter level and covers most cases. The mu-plugin filter approach is the right path for code-managed configurations: agency templates, sites where the SMTP plugin’s From is owned by a different team, or sites deploying to environments where UI configuration does not persist. The dedicated From-override plugin category is a viable third option when a UI override is needed and the SMTP plugin’s From field is off the table.
| Situation | Recommended path |
|---|---|
| Site has WP Mail SMTP, FluentSMTP, or Post SMTP | Path A: SMTP plugin’s From Email override |
| Code-managed config (agency, multi-site template) | Path B: mu-plugin filter snippet |
| UI needed, SMTP plugin’s From field unavailable | Path C: Dedicated From-override plugin |
A site sending unauthenticated mail through PHP’s mail() will not deliver reliably regardless of what the From: header says. Configure an authenticated sending route first, then set the From.