Default wordpress@site.com sender address can be problematic

[thinlinecz]

Hi, if installed, the default sender address of all emails sent from the application is something like wordpress@…. For the majority of sites, this mailbox doesn't exist, which causes numerous problems with delivering. And even the sender's domain doesn't exist in DNS (has no MX record), if it's on subdomain. Couldn't it be better to show warning at first login to set up the address of the sender, which is both real and functionable?

[SirLouen]

This was forced in [3214], mainly because of #1532, 20 years ago, and has prevailed until now.

They switched from

"From: " . get_settings('admin_email') . "\n"

To

"From: wordpress@" . preg_replace('#^www\.#', '', strtolower($_SERVER['SERVER_NAME'])) . "\n" . 

Which did not make any sense to me at first in the early days. In fact, my first impression has always been that the From: should logically be the admin_email (just because it could be manually edited)

But the reality is that admin email could be significantly different from the domain (you could be using a Gmail admin email, and your domain could be whatever.example.com). So the better option here (unless you used some SMTP relay with a different domain than the one in your website), was setting something@…

But what something was the best in this case?

Arguably we could set one of the classic sets, like webmaster, info, etc… but then anyone could come like you saying why webmaster instead of info since info is more popular in a never-ending discussion.

Another option could be, adding in the front-end the option to set this in another field. But there is a WP theory, that WP should work somewhat like a framework, with the minimum fields possible in the backend. If one field is not 99.99% essential, it should go away. And instead of adding a million fields that customize everything to the minimum detail, WordPress uses a "hidden field" strategy with the concept of "filter hooks". This way, you could perfectly customize this, but unfortunately without a visual tip in the front end (because as I say, not everything could be in the front end, only in the ​developer docs).

And here is where the hook ​wp_mail_from comes handy. You can edit this hook, in order, not only to set your from easily like this:

add_filter( 'wp_mail_from', function custom_wp_mail_from( $original_email_address ) {
return 'something@whatever.example.com';
}

But also, you could do some logical stunts to use a different From: based on certain conditions (for example, if you would like to send privacy emails with a privacy@example.com, you could).

Furthermore, there are some plugins that provide you with the field in the front-end, just in case you would rather not touch the code.

If you are planning to go full DYI, WP needs a little extra tweaking beyond the UI, but pretty much like any other framework out there. The important thing here is that you can actually do something to remediate the problem.

This said, I'm closing this as wontfix as this is the expected default behaviour.

[SirLouen]

#62077 was marked as a duplicate.

[michael.orlitzky]

Replying to SirLouen:

This was forced in [3214], mainly because of #1532, 20 years ago, and has prevailed until now.

#1532 isn't complaining about a problem with the admin address, it's complaining about using the server name without stripping the "www". I'm sure there's some history missing here but my point is that the change from the admin address back to a modified server name is not fixing any particular problem.

Which did not make any sense to me at first in the early days. In fact, my first impression has always been that the From: should logically be the admin_email (just because it could be manually edited)

But the reality is that admin email could be significantly different from the domain (you could be using a Gmail admin email, and your domain could be whatever.example.com). So the better option here (unless you used some SMTP relay with a different domain than the one in your website), was setting something@…

That's OK, the new-user emails don't need to come from the site address. I mean, the rest of the admin emails don't -- they come from the admin address! As you say, the main selling point of the admin address is that the admin can change it, which means he will set it to something viable, and it is likely to actually be usable for sending email. With modern email systems the same is not true of address@$SERVER_NAME.

Another option could be, adding in the front-end the option to set this in another field. But there is a WP theory, that WP should work somewhat like a framework, with the minimum fields possible in the backend. If one field is not 99.99% essential, it should go away. And instead of adding a million fields that customize everything to the minimum detail, WordPress uses a "hidden field" strategy with the concept of "filter hooks". This way, you could perfectly customize this, but unfortunately without a visual tip in the front end (because as I say, not everything could be in the front end, only in the ​developer docs).

Two options would be better, but admin address is better than guessing. To put it bluntly, the existing setting is wrong: there's no reason to expect an organization to use the same company for their web and email hosting, and most email systems require SPF/DKIM/DMARC/etc these days. Using the $SERVER_NAME is causing important email to disappear, and AFAIK has nothing else to recommend it over the admin address.

[knutsp]

Sending emails have become stricter over the years. The situation for WordPress is critical, IMHO.

1. From/Sender account must exist. I always create wordpress@ as a forwarder, or add a filter in a site plugin.
2. Domain needs MX. This is automatically created in some hosting environment, also for subdomains when registered as such (not only A/AAAA/CNAME). cPanel does this.
3. SPF/DKIM/DMARC is needed. cPanel makes at least SPF/DKIM. If on email is hosted on another server/system, the SPF must be manually configured to allow webserver host to send emails for the domain.
4. The Sender header must exist as part of the message. I always enable this by phpmailer init action. This not being the default is a bug, IMHO.

SMTP is suggested by most hosts, it seems, since it's hard to explain how to ensure direct sending from the webserver is working properly. An expert is needed, and for many cPanel works as the "expert", but very often a plugin is needed (SMTP or just to add Sender). The difficulties vary a lot with the hosting environments.

I suggest the setup, options(?), Site Health entry(?), the documentation and the recommendadtions become a case for the hosting team at wp.org, if they are still in operation.

[SirLouen]

Replying to michael.orlitzky:

Two options would be better, but admin address is better than guessing. To put it bluntly, the existing setting is wrong: there's no reason to expect an organization to use the same company for their web and email hosting, and most email systems require SPF/DKIM/DMARC/etc these days. Using the $SERVER_NAME is causing important email to disappear, and AFAIK has nothing else to recommend it over the admin address.

Yes, I agree that it's too tricky as-is nowadays. Its funny because #1532 as you say was arguing about that www thing, but in the end, the fix was switching admin email to a fixed wordpress with www stripping (check the changeset [3214]). So basically what I was trying to illustrate there is that originally, it was actually taking the admin email as you suggested.

Still, this is a complex discussion if "Admin email" is ideal. Nowadays, as you say with such many "checks" for mostly anti-spam and security measures, its difficult to guess which will be the ideal sender/from email.

As I said, all problems as solved if we used the hook wp_mail_from.

As it's now current WP_Mail is as follows:

1. By default no specific PHPMailer is done, for this reason, mail function will be used by default, which takes the default MTA in the server.
2. A default MTA could be configured in multiple ways. So choosing a default is not trivial.
3. The default and standard configuration is as simple as: reverse domain pointing to server IP address. Server configured with a single domain, and such domain serving the site for Webserver default address, which means, serving the domain for the WP site. For this reason, hostname === WP_SITEURL (stripping www) and this is how you get to the default selected option.
4. As @knutsp, wordpress@ as a forwarder is just a matter of randomness selection. It could have been info, webmaster or whatever, there is no standard for this, so looks fair to choose the same name as the service for this purpose.

Could Admin Email be a better option? Its more visual and definitely feels much more intuitive. Maybe we could draft a new proposal in a new ticket stating all the reasons of why this should be the way to go. I'm not 100% against this.

There is only one massive problem: Backwards compatibility. In an era where WP is the 40% of the internet, potentially thousands if not millions of servers are already working with default behaviour. If we update the version changing this, there could be massive potential email breakages in multiple sites. For this reason, I'm 99.999% certain that this proposal will be rejected.

Replying to knutsp:

I suggest the setup, options(?), Site Health entry(?), the documentation and the recommendadtions become a case for the hosting team at wp.org, if they are still in operation.

Good suggestions. I'm going to take note and see how can we handle this. Personally I like the idea that @michaelorlitzky was proposing, but realistically speaking knowing all the hindrances that WP pose, this is the way to go.

[knutsp]

Replying to SirLouen:

Could Admin Email be a better option? Its more visual and definitely feels much more intuitive. Maybe we could draft a new proposal in a new ticket stating all the reasons of why this should be the way to go. I'm not 100% against this.

There is only one massive problem: Backwards compatibility. In an era where WP is the 40% of the internet, potentially thousands if not millions of servers are already working with default behaviour. If we update the version changing this, there could be massive potential email breakages in multiple sites. For this reason, I'm 99.999% certain that this proposal will be rejected.

There are ways to avoid breaking backwards compatibility, but if admin email was to be used as From, the default would have to depend on intital database version, which I guess is far from ideal for documentation, learning WP and for support. Therefore I don't like that, except as a default for a new user facing option. In this case, given the increased strictness and compelxity sending emails that will not be rejected or simply flagged as spam, this could be acceptable.

To make a new option easier to set properly, a check could be made that it, when changed, exists using SMTP, and emit a warning if it fails. And/or immediately send a test message to the current user_email. This could also be a Site Health test. The Site Health Tools plugin has a manual email sending check that could be included in core.

When I'm asked to help a site owner or admin, the most common reasons is 1) that they have lost their password and does not receive reset email, or 2) that they have a fatal error and no way to get in and fix it. When asked, many have never ever received any email from their WordPress installation and have given up finding out how to make it work. The simplest to fix is the lack of Sender header, a thing some MTAs are strict about, some not, but very often there are several other problems.

We need to identify all challenges non-expert users face when installing and maintaining WordPress in configuring mail sending that will work, since WordPress depend on it for so many features. Then identfy which and how to do the most common and simplest checks that MTAs will do, before doing an end-to-end test (send a message). The goal should be that setting up email sending natively from the web server (maildrop through PHPMailer) become easier that setting up SMTP, a task some also have trouble with, besides requiring a plugin.

[SirLouen]

Replying to knutsp:

We need to identify all challenges non-expert users face when installing and maintaining WordPress in configuring mail sending that will work, since WordPress depend on it for so many features. Then identfy which and how to do the most common and simplest checks that MTAs will do, before doing an end-to-end test (send a message). The goal should be that setting up email sending natively from the web server (maildrop through PHPMailer) become easier that setting up SMTP, a task some also have trouble with, besides requiring a plugin.

Let's try to shape this a little. How would you display this on a Health Check? (this information could be candidate for another ticket for a Feature Request)

Capturing the mail error, saving it in a db record or something to show it as a Health Check failure?

I like for example how WP Mail keeps informing about Mail problems. I definitely think that something like this could be somewhat replicated as a Health Check

The thing with Mail is that as I said its not a trivial aspect of WP like for example, publishing a post. Some technical knowledge is required. But I agree that not much information is provided on such technical knowledge. I will try to see if we can better sort this out.

[michael.orlitzky]

I think a new option can have a good default and still be backwards compatible:

1. Add the new option
2. When the option is empty/unset, have it mean "use the admin address"
3. The upgrade procedure sets the new option to wordpress@$SITE_NAME
4. New installs leave the option empty

With that, new installs will do something smarter (use the admin address) while old installs retain the existing behavior. And in either case you can change it to suit your setup.

Mail hooks etc. are good workarounds for people who know what the problem is, but TBH we just patch wordpress. I reported this because there are a lot of people out there who know nothing about email except that they don't get certain messages from their hosted WP installations. Using the admin address isn't perfect, but it's a lot more likely to work because, if the admin address doesn't work at all, someone is likely to notice.

[SirLouen]

Replying to michael.orlitzky:

Mail hooks etc. are good workarounds for people who know what the problem is, but TBH we just patch wordpress. I reported this because there are a lot of people out there who know nothing about email except that they don't get certain messages from their hosted WP installations. Using the admin address isn't perfect, but it's a lot more likely to work because, if the admin address doesn't work at all, someone is likely to notice.

Generally, hostings set all this for you when you set up your WP with them.

If anyone is plain clueless about hooks, you better not be using anything but a hosting, or this will be your best problem.

Again, adding more fields to the frontend is probably never going to happen. The tendency is to remove fields, in fact, the overall tendency is going full headless config-wise with just the content management part from the CMS. As I said, the admin email looks intuitive, but at the same time it will run inadequate. It's not uncommon to have your Gmail for notifications for example, as admin email and some server email for delivery (in fact it's much more common than the other way around). So definitely, intuition is not necessary the best practice.

