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).