Finally, stunts in this regard are left for extenders. Also be aware that having WP deal with email as a smarthost is not the best idea because it could add some overhead. Generally, you should be trying to leave this 100% to your local MTA and be as lean as possible. Personally, I only set manually these parameters for testing, but this is not the best practice.

Currently, I'm leaning more towards supporting and elaborating on @knutsp idea, which aligns more with the current state of the art of WP

[siliconforks]

Replying to SirLouen:

wordpress@ as a forwarder is just a matter of randomness selection. It could have been info, webmaster or whatever, there is no standard for this, so looks fair to choose the same name as the service for this purpose.

Actually, there is an RFC for that: ​RFC 2142. Both info@ and webmaster@ are mentioned as well-known mailbox names, while wordpress@ obviously is not.

(I wouldn't recommend changing it now, though, after it's been using wordpress@ as the default for two decades.)

[michael.orlitzky]

Replying to SirLouen:

Replying to michael.orlitzky:

Mail hooks etc. are good workarounds for people who know what the problem is, but TBH we just patch wordpress. I reported this because there are a lot of people out there who know nothing about email except that they don't get certain messages from their hosted WP installations. Using the admin address isn't perfect, but it's a lot more likely to work because, if the admin address doesn't work at all, someone is likely to notice.

Generally, hostings set all this for you when you set up your WP with them.

The hosting company cannot set this up for you unless they are also the email host for the domain. If we host the WP for example.com and if example.com has DKIM/DMARC, I cannot just set up DKIM signing on our server with the private keys that we don't have. I also do not have a good idea what the correct value is, or know the people who are maintaining the theme...

If anyone is plain clueless about hooks, you better not be using anything but a hosting, or this will be your best problem.

It's not a matter of being clueless about hooks, but being required to modify a theme in almost every WP deployment because the default is wrong out-of-the-box.

Again, adding more fields to the frontend is probably never going to happen. The tendency is to remove fields, in fact, the overall tendency is going full headless config-wise with just the content management part from the CMS. As I said, the admin email looks intuitive, but at the same time it will run inadequate. It's not uncommon to have your Gmail for notifications for example, as admin email and some server email for delivery (in fact it's much more common than the other way around). So definitely, intuition is not necessary the best practice.

I understand if no one wants to add new fields, but I don't think I understand your argument. Is the admin email address meant to be used as the "From" address when sending WP mails? If it is, then the admin address is preferable to any address that doesn't work. If not, what you're saying would make sense (and I would agree), but it would also contrast with the fact that WP itself and a huge number of very popular plugins are already using the admin address as the "From" address (because there's no better option!).

[knutsp]

This getting far to complicated and stretching beyond what WordPress core can do.

The admin email is for the recipient only, the "To" header address. This could be any domain. To me, any talk about using this as "From" is confusing and won't work. If someone want that, they must use SMTP.

So far I can only support a new UI option to set the local part, leaving the site domain as the sender domain.

If your web host is not email host, then the SPF record must account for that.

What I want as a first step is only:

1. Let the novice user set up an existsing email address in the web domain, as "From", guided with a check that it exists on the web hosting server, otherwise, advised to create it and ensure the web host is an authorized email sender for the domain. Maybe contact host on how to do it. Default: wordpress@

2. All other cases: Advice th use of an SMTP plugin. Then SPF/DKIM/DMARC is not an issue.

@michael.orlitzky:

a huge number of very popular plugins are already using the admin address as the "From" address (because there's no better option!)

What plugin(s)? They are using SMTP?

[michael.orlitzky]

Replying to knutsp:

2. All other cases: Advice th use of an SMTP plugin. Then SPF/DKIM/DMARC is not an issue.

While SPF verifies the SMTP envelope sender (i.e. what usually winds up in the Return-Path header), DKIM verifies the "From:" header which is independent of the transport mechanism. If the "From:" header is hard-coded to use the $SERVER_NAME, somehow you need to have access to the signing infrastructure for $SERVER_NAME, otherwise you're going to fail DKIM.

The website is not necessarily even hosted on $SERVER_NAME, it could be hosted on www.$SERVER_NAME, because WP is stripping the "www" as if it's irrelevant. But www and @ are different DNS zones! You will occasionally find www delegated to another department to manage beta sites and i18n subdomains, etc. So not only could the email be controlled by another entity (who doesn't want some random web server sending spam through their infrastructure), but you may not even be talking about the same DNS.

@michael.orlitzky:

a huge number of very popular plugins are already using the admin address as the "From" address (because there's no better option!)

What plugin(s)? They are using SMTP?

They are just sending email, the protocol is not really relevant. Wordpress itself uses the admin address as the "From:" value. In wp-includes/ms-functions.php:

$admin_email = get_site_option( 'admin_email' );

if ( '' === $admin_email ) {
  admin_email = 'support@' . wp_parse_url( network_home_url(), PHP_URL_HOST );
}

$from_name       = ( '' !== get_site_option( 'site_name' ) ) ? esc_html( get_site_option( 'site_name' ) ) : 'WordPress';
$message_headers = "From: \"{$from_name}\" <{$admin_email}>\n" . 'Content-Type: text/plain; charset="' . get_option( 'blog_charset' ) . "\"\n";

GravityForms encourages you to use the site admin as the "From" address -- it displays a warning if you're not using either the site domain or the admin email as the "From". You'll find code like,

if ( ! GFCommon::is_valid_email( $from ) ) {
    $from = get_bloginfo( 'admin_email' );
}

Elementor Pro defaults some of its messages to the admin email. WP Updates Notifier defaults to the admin email, etc. Lots of plugins need to send email, and as we are all now discussing, making up a random address @SERVER_NAME doesn't work. So they choose the best address available, which is the admin email. (You can grep for admin_email in any wp-content/plugins directory to find lots more of these.)

I may be pointing in the wrong direction if the admin email was never meant to be used as a sender, but in any case, the web server admin needs to be able to choose an address (really, a DNS domain) that he controls and is responsible for. It's not always possible to gain access to the existing mail infrastructure for $SERVER_NAME, and we don't want all mail from WP to disappear into a void in that case.

[SirLouen]

Replying to michael.orlitzky:

The website is not necessarily even hosted on $SERVER_NAME, it could be hosted on www.$SERVER_NAME, because WP is stripping the "www" as if it's irrelevant. But www and @ are different DNS zones! You will occasionally find www delegated to another department to manage beta sites and i18n subdomains, etc. So not only could the email be controlled by another entity (who doesn't want some random web server sending spam through their infrastructure), but you may not even be talking about the same DNS.

According to this, it seems that at some point, they got to the conclusion that www could lead into spammy results. I'm not 100% sure confident on how they got to this conclusion and which references they found to identify where the host part with www led to this spam trouble.

I can't really think on a way to solve this by (1) not using a new UI element, (2) not using, obviously admin_email (because it might better used for whatever real admin email for notification purposes) and obviously (3) not provoking a backwards compatibility issue. Combining these 3 elements, I can't see other better way to sort using apart from using a hook (which is generally my go-to),

Elementor Pro defaults some of its messages to the admin email. WP Updates Notifier defaults to the admin email, etc.

Are we talking about were these plugins send their notification messages (To:) or which field they use for their notification messages (From:)? I have not reviewed them all, but in the case of "WP Updates Notifier" it seems that they directly take the email from admin and pluck it into their admin menu, so basically they handle their own To: and From: fields. As I said, in my beginnings I always thought that admin_email was default for From: (its the most obvious).

If someone can find some additional idea apart from those stated already, that could bypass the 3 hindrances stated above, maybe we could move from there.

[michael.orlitzky]

Replying to SirLouen:

According to this, it seems that at some point, they got to the conclusion that www could lead into spammy results. I'm not 100% sure confident on how they got to this conclusion and which references they found to identify where the host part with www led to this spam trouble.

The "www" can lead to trouble because most people aren't sending with email addresses like user@www.example.com. If you use $SERVER_NAME without stripping the "www", and if your URL uses the www, then that's what happens, and in most cases it will be wrong: no MX record exists for www.example.com, and you wind up in spam or with your mail rejected. But conversely, the bare example.com is not always right either, if you are not responsible for its mail.

Elementor Pro defaults some of its messages to the admin email. WP Updates Notifier defaults to the admin email, etc.

Are we talking about were these plugins send their notification messages (To:) or which field they use for their notification messages (From:)? I have not reviewed them all, but in the case of "WP Updates Notifier" it seems that they directly take the email from admin and pluck it into their admin menu, so basically they handle their own To: and From: fields. As I said, in my beginnings I always thought that admin_email was default for From: (its the most obvious).

They are using the admin email as the "From". I agree that this is in a sense the most obvious, since it is the one email address that you are able to configure, and are relatively likely to notice if it doesn't work.

It's not clear that Wordpress intends for the admin address to be used this way however. My argument so far has essentially been that "the admin address is better because everyone else is already using it." Which is true, but I want to be transparent about that in case it turns out that everyone else is using it wrong. In that case, the admin email should not be used either, and we are back to the problem of needing to configure a generic "From" address.

[desrosj]

Reading through this back and forth, I don't think this one is ready to be closed out yet. It's not clear whether any changes are necessary (or nothing at all is necessary). While discussion can always continue on closed tickets, I'd like to leave this open so it remains visible in reports.

I tend to agree that it may not be best to change the default now and I am also currently against adding a new option.

However, maybe there is some mix of the following that can be explored:

• Add a warning or info-level notice in Site Health educating the user about how to make their site's email more reliable (seems like #62129 aims to accomplish some form of that)
• Possibly create a simple canonical plugin that helps site owners control and adjust the appearance of their site emails without needing to add their own filters.
• Work with the Hosting team to better document this and explore possible best practices to recommend. For example, I believe if the host is in control of the name servers for the domain name and no email related DNS entries are present, a forwarder could probably be set up by default.

[michael.orlitzky]

Replying to desrosj:

Reading through this back and forth, I don't think this one is ready to be closed out yet. It's not clear whether any changes are necessary (or nothing at all is necessary). While discussion can always continue on closed tickets, I'd like to leave this open so it remains visible in reports.

I tend to agree that it may not be best to change the default now and I am also currently against adding a new option.

In that case I think the first step is to obtain some clarification from the Wordpress team on the role of the site admin address. Is it an email address belonging to the site administrator, or is it the email address used for site administrative purposes? The short blurb within the user interface is unclear about this.

Basically what I am asking is: is it meant to be used as a "To" address, "From" address, or both?

(You may still not like any of these solutions, but in any case, to even know what makes sense as a proposal, we need to know how the site admin address is intended to be used.)

Case 1: It's a "From" address

In this case, it's a better choice than wordpress@SERVER_NAME, since it is configurable and likely to be set to an address that works.

Case 2: It's both

No problem, same as case 1.

Case 3: It's only a "To" address

This is the hardest, because we absolutely still need an easily configurable "From" address, and all of the plugins that are currently using the site admin address as the "From" address are using it wrong.

[SirLouen]

Replying to desrosj:

However, maybe there is some mix of the following that can be explored:

• Add a warning or info-level notice in Site Health educating the user about how to make their site's email more reliable (seems like #62129 aims to accomplish some form of that)
• Possibly create a simple canonical plugin that helps site owners control and adjust the appearance of their site emails without needing to add their own filters.
• Work with the Hosting team to better document this and explore possible best practices to recommend. For example, I believe if the host is in control of the name servers for the domain name and no email related DNS entries are present, a forwarder could probably be set up by default.

Yes, this is mostly the summary of the conclusions we got in this report.

The idea was the following:

• I was planning to leave this report closed, mainly because the idea was to do a new summary with all the information retrieved and create a new clean report focusing on this specific target, building the Health Check.

• The canonical plugin is always an option, still I don't have a clear guidance on how canonical plugins work from scratch (like where to start implementing and all that)

• This was already in process, I already sent the ​report upstream to Hosting and ​the corresponding PR to activate this. After this, I might be probably improving a bit the docs to make this clearer.

Replying to michael.orlitzky

This is the hardest, because we absolutely still need an easily configurable "From" address, and all of the plugins that are currently using the site admin address as the "From" address are using it wrong.

This is what we have already been discussing all the way through. The admin email is only meant to be a "To" address, mainly for notification purposes regarding the administration level of the site. All inputted emails (including other plugins in the ecosystem, like bbPress and Buddypress), use any "saved in the DB" email as a To email. For the From email, the solution was, as I said, using the filter.

You argue that the filter is not well documented in the front end, and this is what we will be solved via Health Check and the Administration docs. These happen to be the classic docs go-to within the administration interface. As we already identified, changing this behaviour can provoke a backwards compatibility trouble, and setting the admin email as the From also collides, as I said, with the idea that this email could be mostly anything the admin decides (for example, the admin's Gmail account).

Maybe we could also improve the copy for that, but again I would open a new ticket for this specifically. Personally, I prefer ​individual tickets for each single thing (working as much atomically as possible), that trying to approach everything in a single shot.

This is why I would consider this a close candidate at least, once all the new atomic tickets have been deployed.

[michael.orlitzky]

Replying to SirLouen:

Replying to michael.orlitzky

This is the hardest, because we absolutely still need an easily configurable "From" address, and all of the plugins that are currently using the site admin address as the "From" address are using it wrong.

This is what we have already been discussing all the way through. The admin email is only meant to be a "To" address, mainly for notification purposes regarding the administration level of the site. All inputted emails (including other plugins in the ecosystem, like bbPress and Buddypress), use any "saved in the DB" email as a To email. For the From email, the solution was, as I said, using the filter.

Ok, thanks, at least this gives us a starting point.

You argue that the filter is not well documented in the front end, and this is what we will be solved via Health Check and the Administration docs. These happen to be the classic docs go-to within the administration interface. As we already identified, changing this behaviour can provoke a backwards compatibility trouble, and setting the admin email as the From also collides, as I said, with the idea that this email could be mostly anything the admin decides (for example, the admin's Gmail account).

My real argument against the filter would be twofold:

1. A usable sender address is one of the most basic settings that needs to be tweaked -- or at least verified -- on every site. Requiring code to change it just means that it will remain incorrect for many people, leading to (silently) lost or junked messages.
2. It's a site-wide setting, so in particular it doesn't belong in a theme; upgrading a theme from wordpress.org/themes shouldn't erase the setting. Is there an easy way to install filters site-wide? (I don't think creating a new custom plugin for each site to change one email address is reasonable.)

[SirLouen]

Replying to michael.orlitzky:

1. A usable sender address is one of the most basic settings that needs to be tweaked -- or at least verified -- on every site. Requiring code to change it just means that it will remain incorrect for many people, leading to (silently) lost or junked messages.

In fact we were talking about the future posssibility of creating some sort of canonical plugin, which could kind of sort this issue and maybe others related to this (a plugin maintained by WP organization). This could add the field you are mentioning, and other issues I've been encountering in the past months.

2. It's a site-wide setting, so in particular it doesn't belong in a theme; upgrading a theme from wordpress.org/themes shouldn't erase the setting. Is there an easy way to install filters site-wide? (I don't think creating a new custom plugin for each site to change one email address is reasonable.)

WP is meant to be extended. It's completely reasonable to have a custom plugin that adds this sort of filters. In fact is a great practice to have a custom plugin per site, where you add all your tweaks there. One of the biggest weaknesses of WP by far, is the effort developers do to preserve backwards compatibility, specially with hooks, so the code maintainance burden of plugins with hooks is virtually 0. You could have added this hook back in 2010, and come now and the plugin would have been working flawlessly.

So having a custom plugin per site is not only reasonable, but very recommended. There are zillions of hook filters (I'm discovering a new one every single day), for a reason. This is essentially the core nature of WP. In fact, there are a couple of plugins that extend by just adding one hook.

If you are worried about people not knowing that this is not configured or missconfigured, here is where the Health Check we commented before comes into play. Health Checks have been used like the swiss army knife for pretty much anything docs within WP admin UI, without having to add more fields or more notices.

[SirLouen]

Related #62129

[SirLouen]

#47605 was marked as a duplicate.

[desrosj]

Replying to SirLouen:

The idea was the following:

• I was planning to leave this report closed, mainly because the idea was to do a new summary with all the information retrieved and create a new clean report focusing on this specific target, building the Health Check.

Whenever possible, it's best to continue using the same ticket. This ensures that past participants and watchers on the original ticket continue to receive notifications for new activity.

• This was already in process, I already sent the ​report upstream to Hosting and ​the corresponding PR to activate this. After this, I might be probably improving a bit the docs to make this clearer.

Thanks for following up on this outside of this ticket! Please make sure to cross-reference any related actions that are taken outside of a ticket in the future, especially ones outside of this Trac or wordpress-develop. It helps contributors follow all of the work that was performed as a result of a ticket's discussions.

I dug a bit deeper into the history of the From: address before [3214] and traced the addition of From: <admin_email> to [2415]. Prior to that, there was no From: email defined at all. The ​tracker used then was mosquito, but it's unfortunately no longer accessible. So any discussion around why can't be followed.

I next looked through all tickets mentioning From in the summary within the Mail component. Here are a few that were notable.

#14586: This one removed the wordpressmu_wp_mail_from() function, which hooked to the wp_mail_from filter and returned the admin_email when the email being used did not contain wordpress@ (see [15678]). The ticket notes that using the admin_email can "have delivery problems (which is why we do wordpress@server)" and exposes the admin email address, which implies that the admin_email is meant to be kept private.

Next up is #25239. This one is quite long and got off track, but there are some comments that are very relevant to this discussion related to why admin_email is not used as the From: address:

• "system generated messages (like password resets or notifications) aren't really from the blog author, but from the backend" (ticket:25239#comment:67)
• "emails like password resets that shouldn't come from the admin, actually touches back on why this is considered a security issue. Admins shouldn't get the bounced email with the link to password reset." (ticket:25239#comment:69)
• "some servers block emails sent FROM anyone but the domain WP is installed on. So your personal email of foobardancingfox@… wouldn't get the messages :( Oh and lets not think about the spoofing of emailing from gmail while actually not being from gmail. Fast track to being blacklisted :(" (also ticket:25239#comment:69)
• "since it isn't human, then presumably the idea is that it's effectively a "noreply@" address? i.e. An address that isn't really intended to get replies" (ticket:25239#comment:70)

After that, the ticket was refocused on the original intent, which was to address potential insecure scenarios with $_SERVER['SERVER_NAME'].

Honorable mention is #17001: Mentions that "Many ISPs block a from address that is off domain."

The last ticket I found that had points relevant to the discussion was #23365. This ticket proposed the addition of a new option for configuring the From: email. From ticket:23365#comment:4:

The main issue with providing a UI option for this, is it requires configuration beyond the option. Something still needs to be done, outside of WordPress, in order to make it work. The user still needs to do some outside configuration they probably don't understand (see the next paragraph for a fairly onerous and confusing process some must go through). That's not very good when you offer an arbitrary input. If any email worked, we would have been using admin_email all this time.

I think something more effective would be to encourage hosts to set up a default email address of wordpress@… in their own systems whenever a user installs WordPress, to allow the local SMTP server to send it. Even if MX records to not go to the host, some hosts do whitelist outgoing mail based on their own systems.

I had not seen this prior to my comment above, but I strongly align with this and it better captures what I was recommending in my third suggested action item. While it's good to surface the documentation that you noticed had been written but not presented in the handbook @SirLouen, I think that it does not accomplish the third point. It does a ​great job of outlining the technical reasons why certain From values may be problematic and how to fix them, but this is still a handbook aimed at advanced administrators. The majority of WordPress users (who are non-technical) would have no idea what to do after reading this.

My vision is something more like what was recommended by @nacin where hosting companies just handle this for the user and they can change it if they'd like. As an employee at a hosting company, I am going to do some research here to see if this has been attempted before and raise it as a discussion with the broader hosting team.

Next, I also took a look at how the admin_email field is presented tot he user.

• General Settings: The field is labelled "Administration Email Address" and the description is "This address is used for admin purposes. If you change this, an email will be sent to your new address to confirm it. The new address will not become active until confirmed."
• Network Settings page: The field is labelled "Network Admin Email" and the description is the same as on the General Settings page.
• Installation Page: The field on this page is labelled "Your Email" and the only description is "Double-check your email address before continuing."

If the email was meant to be surfaced and used within email communication from the site, I think that the context provided to the user would be much more descriptive. Especially on the installation page where it reads as if you are entering an email for your own user account on the site.

With all this in mind, I think that it's safe to answer your question @michaelorlitzky: The admin_email is only intended to be a "to" address (option 3).

using the site admin address as the "From" address are using it wrong.

I also agree with this, though I can't speak for how each individual plugin explains this to the site owner. It's possible that some do adequately explain the reasoning and consequences of using that field as the From: sender instead of the default so that the user can make a truly informed choice. I'd be curious how they are working around the other related factors described above that will potentially result in the emails being flagged as suspicious. But that's a discussion for a different day.

I've also reconsidered whether a canonical plugin would be useful in this situation and I've decided that I don't think it would be appropriate here. Even if the From email is changed through the use of a filter, that alone would not be enough. "Something still needs to be done, outside of WordPress, in order to make it work," as stated above. This would just result in a confusing scenario for the user.

• Activate canonical plugin
• Change From email
• Experience varying levels of email reliability depending on the email that's used, the policies associated with that email service and/or the ISP. This also won't be immediately obvious, if it's ever noticed at all.

This leaves #62129 for implementing a check and educating the user about possible issues related to the default choice in Site Health, the pull request that @SirLouen created, and the outreach I described above with the hosting team. I'm going to mark this as close to allow time for any additional thoughts in response to this. I think that this is actually a duplicate of #23365. Even though that ticket explicitly asks for a new option for the From address, this ticket is essentially asking for the same thing.

[SirLouen]

Some key elements I want to highlight:

1. The From: part is kind of tricky regarding the hosting part. If you have a fully configured MTA in your server/webhost/whatever you are using, as long as you have the local part (the wordpress) mapped, it won't bring any troubles. The problem is that most hostings limit the mappings to X units, and aliases don't count.

I have not used regular web hosting for ages, but the last time I dealt with one I remember that just creating the mailbox for wordpress with my associated domain DNS pointing fully to the hosting was more than enough to make the WP mailing system work flawlessly. So from a very basic user standpoint, just explaining in the Health Check that they need to create said mailbox will be more than enough (or edit this with the corresponding hook). For the “advanced administrator” that needs to configure his MTA accordingly, here is where the Administration Handbook entry comes into play.

2. I still need to review the book entry more deeply. Despite it was merged some months ago the link was not even added, so it is not published yet. I think that the major problem that administrators are having is with the Sender address itself (not the wordpress@host address in particular). In fact, in some of my servers I use a wordpress@mail.host.org format because I host the core domain for corporate emails in a different mail server. So the reality is that if the administrators can't deal with the filter hook… they have a serious problem.

I've also reconsidered whether a canonical plugin would be useful in this situation and I've decided that I don't think it would be appropriate here. Even if the From email is changed through the use of a filter, that alone would not be enough. "Something still needs to be done, outside of WordPress, in order to make it work," as stated above. This would just result in a confusing scenario for the user.

3. Still, could we add a place to modify the From. A canonical plugin is not a terrible idea. If there was a section specific to mail-related topics within a plugin, I don't see the trouble in adding this. In fact, most extensions have this by default (and the Reply-To also, which is a little forgotten and could be as valuable as the From:).

4. About the #25239 you mention there. As you have seen, related to the point number 2, the main issue that people have historically had is with the Sender property, no the email address itself (this is why I closed this ticket, as it's unlikely to get too far apart from the little tweaks we are commenting here). That report sorted out a problem with certain web server apps, and now it's a little more reliable. But this was mostly affecting people managing their servers.

5. Finally, I have to admit that the decision to use wordpress@ was terrible. As @siliconforks pointed out, back in the day, the #1 option was hostmaster, and this was part of the RFC recommendations. This kind of discussion could have ended easier if that was set up, as it almost a default, and many webhosts give these inboxes for free by default (I wonder if Bluehost does)

I would like to hear about what the ppl from BH are doing nowadays. Given they are providing WP preinstalled as one of the main services, I wonder how they are deploying the mail part for their users (probably autogenerating a wordpress local inbox by default straight away`). With the conclusions, I think we need to tweak a little more the copy on #62129.

[knutsp]

Replying to SirLouen:

Let's try to shape this a little. How would you display this on a Health Check? (this information could be candidate for another ticket for a Feature Request)

Capturing the mail error, saving it in a db record or something to show it as a Health Check failure?

No need to save anything, other than caching it. I mean a Test (those automatically performed when visiting Site Health). As we know, that page performs tests, then displays the results, what they mean, explains what the implications are and so on. In case of failure, the user may be advised to create a forwarder to null ("blackhole"), to an existing address or create a full account.

The test may just try to send to the From adress with SMTP (default: wordpress@[server.host]), not actually sending any message, using VRFY or RCPT TO. With the latter, the MX will either accept it and invite to go on or reject it as non existent. The response code can be turned into a boolean (success/unsucessful). Or actually send a test message, but that would require a user initiated test, as in the plugin "Site Health Tools".

I may be able to make a tiny plugin to demonstrate this concept, implemented as a Site Health Test, if this is the way to go.

[desrosj]

Could we discuss the specifics of the Site Health check on #62129?

Please leave close on this one so that it shows in the Suggesting Close / Needs 2nd Opinion report. As a Committer, my suggestion is to close it, but I would like to get additional thoughts and opinions from other contributors who have not participated yet.

[michael.orlitzky]

Replying to SirLouen:

Some key elements I want to highlight:

1. The From: part is kind of tricky regarding the hosting part. If you have a fully configured MTA in your server/webhost/whatever you are using, as long as you have the local part (the wordpress) mapped, it won't bring any troubles. The problem is that most hostings limit the mappings to X units, and aliases don't count.

Apologies, but this is very misleading. If your organization's mail is hosted at O365 and if your website is hosted at Bluehost, creating a mailbox for wordpress@$SERVER_NAME is not going to do anything. You will still fail SPF/DKIM in every scenario where you would have failed it before. The only situation where this could possibly help is when the recipient uses​sender address verification. But sender address verification is considered abusive, never worked reliably, and is mostly gone.

I have not used regular web hosting for ages, but the last time I dealt with one I remember that just creating the mailbox for wordpress with my associated domain DNS pointing fully to the hosting was more than enough to make the WP mailing system work flawlessly. So from a very basic user standpoint, just explaining in the Health Check that they need to create said mailbox will be more than enough (or edit this with the corresponding hook). For the “advanced administrator” that needs to configure his MTA accordingly, here is where the Administration Handbook entry comes into play.

This will almost never help, because sender address verification is almost never the problem. Moreover, "nobody" hosts their email on their web server (check the market share of Gmail + O365), so this advice is impossible for most people to follow.

2. I still need to review the book entry more deeply. Despite it was merged some months ago the link was not even added, so it is not published yet. I think that the major problem that administrators are having is with the Sender address itself (not the wordpress@host address in particular). In fact, in some of my servers I use a wordpress@mail.host.org format because I host the core domain for corporate emails in a different mail server. So the reality is that if the administrators can't deal with the filter hook… they have a serious problem.

There is no "Sender" address. It's important to be clear about what we're trying to fix. There are a few potential issues:

1. Sender address verification: can be ignored in 2025, but regardless, only cares about the SMTP envelope sender that is sent during off-site mail transmission.
2. DKIM: only cares about the From: header.
3. SPF: only cares about the SMTP envelope sender.

All three are related in that, when sending mail locally via mail(), there is no SMTP transaction, and your MTA has to guess an envelope sender to be used when it eventually relays the mail off-site. The common linux MTAs will use the From: header by default, unless you override it via PHP's sendmail_path (not a great workaround because it affects every message sent from PHP). So in all likelihood we are talking about the From: header in all cases.

[michael.orlitzky]

Replying to knutsp:

Replying to SirLouen:

No need to save anything, other than caching it. I mean a Test (those automatically performed when visiting Site Health). As we know, that page performs tests, then displays the results, what they mean, explains what the implications are and so on. In case of failure, the user may be advised to create a forwarder to null ("blackhole"), to an existing address or create a full account.

The test may just try to send to the From adress with SMTP (default: wordpress@[server.host]), not actually sending any message, using VRFY or RCPT TO. With the latter, the MX will either accept it and invite to go on or reject it as non existent. The response code can be turned into a boolean (success/unsucessful). Or actually send a test message, but that would require a user initiated test, as in the plugin "Site Health Tools".

I may be able to make a tiny plugin to demonstrate this concept, implemented as a Site Health Test, if this is the way to go.

Again, apologies for sounding rude, but this is just doomed to fail. The theoretical problem is that sending to the From: address is not meaningful unless the server it lives on implements the same SPF/DKIM checks that other recipients will (sender address verification is almost never the problem). The practical issue is that "is this address deliverable?" is not a boolean. A lot of things can go sideways:

1. You're bypassing the MTA's configuration... what if it uses a relay host and the web server is blacklisted?
2. You have to pick a HELO name that both passes SPF and is valid for the web server.
3. What do you do if there's a temporary DNS error?
4. What do you do if you manage to connect but the connection is dropped?
5. What do you do if everything goes OK, but at the very end, the server sends you a 4xx mailbox full?

An MTA is equipped to handle all of those scenarios, and the web server's MTA is (should be) properly configured. But if all you get is a one-off SMTP session where nothing is configurable, you're going to get wrong answers and confuse the hell out of people trying to explain to them problems that don't exist.

If site health is the way to go, the best we can hope for is a warning that no address was configured and that you have to write a plugin or modify your theme to configure one (both of which are insane :P)

[knutsp]

Replying to michael.orlitzky:

1. You're bypassing the MTA's configuration... what if it uses a relay host and the web server is blacklisted?

Fail.

2. You have to pick a HELO name that both passes SPF and is valid for the web server.

Fail.

3. What do you do if there's a temporary DNS error?

Temporarily undetermined result.

4. What do you do if you manage to connect but the connection is dropped?

Temporarily incolclusive result.

5. What do you do if everything goes OK, but at the very end, the server sends you a 4xx mailbox full?

Success. Not relevant.

In my view, the only problem WordPress should care about is that the From address should exist, whatever it's configured to be. The fact that this may not be reliably checked doesn't make it unusable.

What will really be bad is an user facing option where users may blindly enter myname@… or whatever they think could look nice. These are emails from the WordPress installation on the domain. Being able to send emails from that domain is a requirement.

A simple canonical plugin to change the From to whatever is probably the best solution for those who do not make their own or use SMTP plugins. It should come with the same warnings. To check that it will alway work is complicated, not to say impossible, without trying to send a message. That it's valid and exists, is the first thing, and the only thing WordPress reasonably can do.

Why NOT just use an SMTP plugin for complicated configurations? Those I have used let's you also set From. The solution to "Default wordpress@… sender address can be problematic" is using SMTP with authentication.

That's all. I wonder why I started participating on this ticket. I'm out.

[SirLouen]

Replying to michael.orlitzky:

This will almost never help, because sender address verification is almost never the problem. Moreover, "nobody" hosts their email on their web server (check the market share of Gmail + O365), so this advice is impossible for most people to follow.

@michaelorlitzky I think we are mixing concepts here. Surely Google and Microsoft, could be leading in terms of email service. But here we find two main scenarios:

Beginner User

A novice user pretty much purchases the domain in the same hosting that is going to provide his WordPress installation, namely, Bluehost, Hostinger, etc... (or at worst, they may purchase it outside, and be asked by the host to set the DNS pointing to them). The host will set your DNS to their own instance and they will get everything configured for you, including the wordpress@yourdomain.whatever.

Here the big question as I commented to @desrosj is, for those hostings with limited number of inboxes for local parts (say a limit of 50 inboxes), I'm not sure if they include wordpress one for free, or if they actually expect you to create one. In any case, a notice in the Health Check will be useful for either changing it via plugin/hook/functions.php, or suggesting to create such inbox or to be aware if that inbox is a valid receiving option. Here is where the check that @knutsp was proposing takes place. And this is only relevant, for the reply part (so the replies are not lost for the beginner).

Advanced User

The advanced user, in this case, a person like you that has his main mail service outside, say Google Workspace, but needs the local MTA installed with WP to operate.

Firstly, I'm assuming that SPF and DKIM are out of this equation correctly configured. Neither SPF and DKIM care about the local-part. You can pretty much use any randomized local part and it will still get through as long as the domain has the SPF pointing to your WP host and a DKIM selector with the public key rightly configured to match the WP local MTA

A different topic here is, as I said in my previous post, if you want to have a different domain for your MTA. Instead of using your domain example.com, like I do in many installations, you want to have mail.example.com here. In this case, you definitely need to change your From:. Here is where the hook takes place and this should be also documented in the Health Check plus the Administration Handbook. But as I say: If you are so pro to by using a setup like this, you should know that WP is a hook based framework, so the expectation of having to add the code must be high.

=====

Now let's move into the health check part, as @desrosj already commented, we should put these concerns in #62129 as this is where we will be working on.

I'm going to copy all the concerns and answers there to continue the conversation on that topic.

Replying to knutsp:

That's all. I wonder why I started participating on this ticket. I'm out.

As @desrosj suggested you just focus on #62129, which is the direction we will be taking. This has turned out to be a philosophical report.

[michael.orlitzky]

Replying to SirLouen:

Beginner User

A novice user pretty much purchases the domain in the same hosting that is going to provide his WordPress installation, namely, Bluehost, Hostinger, etc... (or at worst, they may purchase it outside, and be asked by the host to set the DNS pointing to them). The host will set your DNS to their own instance and they will get everything configured for you, including the wordpress@yourdomain.whatever.

I agree that these people exist, and that they should be completely supported. (If you look at how I spend my time you'll see that I'm not a friend of Microsoft, Google, or... anyone else.) But I also know that the absence of a wordpress@ address is not going to cause them any deliverability problems, except maybe to themselves. This is a red herring.

Advanced User

The advanced user, in this case, a person like you that has his main mail service outside, say Google Workspace, but needs the local MTA installed with WP to operate.

Firstly, I'm assuming that SPF and DKIM are out of this equation correctly configured. Neither SPF and DKIM care about the local-part. You can pretty much use any randomized local part and it will still get through as long as the domain has the SPF pointing to your WP host and a DKIM selector with the public key rightly configured to match the WP local MTA

This has been called a complex configuration or an advanced use, but the reason I keep bringing up Google and O365 is that, if you look at the numbers, this is the common case. You may assume that SPF and DKIM are out of the equation, but that's not realistic. Google and Microsoft make it easy to enable SPF/DKIM/DMARC with the click of a button, and in any reasonably sized organization, the website and email are going to be on opposite sides of an organizational boundary.

We have a few clients in the medicaid industry. They're governed by HIPAA, the Affordable Care Act, and a bunch of other regulations. While their email handles sensitive information, their website (effectively an advertisement) does not. There's an internal team of people involved in keeping their email secure; then there's us, a bunch of strangers in another state, who manage the website. There's no way in hell they're giving us the ability to DKIM-sign mail as them. And they're right! This is not just a contrived example, I agree with them -- it would be irresponsible to allow us to send authenticated mail from the domain that they use for their regular communication.

This isn't an outrageous scenario, and there are plenty of other reasons why a web host might not be able to change DNS records for a site they host (I've already mentioned this somewhere else). So there are two problems that can't be assumed away:

• No one knows that WP is going to try to send mail as wordpress@$SERVER_NAME, because they haven't configured it to do that. Even if they have access to the DNS, it's not obvious that they need to make changes.
• You will not always be able to get SPF/DKIM to pass for $SERVER_NAME. You must be able to change the From: address in that case.

[SirLouen]

Replying to michael.orlitzky:

This isn't an outrageous scenario, and there are plenty of other reasons why a web host might not be able to change DNS records for a site they host (I've already mentioned this somewhere else). So there are two problems that can't be assumed away:

I think that now we are moving in circles. Long story short: you would rather not add a plugin just for such a "simple feature."

• No one knows that WP is going to try to send mail as wordpress@$SERVER_NAME, because they haven't configured it to do that. Even if they have access to the DNS, it's not obvious that they need to make changes.
• You will not always be able to get SPF/DKIM to pass for $SERVER_NAME. You must be able to change the From: address in that case.

And this is the conclusion we got, but maybe not the way you expected. Instead of adding more options, we will be simply adding more docs.

[michael.orlitzky]

Replying to SirLouen:

I think that now we are moving in circles. Long story short: you would rather not add a plugin just for such a "simple feature."

I'm happy patching WP, but no, I don't share your optimism that normal users will spend a day learning how to write a WP plugin just to change one setting. If the users aren't on board, plugin devs will have to keep using the admin address, and nothing will change.

And this is the conclusion we got, but maybe not the way you expected. Instead of adding more options, we will be simply adding more docs.

This could be OK if the docs are accurate, but the suggestions I've seen so far are testing and suggesting the wrong things. If wordpress@$SERVER_NAME exists and if you can send mail to it, that means nothing. And conversely, if you cannot deliver mail to wordpress@$SERVER_NAME, that also means nothing.

[SirLouen]

Replying to michael.orlitzky:

This could be OK if the docs are accurate, but the suggestions I've seen so far are testing and suggesting the wrong things. If wordpress@$SERVER_NAME exists and if you can send mail to it, that means nothing. And conversely, if you cannot deliver mail to wordpress@$SERVER_NAME, that also means nothing.

I think we are mixing ideas. I know I'm not going to convince you because you want the change. But at least I want to let you understand why your the current state is not so terrible as you think.

1. The basic testing for the validation that @knutsp was suggesting is only useful for the Reply-To part. Making users aware through a check that the Reply-To is, by default, configured to wordpress@hostname. It is not a matter of email authentication; it's just a sanity check that is not even reliable but at least could be a heads-up (and not the sole check; again, refer to #62129 for more info).

2. About the DKIM part you have mentioned multiple times, you have to be aware that DKIM is simply an integrity authentication check. It only checks if the content has not been made up and is coming from who says to be the trusted source. This is 100% mail-server-side, nothing to do with WP.

3. About the SPF, here is the tricky part. You could perfectly have the SPF with a subdomain or even your domain configured to the IP of the server. The HIPAA guy's or whoever you are working with might whitelist in their SPF record for the IP of your server, and things will go fine. The local part (wordpress) is completely irrelevant when we talk about the SPF check. For the DMARC check, you only need to make sure that the From: part is the same as the delivery server hostname. And since WP is taking by default the hostname of the site, it will always match (unless certain weird scenarios with certain mail servers, but this is another story).

4. Finally, let's say that they don't want to configure the SPF record, and you have to relay through another domain. Let's be clear: if you have to do this, you are a pro.

I'm happy patching WP, but no, I don't share your optimism that normal users

You are not a “normal user”. Here you fall into the category of “pro users”, and pro users are directed to the Administration Handbook, and it's not crazy that they are instructed on the use of simple hooks.

And I see you overly worried about such "normal users", but the average Joe is not going to have any troubles with the current state of the art as long as they configure their server correctly to present their DKIM keys accordingly and have their DNS records set-up orderly for SPF, DMARC, and DKIM. Are they using email from both O365 and their WordPress site? Just configure their SPF whitelisting both addresses. Do they need to correctly DKIM sign their sent emails? Configure two DKIM selectors in the DNS, one per server. Basic mail administration.

Do they need to configure another domain or subdomain for their WP server? Again: You are a Pro. You are not a "basic user." I have to leave this clear.

And for the 80% of the SMB users who are simply dependent on their cPanel/Plesk/DirectAdmin/Hosting panel just hang with a domain that happens to be managed by the same people that provide them email, backups, email marketing, and maybe an SEO package. These guys won't care more about anything but the fact that they receive the replies to the sender's email in an inbox they control and they don't lose communication with their clients/partners/subscribers/friends.

From here I don't really know where the conversation could lead, but keep moving in circles. I can explain if there are more doubts, or if there are more edge-case scenarios, but for this to be useful, there should be more proposals apart from the ones commented (health check, docs, a possible canonical plugin) and rejected (new fields on the admin interface).

[mvl22]

As someone who runs a fair number of WordPress installations across multiple organisations, I continually run into this problem. I do think this really has to be addressed.

Mail deliverability security is nothing like it was 20 years ago when https://core.trac.wordpress.org/changeset/3214 was created. No credible mail system will now just blindly accept a randomised webmaster@[domain] address without the relevant DNS set up for it.

I have plenty of installations whose domain does not have an associated MX record, and will not have for security as we do not want to be processing incoming e-mail. Instead, we want to be able to set a general address used by the server administrator who is responsible for security, since it is they who are responsible for patching etc and so need to see notifications.

I think forcing the requirement to create a plugin and define a wp_mail_from value is not really an acceptable workaround (though it should remain in place). Update notifications are a security matter. The from address should therefore be settable by an administrator easily, just as any other setting is.

To me the solution is straightforward and simple, and can be implemented in a backwards-compatible way.

Currently there is a hard-coded use of webmaster@[domain] set by this:
​https://github.com/WordPress/WordPress/blob/550376599471c7f7b0560766a06980ba3fe15acc/wp-includes/pluggable.php#L407-L426

There should simply be an optional mail_from admin setting added, and that isSet() block at the start return the mail_from value if it is non-empty.

wp cli should then be able to set the mail_from admin setting, so that we can then add this to existing scripts. The inability to script this at present is a major pain.

This does not break BC because only those who care about this problem need to set the mail_from. Everyone else will continue to get spam-filtered notifications if they don't have MX/SPF set up or whatever and suffer the downsides of that. But they now have a simple setting to change it if they want.

NB I do not think Wordpress should be making any attempt to test the deliverability of the address. It is the job of the sysadmin to set something that will work. Messing about with VRFY or RCPT TO checks etc should be entirely out of scope. SPF/DKIM/DMARC mean that the DNS system already provides de-facto protection against fake addresses being used for spam purposes, and frankly a Wordpress security notification is hardly useful as a spam route (and the existing wp_mail_from route is already a way to do that, so this is not adding a new spam vector).

[amanandhishoe]

The underlying issue is that sending email is no longer simple. Many mail servers now reject messages when SPF does not align with the sending domain, and DKIM and DMARC are effectively mandatory for reliable delivery. This complexity is difficult to explain to users who simply want a website and working email.

Email configuration itself is beyond the scope of WordPress core. However, WordPress could provide guidance. For example, Site Health could check whether SPF, DKIM, and DMARC records exist for the domain and show a notice such as:
“Your domain does not publish SPF, DKIM, or DMARC records. Emails sent from this site are likely to be rejected or placed in spam.”

[SirLouen]

Replying to amanandhishoe:

Email configuration itself is beyond the scope of WordPress core. However, WordPress could provide guidance. For example, Site Health could check whether SPF, DKIM, and DMARC records exist for the domain and show a notice such as:
“Your domain does not publish SPF, DKIM, or DMARC records. Emails sent from this site are likely to be rejected or placed in spam.”

Yes, that could be an option to be added. We were already discussing about health checks for this purpose like #62129

Replying to mvl22:

I think forcing the requirement to create a plugin and define a wp_mail_from value is not really an acceptable workaround (though it should remain in place). Update notifications are a security matter. The from address should therefore be settable by an administrator easily, just as any other setting is.

Nowadays security updates go on point releases which are automatic by default regardless of the major version you sit in (if still supported). So if you want to deactivate this automatic updates for point releases for any reasons, I would seriously rethink taking your time into supporting the mail behaviour with whatever hooks it's required.

One thing that I have commented above in many other posts is the nature of the current mail system in WP. This is not something I support, but is worth knowing to understand how troublesome it is to change. Mail all around currently is a pluggable (a.k.a. meant to be managed through a plugin). One of my plans is removing this "pluggable" status in the future, with how things are going I would look minimum into 7.1 or 7.2, nothing closer.

About the frontend field expectations, I always thought that a frontend place to add the from address (and probably the From name), could be great as these are very useful fields and setting up mail in a trustworthy way should be something that every single WP user should take his time to set up, just like any other feature, as mail is the current and long-term main notification medium (there were plans of extending the notifications API but this is not going to happen any time soon)

I've seen myself in endless discussions about new Frontend inputs that get to nowhere, and then I see things like this:

and

It's a 🤦‍♂️

Currently, all the frontend updates are surging in the "Appearance" tab (that is being controlled by the Gutenberg team). It's remarkable because most new items are going to even have the new interface. So I'm still thinking how to give this a plot twist to avoid inferencing in the Jurassic Park admin menus. Surely, we will see a From address one day somewhere.

Long story short: don't expect anything anytime soon, but eventually, we will see some improvements.

[dmsnell]

#64420 was marked as a duplicate.

[dmsnell]

Every time I dig deeper into this general topic the list of tickets expands the emotional heat increases 😅

Let’s do our best to remain professional; this is a passionate topic for folks, and I want to stress that it will be most helpful if we stick to our own experience and not attempt to speak for others, whether asserting the motivations we assume they must have or the assumption that something that seems clear to us is obvious to others or even accurate.

WordPress can only stand with "golden rules", not with all the theories that help you push up your rankings or like in this case, help deliverability based on some "relatively well known rules"…

I want to pause and hopefully direct the energy into what I want to see us all work towards: that wherever we have control, we can improve the ecosystem together, even when that means going beyond or in contrast to RFCs and other specs.

What matters most to me is that inasmuch as we are able, that we can find ways to improve mail deliverability and influence each other towards more robust configurations and systems. Sometimes really good things come from solving the problem “at the wrong end of the chain of responsibility.”

WordPress is meant to simplify the life of the exemplary users not the system administrators that should have all the tools in the world to make things happen

Email is collective problem and I want us to find ways to help end users and system administrators.

A simple canonical plugin to change the From to whatever is probably the best solution for those who do not make their own or use SMTP plugins

This seems like the correct state of things, apart from the fact that there’s no “canonical” part, but since the plugin to workaround the issue is so small, I don’t know how much it would rise to the level of needing a canonical adoption.

---

Thank you all for sharing your expertise on this, by the way. There are some questions I have right now after getting through this and a few other related tickets on the matter:

• Do any of us we have real metrics from 6.9 to indicate if the change to adding a default Envelope Return-Path to wordpress@host() was a net help or hindrance for deliverability? I understand that some mail hosts are concerned about long-term IP reputation, but this problem has wildly different imperatives if we fixed 80% of mail issues and created 2% new problems, vs if we solved 5% of mail issues and created 60%. I made up those numbers. The point is without knowing these numbers it’s near-impossible to agree where we stand. A revert of the change could be warranted, but considering how all of the discussion led us a bit astray in the original ticket, I would like to see some substantiation for the claims before we overreact and removed what could be a net win, albeit with its own unintended consequences that still need to be worked out.

• Do we have any tools through .well-known directories, DNS, or at the host-level which could be used to communicate into WordPress to establish a better Return-Path?

• If you are a host dealing with this issue, what technically makes it easier to work with WordPress emails that are sent with systemuser@local.system.hostname than wordpress@public.hostname()?

• If you are a host dealing with this issue, do you send all bounce emails to the same address for all hosted sites? Are there any potential privacy issues with this practice? How does receipt of bounce messages and DMARC notices get relayed to the site owner?

• “I do not think WordPress should be making any attempt to test the deliverability of the address” @mvl22 would you care to share more about why? in the case that email is setup appropriately, would it be difficult to positively identify a proper return-path address? in which cases would an attempt be misleading? in other words, I would imagine that a failure to detect delivery might not say anything, but a confirmation of delivery would. I have no idea how to detect deliverability so maybe you are saying WordPress doesn’t have an avenue to do so?

From my perspective, adding a Site Health section for email sounds like a high-priority task to start working towards a better future. Even if all we do is highlight that there is no Return-Path set, that provides the starting communication to direct people to where to figure this out. There’s a nice-looking mockup of the first step in #62129.

---

Final reminders, and this is not specifically for this ticket, but based on discussion in this and related tickets: please refrain from suggesting that if people have a different perspective on this problem that they are ignorant of some knowledge you hold; please refrain from suggesting that if people were knowledgeable that they must agree with your ideas of how this ought to be; please refrain from making declarations how someone else feels, reacts, thinks, or works.

We should remember that if the solutions were easy or straightforward it would not be likely that we would have years of attempts and debate on how to resolve this. Everything we do will likely make someone’s job more difficult; hopefully as we progress we minimize that — this is exactly why we’re discussing this, because we all want to solve this problem.

[SirLouen]

Replying to dmsnell:

Email is collective problem and I want us to find ways to help end users and system administrators.

The biggest concern here is that ultimately we have to choose, it's very hard, and in certain cases, almost impossible to satisfy both groups. It doesn't matter how much discussion we can go through

[michael.orlitzky]

Replying to dmsnell:

• Do any of us we have real metrics from 6.9 to indicate if the change to adding a default Envelope Return-Path to wordpress@host() was a net help or hindrance for deliverability?

What changed in 6.9? I haven't noticed any new problems, but the Return-Path was never a problem for us to begin with:

1. It can be set in php.ini by using "sendmail -f" as your sendmail_path
2. The recipient doesn't see the Return-Path, so you can set it to anything you want to get SPF to pass

Conversely, the "From" address can not be changed, and the recipient sees it, so it is more important and harder to fudge. If I want to send "From" a domain, I need to obtain secret keys or DNS access from the owner.

• If you are a host dealing with this issue, what technically makes it easier to work with WordPress emails that are sent with systemuser@local.system.hostname than wordpress@public.hostname()?

You may not be authorized to send mail as public.hostname(), and you may not be in a position to change that. (The same is true for local.system.hostname, it really needs to be configurable.)

• If you are a host dealing with this issue, do you send all bounce emails to the same address for all hosted sites? Are there any potential privacy issues with this practice? How does receipt of bounce messages and DMARC notices get relayed to the site owner?

The system admin gets the bounces, and rarely the site owner or web developer does as well. There are a few reasons for this,

1. Usually, the bounces indicate a problem with the server and not with the site (blacklisting, spam attack, etc.)
2. When that's not the case, it's some problem that the site owner can't fix, like the fact that WordPress insists on using the wrong sender address :)
3. There's no (additional) privacy issue because anything your site does can be seen by the server admin
4. Most of our customers are non-technical and just don't care unless there's a problem; and when there's a problem, they're going to call us about it anyway

in the case that email is setup appropriately, would it be difficult to positively identify a proper return-path address? in which cases would an attempt be misleading? in other words, I would imagine that a failure to detect delivery might not say anything, but a confirmation of delivery would. I have no idea how to detect deliverability so maybe you are saying WordPress doesn’t have an avenue to do so?

Yes, it's "impossible" to tell whether or not an external address is deliverable. Particularly if all you are doing is handing the message off to /usr/bin/sendmail, since sendmail will succeed immediately and the MTA will attempt delivery later. (And if you try to use something other than sendmail on a server that usually uses sendmail, you are testing the wrong thing.)

[michael.orlitzky]

Replying to SirLouen:

Replying to dmsnell:

Email is collective problem and I want us to find ways to help end users and system administrators.

The biggest concern here is that ultimately we have to choose, it's very hard, and in certain cases, almost impossible to satisfy both groups. It doesn't matter how much discussion we can go through

It's absolutely trivial to make both groups happy in this case. I've been told that the problem is,

But there is a WP theory, that WP should work somewhat like a framework, with the minimum fields possible in the backend. If one field is not 99.99% essential, it should go away. And instead of adding a million fields that customize everything to the minimum detail, WordPress uses a "hidden field" strategy with the concept of "filter hooks".

You can't blame the users or admins for that.

[dmsnell]

@michaelorlitzky in WordPress 6.9, mail started being sent with wordpress@site.com as the envelope sender/return path/mail from address. This is still configurable via the wp_mail_from filter so it’s well within reach to change it, but there is no UI setting in wp-admin for it — it requires a few lines of code in a plugin.

In the process, #64368 appeared for when people were passing the -f CLI arg as part of the sendmail_path and that created unexpected crashes. That specific interaction bug between the reportedly invalid use of -f inside the sendmail_path and the change in WordPress will be resolved in the 6.9.1 release (whereas if that arg is present then WordPress will try and avoid setting the return-path again).

ultimately we have to choose…it's "impossible" to tell whether or not an external address is deliverable…It's absolutely trivial

Since so many people are extremely confident in contradictory extremes it leads me to believe that the extremes are not where we’ll resolve this issue; if that were truly the case I would think we all would have either solved this or given up entirely. So while there’s debate, we can keep trying to find creative solutions.

In the preparation for #49687 I sent test emails to ​aboutmy.email and that provided helpful knowledge about what actually left WordPress and the shared host it was on. Perhaps there is opportunity for a WordPress.org service where we could report back on test email. I know that opens a can of worms for security and spam and abuse, but perhaps we can find a way to create a temporary service which can assert various information about the mail, including SPF, DMARC, and DKIM verification, and even attempt delivery to the sender address.

I’m also wondering if there are not solutions out there for hosts to provide information to a service on when the last messages appeared in their controlled return-path mailbox. If WordPress could know it sent out emails, but has never received any messages in the return, it could raise a notice “Without having received messages, we cannot be sure that the email is configured properly. Check XYZ.”

---

Based on my extremely limited exposure, it seems like something could be better with the integration of these email settings and WordPress. It also seems a bit suspect to be handing out private information in the mail headers, such as the local Linux username and local hostname.

I would have rather expected a host to override mail settings and send something with a return path like mail-info@cheap-vps.net rather than cd16557@n05-cluster2.local.

[michael.orlitzky]

Replying to dmsnell:

@michaelorlitzky in WordPress 6.9, mail started being sent with wordpress@… as the envelope sender/return path/mail from address.

Oh, wow, thanks, this has affected us. Ever since the upgrade, we are throwing away mail to every domain that checks SPF. But of course I'm not getting the reports, because WP is overriding the Return-Path with an address that doesn't exist.

In the preparation for #49687 I sent test emails to ​aboutmy.email and that provided helpful knowledge about what actually left WordPress and the shared host it was on. Perhaps there is opportunity for a WordPress.org service where we could report back on test email. I know that opens a can of worms for security and spam and abuse, but perhaps we can find a way to create a temporary service which can assert various information about the mail, including SPF, DMARC, and DKIM verification, and even attempt delivery to the sender address.

I think you will find certain common scenarios impossible to replicate, like the spam filtering on the real mail server, or the fact that the real mail server for example.com knows that wordpress@… does not exist and will reject your mail based on that.

I would have rather expected a host to override mail settings and send something with a return path like mail-info@cheap-vps.net rather than cd16557@n05-cluster2.local.

That's what we do. We use postmaster@ specifically since it bypasses spam filtering. (Or so I thought. Now I see that since 6.9 they are coming from wordpress@$sitename and bouncing into the void.)

[dmsnell]

Since you are not the only one using this language @michaelorlitzky, it makes me curious. Why do people say specifically that WordPress is “overriding” the return-path when it’s just setting the value through the intended and documented argument to PHPMailer?

Is this a rant or are people making a claim that WordPress/PHPMailer has somehow broken the system by allowing a mail-sending server to specify the return-path?

I thought that the configurability was there specifically so that mail-sending servers could use the appropriate return-path address, whatever that might be. If that is truly the case, isn’t passing a value just setting the return path?

[michael.orlitzky]

Replying to dmsnell:

Since you are not the only one using this language @michaelorlitzky, it makes me curious. Why do people say specifically that WordPress is “overriding” the return-path when it’s just setting the value through the intended and documented argument to PHPMailer?

Semantics, but since I was using sendmail -f to set the envelope sender, it is now being overridden via the second -f.

[dmsnell]

Semantics, but since I was using sendmail -f to set the envelope sender, it is now being overridden via the second -f.

Thanks for clarifying. It’s a hot topic, so I am trying hard to stick with factual statements to avoid triggering different folks. I am led to believe that using -f in the sendmail_path is another one of these “invalid but standard” practices, and that it would be much easier for all parts of the system to cooperate if the return-path were set via wp_mail_from.

In 6.9.1, by the way, WordPress will avoid sending a second -f if it detects one in sendmail_path — that was an oversight when the patch was merged into 6.9.

[amanandhishoe]

Addresses designated to handle bounces in an email’s envelope (the Return-Path / MAIL FROM address) exist for one primary purpose: receiving and processing delivery failure reports. In practice, they serve several distinct but related functions:

• Receive non-delivery reports
• Enable automated bounce processing
• Support SPF, DKIM, and DMARC alignment
• Prevent backscatter and forged replies

What envelope bounce addresses do not do:
They are not intended for:

• Human replies
• Customer support
• User-visible communication

Those functions belong to the From or Reply-To headers, not the envelope.

It is critical that a valid email address exists in the email’s envelope (the Return-Path / MAIL FROM address). This address is entirely independent of the visible From address. Humans do not read bounces or failure notices sent to the envelope address; they are handled by automated mail systems and bounce-processing software.

Because the envelope is created and finalized by the underlying mail transfer agent (MTA) or transactional email service, WordPress itself is not in a position to reliably define or manage the envelope sender. Attempting to do so at the application level risks misalignment with host- or provider-level mail configuration and can lead to delivery and authentication failures.

[michael.orlitzky]

Replying to dmsnell:

Thanks for clarifying. It’s a hot topic, so I am trying hard to stick with factual statements to avoid triggering different folks. I am led to believe that using -f in the sendmail_path is another one of these “invalid but standard” practices, and that it would be much easier for all parts of the system to cooperate if the return-path were set via wp_mail_from.

It is certainly a bug that PHPMailer will blindly append a second -f, but passing parameters to sendmail has been a documented use case of sendmail_path in PHP forever.

The reason these issues (there are many like this one) were opened is because guessing the "From" address is fundamentally wrong, and will cause mail to be lost. I said in my first message of the day that

Return-Path was never a problem for us to begin with:

1. It can be set in php.ini by using "sendmail -f" as your sendmail_path

The reason you are getting complaints is because 6.9 invalidated this. Now the envelope sender is just as broken as the "From" address, so WP is losing even more mail than it was.

[amanandhishoe]

The envelope (the Return-Path / MAIL FROM address) receives a variety of delivery status notifications, not just permanent failures (hard bounces). It is also notified of temporary failures such as “mailbox full” or “server busy, try again,” as well as other policy- or network-related delivery responses. These notices are not meant to be handled by humans, which is why the envelope sender must be set by the mail transfer agent (MTA) or transactional email service, not by WordPress.

[dmsnell]

thanks also @amanandhishoe.

for everyone in this discussion, let’s get one thing out the door though to keep the communication simple:

• nobody is discussing Reply-To addresses. ONLY the Return-Path/Envelope From/MAIL FROM/Sender address is in scope.
• the matter of having duplicate -f parameters is out-of-scope and slated for resolution in 6.9.1.
• it is widely-understood that the -f parameter in the sendmail_path has been documented; it has also been established that the documentation should not have provided that. (unfortunately we have a large shared legacy of documentation in PHP misleading people on how to reliably interoperate).

if anyone else wants to write something about Reply-To or From, please don’t 😅 — it’ll just muddy this conversation.

---

Because the envelope is created and finalized by the underlying mail transfer agent (MTA) or transactional email service, WordPress itself is not in a position to reliably define or manage the envelope sender.

How would you propose that a WordPress site establish the Return-Path when the mail is not handled by the service hosting the site? To borrow some other discussions, for example when mail is handled via Office 365, Gmail, or Proton?

Attempting to do so at the application level risks misalignment with host- or provider-level mail configuration and can lead to delivery and authentication failures.

We can remember too that this entire struggle starts with misalignment and delivery failures that are due to the existing default-generated Return-Path. As far as I can tell, everyone agrees that we want deliverable mail. We have risk with or without it.

What makes application-level configuration riskier than host-level configuration?

WP is losing even more mail than it was

@michaelorlitzky I appreciate you sharing this, but everyone is kind of tossing around these claims and I would really love to see numbers. that is, I don’t want any of us to have to guess or pick whose opinion is more trustworthy given that we have these contradictory claims.

are you able to report or estimate delivery issues against total number of sites/email attempts on your host?

---

With this next question, please understand that I’m trying to learn and understand everyone’s needs and that I’m not proposing a solution.

From a host’s perspective, if we are already overriding or setting the Return-Path for emails, would it not be possible to also override the wordpress@site.com address?

• Is it non-trivial to know the site.com part for a given node/site?
• Is it non-trivial to rewrite the Return-Path?

---

One more burning question I have is this: if the -f parameter is set in sendmail_path and that’s respected by WordPress, is there still an issue from the host side? It seems like this is the fix that everyone wants: a host can override what’s set by WordPress, but a WordPress plugin can also intervene and definitively set a proper Return-Path when a valid mailbox exists.

---

I’m going to take a short pause from this to let other people speak and digest what y’all are saying. I am certainly open to a revert of [61010] if there’s agreement for it, but it seems from what everyone is saying that the primary issue is that a non-plugin-modified Return-Path should take a secondary role to a -f argument in sendmail_path.

[knutsp]

WordPress 6.9 now, finally works, without any actions and filters, to send emails reilably on all hosts I have experience with. All test pass. Thanks!

But, of course, a MTA operators must be able to override it, when made deliberately and correctly. It's not setting it at all that may causes failures.

What needs to be fixed is that it can be overriden by the -f parameter in the path.

Wheter the bounce messages is meant for either humans or systems is irrelevant, they are for both automated systems and for humans, as most in programming that is not raw binary code.

[siliconforks]

Replying to dmsnell:

thanks also @amanandhishoe.

for everyone in this discussion, let’s get one thing out the door though to keep the communication simple:

• nobody is discussing Reply-To addresses. ONLY the Return-Path/Envelope From/MAIL FROM/Sender address is in scope.

...

if anyone else wants to write something about Reply-To or From, please don’t 😅 — it’ll just muddy this conversation.

I think maybe you're confused about what this ticket was originally about? To clarify: this ticket (#60420) was originally specifically about the From: header address. I guess you could argue it's now about the From: header address and the envelope sender, since those are now the same since version 6.9, but originally when it was opened (almost 2 years ago) it was just about the From: header address.

(I agree that the Reply-To: header is not relevant here.)

[SirLouen]

Replying to knutsp:

What needs to be fixed is that it can be overriden by the -f parameter in the path.

Conversations have become so massively big, that it's hard to follow them. Long story short this has been already scheduled for 6.9.1

It is critical that a valid email address exists in the email’s envelope (the Return-Path / MAIL FROM address). This address is entirely independent of the visible From address. Humans do not read bounces or failure notices sent to the envelope address; they are handled by automated mail systems and bounce-processing software.

Nothing hinders sysadmins from having a valid email (and it doesn't even need to be valid, as long as is not refused).

Also, and in the ultimate worst case, MTAs that sysadmins control have the final word. Any web hosting maintainer, can easily override the PHP's -f in Exim, Postfix, Qmail, Sendmail, or whatever it's being used.

But as we suggested here #62129 I agree that more health checks could be useful to inform users that their From addresses should exist (and transitively now, their Sender).

Because the envelope is created and finalized by the underlying mail transfer agent (MTA) or transactional email service, WordPress itself is not in a position to reliably define or manage the envelope sender

This is not necessary true. Moreover, is not WP itself, but the underlying mailing library (PHPMailer), which defaults this. In fact WP remove the defaults back in the day not because of this, but another completely unrelated issue. This should have never been removed, but I was not around back in the day to further discuss that decission. Any client is in the position to define whatever Sender is more convenient, any user can override this easily and MTA should abide and better improve to whatever Sender is being received.

Also, I still can't understand why you are completely ignoring the DMARC's SPF alignment. As @knutsp has said, now all tests pass straight out of the box even on relatively hostile hostings.

(I agree that the Reply-To: header is not relevant here.)

We were talking at some point about Reply-To, because it was also formed following the same principles (related to the From which was the starting point of this ticket).

From my position I only get these actionable items:

1. Consider in the future how to add a nice From address input somewhere in the Admin section
2. Wait for 6.9.1 and see how it goes for all people that were having troubles.

For the rest I know it's frustrating for some, but there is no solution without returning to the wrong past scenario.

I'm in the urge of reopening #64420 because this is so messed up now that all concepts are starting to get scrambled.
Please, let's keep this topic for the From part, and move to #64420 for the Sender(MAILFROM`) part.

[michael.orlitzky]

Replying to dmsnell:

• it is widely-understood that the -f parameter in the sendmail_path has been documented; it has also been established that the documentation should not have provided that.

I don't believe this. I see that the author of https://core.trac.wordpress.org/ticket/64368 is fond of stating it without justification, but the only discussion upstream is this Github issue with no comments: ​https://github.com/php/php-src/issues/20648

It is unfortunate that duplicate values of -f can cause some sendmail implementations to crash, but Wordpress has no business guessing the wrong address and trying to pass it to sendmail in the first place. Personally, I would have preferred it to crash than lose mail for two weeks.

What makes application-level configuration riskier than host-level configuration?

I don't think this is the argument that anyone is making. Neither is inherently more risky than the other. What is risky is using an invalid address that was pulled out of Wordpress's butt to override an address that the host has explicitly specified.

WP is losing even more mail than it was

@michaelorlitzky I appreciate you sharing this, but everyone is kind of tossing around these claims and I would really love to see numbers. that is, I don’t want any of us to have to guess or pick whose opinion is more trustworthy given that we have these contradictory claims.

are you able to report or estimate delivery issues against total number of sites/email attempts on your host?

When you pointed me towards the new behavior in 6.9, I checked our logs. Whereas previously we had no mail going out from wordpress@$sitename, we now have lots of it going out from wordpress@$sitename, and many of those are rejected because our web server is not in the associated SPF record. We were failing 0% due to SPF in 6.8.x, and now we are failing more than 0%. The numbers are pretty unambiguous.

I monitor these things, but the emails informing me of the problem were being sent to nonexistent wordpress@ addresses.

Anyone who had a working system using sendmail -f to set the envelope sender will be in the same boat. And while it's possible that some people got lucky and are seeing better results with the new wrong addresses than they did with the old wrong addresses, they're still wrong addresses. It isn't an empirical matter.

With this next question, please understand that I’m trying to learn and understand everyone’s needs and that I’m not proposing a solution.

From a host’s perspective, if we are already overriding or setting the Return-Path for emails, would it not be possible to also override the wordpress@site.com address?

How? The "From:" header is in the body of the message. The best solution I have found so far is to patch Wordpress. This is easier and more correct than putting hooks in every theme, since I don't have to create a hundred child themes, and the changes do not propagate to other servers when a site is migrated. (When a site moves, SPF/DKIM alignment needs to be re-evaluated.)

One more burning question I have is this: if the -f parameter is set in sendmail_path and that’s respected by WordPress, is there still an issue from the host side? It seems like this is the fix that everyone wants: a host can override what’s set by WordPress, but a WordPress plugin can also intervene and definitively set a proper Return-Path when a valid mailbox exists.

This fixes the problem for the Return-Path, but then you still have all of the same issues with the "From:" address, and there is no way to override it.

[dmsnell]

#64420 was marked as a duplicate.

[mvl22]

It feels like this conversation has generated a lot of complexity, when the solution to the wrong assumption of <wordpress @ site.com> would be simple for the vast majority of cases: simply adding a setting to allow the mail from value to be set as a setting, like any other setting.

At the moment that has to be done using a plugin (proving the problem is already solveable), but that is really the wrong architectural level to set a configuration value. This is configuration (config), not site behaviour (plugins).

As I said:

There should simply be an optional mail_from admin setting added, and that isSet() block at the start return the mail_from value if it is non-empty.

What would be the downside?

Complex stuff like checking mail deliverability is a second-order issue and could be considered later. Personally I think that should be entirely out of scope. The key point is simply that server administrators should be able to configure the mail address string in the config without having to disrupt the installation itself by requiring a plugin to be added.

[mvl22]

“I do not think WordPress should be making any attempt to test the deliverability of the address” @mvl22 would you care to share more about why? in the case that email is setup appropriately, would it be difficult to positively identify a proper return-path address? in which cases would an attempt be misleading? in other words, I would imagine that a failure to detect delivery might not say anything, but a confirmation of delivery would. I have no idea how to detect deliverability so maybe you are saying WordPress doesn’t have an avenue to do so?

Because it's complex. I've no strong objection to it, but this is not the problem the ticket is actually describing. The problem is simply that WordPress assumes that the domain used by the site is enabled for deliverability, which is no longer a correct assumption in 2025. Therefore that address simply needs to be easily configurable.

If, having solved that problem, people want deliverability detection etc. to be solved also, fine. But we really must make the address configurable easily in the first place (i.e. not by having to write and deploy a plugin).

[dmsnell]

For those proposing the configuration option, what do you propose in the following situation:

• a site admin sets an address for the ever-confusing Return-Path
• a host set -f in the sendmail_path

In this situation, isn’t it the case that the hosts are still overriding the address but the site owner is now confused why the value they entered is not respected? If WordPress were to try and prefer the site admin’s choice, wouldn’t we be back here where this thread is discussing the fact that hosts want to override site choices to protect their IP reputations?

one thing I think I keep hearing is that hosts want control over this address and want that outside of WordPress. wouldn’t a configuration in wp-admin be tantamount to a plugin, in that hosts would still require site owners to make the changes themselves?

and how should discrepancy by indicated in the site config when -f is provided in sendmail_path? in a sense this same problem exists now with a plugin, but on the other hand the plugin is the result of a deliberate choice to set a specific value, and different plugins can choose different resolutions.

again, I’m not posturing for or arguing any solutions — just gathering inputs.

[michael.orlitzky]

Replying to dmsnell:

For those proposing the configuration option, what do you propose in the following situation:

• a site admin sets an address for the ever-confusing Return-Path
• a host set -f in the sendmail_path

In this situation, isn’t it the case that the hosts are still overriding the address but the site owner is now confused why the value they entered is not respected? If WordPress were to try and prefer the site admin’s choice, wouldn’t we be back here where this thread is discussing the fact that hosts want to override site choices to protect their IP reputations?

We're only upset that you're overriding our -f because the whole point of the -f is to fix the wordpress@$sitename debacle. If you made the sender address configurable, we wouldn't need -f on our WordPress vhosts, and then there would be no issues. This is how every other website manages to send email; it really isn't complicated.

1. Make the address configurable
2. Server admins remove the -f override
3. Somebody types a usable address into the box
4. No one is surprised by what happens
5. Everything works if you choose an address that you're authorized to use

(The precise details depend on how badly WP and PHPMailer decide to shoot themselves in the foot in response to all of these what-should-be non-issues, all for lack of a text box.)

and how should discrepancy by indicated in the site config when -f is provided in sendmail_path? in a sense this same problem exists now with a plugin, but on the other hand the plugin is the result of a deliberate choice to set a specific value, and different plugins can choose different resolutions.

There's really no discrepancy. All of these problems boil down to one thing: the lack of a text box to type in a usable address in a manner that is consistent with the design of WP, the internet, and hosting environments.