`Could not instantiate mail function` errors sending mail in 6.9

[desrosj]

There have been some reports of wp_mail() failing to send emails after upgrading to 6.9. This was ​first spotted on the `r/Wordpress` subreddit, but there have been a few other reports since (#64367 here on Trac).

The culprit seems to be [61010] which solves #49687. Reverting that specific change (or downgrading to 6.8.3) has fixed the problem for every tester so far.

Because #49687 is a closed ticket on a completed milestone, this is being created to track this bug and eventually reference in any commits that are deemed necessary (if any at all).

The discussion about the problem begins at in the previous ticket with ticket:49687#comment:44. While it's worth reading through that conversation, here are some notes from the discussion so far:

• The issue mentioned as a possible problem in ticket:49687#23 seems like it could be causing these issues.
• Including -f when setting sendmail_from is bad practice, but is a widespread misunderstanding due to upstream documentation in PHP. An ​upstream ticket in php-src has been opened to address this.
• While -f is not supposed to be passed to php_admin_value[sendmail_path], using php_admin_value[sendmail_from] does not seem to work as expected for some in Linux environments using Postfix with Sendmail compatibility interface.

Upstream work

• Remove PHP manual page’s example with -f ​PHP#20648
• Report for PHPMailer on issue ​PHPMailer#3281
• Report for PHPMailer for -f issue? ​PHPMailer#3282
• PHPMailer patch to avoid double-adding -f ​PHPMailer#3283

[desrosj]

#64367 was marked as a duplicate.

[siliconforks]

The user on Reddit who reported this says that he is using DomainFactory for hosting:

​https://www.reddit.com/r/Wordpress/comments/1pdu68r/comment/nse0sur/

I found this discussion which talks about DomainFactory's sendmail_path configuration:

​https://forum.getkirby.com/t/error-could-not-instantiate-mail-function-with-kirby-email/13933/15

...the reason seems to be, that Domainfactory changed their general server configuration and now they are forcing a ReturnPath with the parameter -f within the sendmail_path in the php.ini (which I cannot access)...

That post is a few years old so I can't be certain it's still accurate today, but it does seem to suggest that DomainFactory likes putting the -f option in their sendmail_path value.

[SirLouen]

Following the latest comments by @jamieburchell @siliconforks and myself

https://core.trac.wordpress.org/ticket/49687#comment:52
https://core.trac.wordpress.org/ticket/49687#comment:58
https://core.trac.wordpress.org/ticket/49687#comment:59

With this config in both postfix and exim

Nothing is really changing as expected. Not failing either.

But finally with debian bookwork version of sendmail I got the error.

Postfix and Exim literally ignore the -f and everything. But sendmail is more "purist".

[SirLouen]

After some research I've gotten to a conclusion: The problem falls into Sendmail software

If sendmail_from is set at the same time as -f, Sendmail blows.

The logic of PHPMailer is not helping either. If the Sender is enabled, it will add a sendmail_from making Sendmail blow.

This behavior is not occurring in the rest of the mail servers. I have tested with Sendmail up to 8.17.1, not the latest 8.18.1.

According to their changelog, I'm not 100% sure
​https://ftp.sendmail.org/RELEASE_NOTES
If they have solved this here

VACATION: Add support for Return-Path header to set sender
		to match OpenBSD and NetBSD functionality.

Because, to be 100% sincere, I'm not sure what sendmail_from is literally doing. I will need to dig a bit on the PHP code before getting to a conclusion.

For now, the only solution for people under these circumstances, is to force set ->Sender to empty as @siliconforks commented

<?php
function use_no_sender( $phpmailer ) {
   $phpmailer->Sender = "";
}

add_action( 'phpmailer_init', 'use_no_sender' );

I will report back when I have more data. For now all I can say is that this is not an intrinsic problem of WP itself. Maybe some changes could happen in PHPMailer in the coming days.

[digitalblanket]

We host on Cloudways. We discovered yesterday that a client site with SMTP settings set through the phpmailer_init hook was now ignoring the $phpmailer->From address value we set, reverting to the address set within the email itself (Gravity Forms notofications in this case, which were still set to use the default admin_email From address). This causes the emails to be rejected by the client's Office365 HVE SMTP.

It sounds like we should be setting $phpmailer->From and $phpmailer->Sender now to overcome this? If so that's a massive change which is not at all explained in the WP 6.9 changelog!

[siliconforks]

Replying to digitalblanket:

It sounds like we should be setting $phpmailer->From and $phpmailer->Sender now to overcome this?

I think the best thing to do in your case would be to use the wp_mail_from filter. The intended behavior in WordPress 6.9 is that, if you use the wp_mail_from filter, then there should be no need to set the $phpmailer->From and $phpmailer->Sender values.

If you don't use the wp_mail_from filter - then yes, you're right, if you're setting $phpmailer->From manually then you should probably also be setting $phpmailer->Sender too.

If so that's a massive change which is not at all explained in the WP 6.9 changelog!

Well, ​https://make.wordpress.org/core/2025/11/18/more-reliable-email-in-wordpress-6-9/ does mention the change in behavior and suggest using the wp_mail_from filter. But obviously this change is causing issues for some people, so it's possible it might simply be reverted in a future bugfix release. But even if the change gets reverted, you may still want to set $phpmailer->Sender, to make sure your emails are getting sent with a sensible envelope sender value.

[studiomondiale]

Replying to siliconforks:

That post is a few years old so I can't be certain it's still accurate today, but it does seem to suggest that DomainFactory likes putting the -f option in their sendmail_path value.

I'm the reddit user who initially posted this and I can confirm that this is still what Domainfactory does, at least on our server, which is causing the issue.

[SirLouen]

I've found the solution to this problem. After reviewing Sendmail and PHP-src code, I was trying to understand how the Sender processing was being done, as it made no sense to me (plus the sendmail_from thing). I thought that the problem was that it was adding a sendmail_from but this was irrelevant. It's true that having a sendmail_from set up, will set it as the Sender envelop but not because of PHP default behaviour but a PHPMailer casuistry that is not relevant to this specific problem (and goes behind the default set of setFrom, this is why @jamieburchell could not see any changes when setting this sendmail_from in his server, as the From address takes precedence unless explicitly set in $phpmailer->Sender)

The thing is that all issues fall into PHPMailer: it was basically double-setting the -f parameter if the sendmail_path was set (as many had, and as it is a recommendation by the PHP docs).

I've already proposed a fix, and I will rush it to have it ready before 6.9.1 release.

For those having the issue and want a temporary fix, just set the Sender to empty as commented here https://core.trac.wordpress.org/ticket/64368#comment:4

Once updated to 6.9.1 this code can be removed.

cc @studiomondiale @digitalblanket

I'm adding close as a candidate of reported-upstream once this has been sorted out.

[siliconforks]

Replying to SirLouen:

I've found the solution to this problem.

I don't think it's certain that the double -f problem is the only issue here. This report sounds like it is the double -f problem, but this report sounds like it's a deliverability problem instead. This report might be either one - it's hard to tell.

[SirLouen]

Replying to siliconforks:

I don't think it's certain that the double -f problem is the only issue here. This report sounds like it is the double -f problem, but this report sounds like it's a deliverability problem instead. This report might be either one - it's hard to tell.

Sender affects to SMTP setups as it chooses the Sender address instead of From, if you are not u sing the hook. And for regular mail installations this is what it takes for the Sender related topics.

The first and the last are solved with this (the last is not 100% clear, but seems to be in line).

There is only one scenario I don't understand.

@studiomondiale told me that when he run $phpmailer-isSendMail() he got this error:

Could not execute: /usr/sbin/sendmail -finfo@domain.name -t -i

But it works for him having this sendmail_path

sendmail_path = /usr/sbin/sendmail -finfo@domain.name -t -i

My only theory is that his web host have the popen restricted because, regardless of the Sender change, if using $phpmailer->isSendmail should have worked as if it will technically execute the same (and is one of the recommended actions in PHPMailer).

So here are all the 3 possible scenarios.

1. With SMTP the problem is not using the hook
2. With regular mail (mailSend) the problem will be fixed soon
3. With mailSendmail there should not be any problems, in fact probably any user would have already set the $phpmailer-Sender if he was willing to use this method so this change should have not affected.

So with this in mind, the second one from @digitalblanket is because, if the Sender is set up, then it will set the From to the Sender if they are setting the $phpmailer->From instead of using the wp_mail_from hook, that will eventually set the From and the Sender at the same time with the same value. In his case, the patch coming to 6.9.1 will not solve anything.

Setting directly the $phpmailer->From or the $phpmailer->Sender is not the greatest practice (existing the hook), so it's a good opportunity to fix this and start using the wp_mail_from hook.

Since we are using PHPMailer as an abstraction layer instead of an adapter or a facade, for pretty much any change, there always could be leaks like these all over the place. In fact, the regression in 2017 would have been even worse, if DMARC were important back in the day. But DMARC/DKIM has started surging in the past few years so back in the day no one cared about these changes as deliverability issues were inexistent.

[siliconforks]

Replying to SirLouen:

Could not execute: /usr/sbin/sendmail -finfo@… -t -i

It looks like he is setting $phpmailer->Sendmail to a complete command line, with options? I think it's just supposed to be the path, /usr/sbin/sendmail, no options. PHPMailer is supposed to set all the options. (This is a bit different from the way sendmail_path works.)

sendmail_path = /usr/sbin/sendmail -finfo@… -t -i

I'm confused about that one - the -t and the -i are fine, but the -f is still not supposed to be there. Isn't that what caused his issue in the first place?

So with this in mind, the second one from @digitalblanket is because, if the Sender is set up, then it will set the From to the Sender if they are setting the $phpmailer->From instead of using the wp_mail_from hook, that will eventually set the From and the Sender at the same time with the same value. In his case, the patch coming to 6.9.1 will not solve anything.

Yes, in his case I think that it may require manual intervention by him to fix the problem.

[SirLouen]

Oops i was using github notation and the code looked terribly. I have fixed it.

Replying to siliconforks:

It looks like he is setting $phpmailer->Sendmail to a complete command line, with options?

No, I asked him to set the $phpmailer->isSendmail() method (not $phpmailer->Sendmail), just to check if his sendmail binary was working. But then I forgot that the popen PHP function could be restricted in his web host, so basically it was a useless test and I asked him to revert.

Theoretically, with isSendmail, none of these issues should have occurred (this is why it was recommended in the PHPMailer guidelines). But it has been a good opportunity to review that old ticket in PHPMailer you mentioned back in the day, that was mostly lost in oblivion without a real solution.

About the PHP-src ticket you opened, I also think that the sendmail_path example is misleading. The problem is that they clearly chose a weak name for the variable sendmail_path, so I believe they wanted to showcase that they were referring to sendmail_cmd instead, and they placed a full typical command to explain that you actually have to set in a full command, not only a path.

Yes, in his case I think that it may require manual intervention by him to fix the problem.

Setting the $From is a terrible idea. It's a public property for BC strictly, but the right way is to use SetFrom, which happens to be what the hook does. It's even better to set the From in the headers and pass the headers to wp_mail. From all the options, setting $From is the worst among all options. So basically, for me, that is more suitable for a support forum issue.

[siliconforks]

Replying to SirLouen:

It looks like he is setting $phpmailer->Sendmail to a complete command line, with options?

No, I asked him to set the $phpmailer->isSendmail() method (not $phpmailer->Sendmail), just to check if his sendmail binary was working. But then I forgot that the popen PHP function could be restricted in his web host, so basically it was a useless test and I asked him to revert.

If you just call $phpmailer->isSendmail(), and it fails for some reason, you should get an error message like this:

Could not execute: /usr/sbin/sendmail

But that's not what he got, right? You said he got the following:

Could not execute: /usr/sbin/sendmail -finfo@domain.name -t -i

I think the only way to get an error message like that is to do this:

<?php
$phpmailer->isSendmail();
$phpmailer->Sendmail = '/usr/sbin/sendmail -finfo@domain.name -t -i';

[SirLouen]

Replying to siliconforks:

I think the only way to get an error message like that is to do this:

Not necessarily. If you have a sendmail_path set, it will also pick it for this purpose.

​https://github.com/WordPress/wordpress-develop/blob/1bcada8b8d5705aa980b7a467f84cb352f846533/src/wp-includes/PHPMailer/PHPMailer.php#L993-L1003

[siliconforks]

Replying to SirLouen:

Not necessarily. If you have a sendmail_path set, it will also pick it for this purpose.

OK, but if you have a sendmail_path set with -f in it, then won't you eventually end up with a command line with two -f options? I don't see how that could possibly work.

It seems like the only way you could get it to work would be something like this:

<?php
$phpmailer->isSendmail();
$phpmailer->Sendmail = '/usr/sbin/sendmail';

[SirLouen]

Replying to siliconforks:

It seems like the only way you could get it to work would be something like this:

True. It can add up. Yet another potential bug.

[SirLouen]

I have also added a fix for the isSendmail version following a similar fashion.

[desrosj]

Just linking off to the related discussions upstream:

• ​PHPMailer issue 3281
• ​PHPMailer issue 3282
• ​PHPMailer PR 3283

Let me know if I've missed any external activity or context @SirLouen. Please just include links to these next time for easy following.

And thanks everyone for the great work looking into this one!

I'm adding close as a candidate of reported-upstream once this has been sorted out.

Fine to leave this keyword for now. This admittedly falls into a grey area. It is a legitimate bug within WordPress, but it seems likely that it will not require any changes to WordPress itself. But the ticket is valuable for planning and tracking purposes.

Sometimes tickets like this are marked resolved as fixed with the same commit that ends up attached to the library's update ticket. It can be helpful to have a ticket that specifically describes the bug that was fixed that is separate from the more general one. Let's continue to keep this open for now to ensure it's not missed by the contributors that eventually wrangle 6.9.1.

May be a good scenario to document in the handbook. I've added that to my list to think this through a bit.

[desrosj]

Also, I have ​gone through the Support Forums and I'm not seeing any additional support requests that seem related to this issue.

Has anyone else had observations contrary to that?

And last thought on the matter is that I think a dev note could be helpful so that there is a canonical resource that can be shared and referenced on the bug if there are new reports going forward. We should work/share this with the #hosting channel, and coordinate any needed efforts to the ​Advanced Administration Handbook as well.

[siliconforks]

Replying to desrosj:

Also, I have ​gone through the Support Forums and I'm not seeing any additional support requests that seem related to this issue.

Has anyone else had observations contrary to that?

There's another one I saw here (it might be the same multiple -f issue again):

​https://wordpress.org/support/topic/two-factor-stopped-working-since-wordpress-6-9/

[desrosj]

Of course, #64379 was just opened. Asked them to test and report back so it can be confirmed as a duplicate.

[Presskopp]

#64379 was marked as a duplicate.

[dmsnell]

loving the activity here. thank you especially for working so diligently to discover, debug, and report upstream issues.

supposing we narrow this down to those specific triggers, including misconfigured -f parameters, could we add in a check for that and adjust it? for example, if we detect the duplicate -f could we remove one before attempting to send the mail? or will the act of checking also trigger the failure?

[SirLouen]

Replying to dmsnell:

supposing we narrow this down to those specific triggers, including misconfigured -f parameters, could we add in a check for that and adjust it? for example, if we detect the duplicate -f could we remove one before attempting to send the mail? or will the act of checking also trigger the failure?

Yes, this is already sorted

[dmsnell]

Yes, this is already sorted

@SirLouen I looked and saw no commits in trunk and I see no linked work in this ticket. Can you link to where it was sorted?

[SirLouen]

Replying to dmsnell:

Yes, this is already sorted

@SirLouen I looked and saw no commits in trunk and I see no linked work in this ticket. Can you link to where it was sorted?

Here is the wip
https://core.trac.wordpress.org/ticket/64368#comment:18

[dmsnell]

thanks @SirLouen — I think I wasn’t clear in what I was writing. acknowledging that this is an upstream bug, we clearly introduced it with WordPress 6.9 — it’s an integration bug between our code and theirs.

that being said, I wanted to know if we can get something added to 6.9.1 to reliably detect this fault situation and resolve it while we wait for the long-tail of updates to any upstream fixes which might get merged.

[SirLouen]

Replying to dmsnell:

that being said, I wanted to know if we can get something added to 6.9.1 to reliably detect this fault situation and resolve it while we wait for the long-tail of updates to any upstream fixes which might get merged.

Do you know when 6.9.1 is planned for release?
I think this will be merged on time by then.

[jorbin]

that being said, I wanted to know if we can get something added to 6.9.1 to reliably detect this fault situation and resolve it while we wait for the long-tail of updates to any upstream fixes which might get merged.

I had the same thought, but looking through the linked upstream issues, I think the solution is going to be an update to phpmailer which will be added to core. I'm removing the close keyword since the commit that updates phpmailer be that can be used to close this ticket as @desrosj noted.

Since I can't be 100% sure that PHPMailer will update on time for 6.9.1 and I don't really know when 6.9.1 is schedule for release, I'm providing here a failover as @dmsnell suggested.

[SirLouen]

Replying to dmsnell:

that being said, I wanted to know if we can get something added to 6.9.1 to reliably detect this fault situation and resolve it while we wait for the long-tail of updates to any upstream fixes which might get merged.

Ok, I got you. I've added a failover in case this is not sorted on time. If this gets merged, I will make sure that it gets deleted on the same patch as the PHPMailer next update.

@jorbin I was thinking of creating a separate ticket that closes this one, because if it's a PHPMailer update, it will belong to the External Libraries component.

[zoe20]

Hello,

After updating my WooCommerce site to WordPress 6.9, all WooCommerce store-related emails stopped sending (such as New Order, Processing Order, and other transactional emails).

However, PayPal payment confirmation emails continue to arrive without any issues, so the problem seems isolated to WordPress/WooCommerce-triggered emails.

When I downgrade back to WordPress 6.8.3, everything works perfectly again.
No other configuration changes were needed — simply reverting WordPress itself restores full email functionality.

This confirms that the issue is directly related to the WordPress 6.9 update.

I also see this has been documented here:
https://core.trac.wordpress.org/ticket/64368

—which appears to match the behavior I'm experiencing.

Could you please clarify:

When is WordPress 6.9.1 expected to be released?

Is there any temporary workaround or patch available that resolves this issue while staying on WP 6.9?

Thank you — happy to provide additional details or logs if needed.

[westonruter]

#64385 was marked as a duplicate.

[siliconforks]

Replying to zoe20:

Is there any temporary workaround or patch available that resolves this issue while staying on WP 6.9?

This comment includes code for a workaround that should make WordPress 6.9 behave like previous versions when sending mail:

https://core.trac.wordpress.org/ticket/64367#comment:5

[jorbin]

@SirLouen A single commit can close multiple tickets. As this is the one people are being directed to, it shouldn't be closed until a fix has been committed.

@zoe20

When is WordPress 6.9.1 expected to be released?

6.9.1 is not scheduled as of yet.

[SirLouen]

Replying to @zoe20

Is there any temporary workaround or patch available that resolves this issue while staying on WP 6.9?

Yes, if you can add this code in a plugin or functions.php

add_action( 'phpmailer_init', static function ( $phpmailer ) {
        $phpmailer->Sender = '';
} );

Once 6.9.1 is released, you can remove it.

Replying to jorbin:

@SirLouen A single commit can close multiple tickets. As this is the one people are being directed to, it shouldn't be closed until a fix has been committed.

Yes, my intention was that: open a ticket in the External Libraries component for the PHPMailer upgrade and once fixed, close all. Anyway, if we cannot make it in time, we will need to push ​this patch for 6.9.1 as a temporary fix. This is why I was not planning to close this (just added the close tag). 👍

But personally I would prefer to keep PHPMailer in a separate ticket, because it will be including several more things than just this fix (also, it's more traceable when doing Google queries and that).

[zoe20]

Replying to SirLouen:

Replying to @zoe20

Is there any temporary workaround or patch available that resolves this issue while staying on WP 6.9?

Yes, if you can add this code in a plugin or functions.php

add_action( 'phpmailer_init', static function ( $phpmailer ) {
        $phpmailer->Sender = '';
} );

Once 6.9.1 is released, you can remove it.

Thank you for the suggestion! I’ve created a plugin called WP-Mail-Fix and installed it. I tested the New Order Email preview, and everything is processing as expected without any issues.

I appreciate your help in providing a temporary workaround. This solution works well, and I’ll keep an eye out for the release of WP 6.9.1 to remove the patch once it’s no longer needed.

Thanks again for your assistance!

[Monarobase]

Hello,

I understand that this ticket primarily addresses a PHP error related to setting the Envelope-From.

However, I would like to comment on the broader decision to always define an Envelope-From address, which is related but separate from the PHP error itself.

The concern here is not whether an Envelope-From should exist, but that RFC standards require the Envelope-From to be a valid mailbox. In many real-world hosting environments, wordpress@… does not exist and cannot be sure that it exists — particularly when email is hosted externally.

The rationale given for defining an Envelope-From by default is to help hosts that do not configure it correctly.

However, defining it with an invalid mailbox has the following consequences:

• It reduces deliverability for WordPress sites on hosts that already configure return paths correctly and prevents from receiving delivery errors
• It negatively impacts IP reputation on hosts that do not enforce RFC compliance.
• It blocks email entirely on hosts that do enforce RFC compliance and reject invalid Envelope-From addresses.

While I agree that leaving the Envelope-From undefined is not ideal for deliverability, it is still preferable to defining one that is invalid, as the latter actively breaks previously working and RFC-compliant setups.

Given this, I would kindly ask the team to reconsider defining the Envelope-From by default until a more complete solution is available — or at least make it opt-in — ideally with:

• a configurable setting for the Envelope-From address, and/or
• detection and admin warnings when the configured Envelope-From is likely invalid.

This would avoid breaking existing, correctly configured sites until WordPress can improve email handling by allowing users to define the "Envelope From" or the E-mail sender from WordPress's interface.

[amanandhishoe]

I think the problem is that WordPress should not be guessing how to format the Envelope. That is the responsibility of the sending email server.

When WordPress uses PHP mail() / sendmail:

• it does not know which MTA is behind it (Sendmail, Postfix, Exim, wrapper)
• it does not know host-level flags (-f, rewriting rules)
• it does not know how the envelope is ultimately formed
• it does not see the SMTP transaction

So WordPress cannot reason reliably about the envelope.

What WordPress could verify safely:

WordPress can perform DNS-based checks, because those are:

• read-only
• non-invasive
• independent of the host MTA
• already done elsewhere in core (updates, REST, loopback)

Specifically, WordPress could check:

SPF

• Does the site’s sending domain have an SPF record?
• Is it missing entirely?
• Is it +all / overly permissive?

DKIM

• Is there any DKIM selector published for the domain?
• (Not whether it’s correct—just whether DKIM exists at all.)

DMARC

• Is _dmarc.example.com present?
• Is it p=none, quarantine, or reject?

These checks do not require sending mail and do not interfere with delivery.

A Site Health notice like:

“Your domain does not publish SPF, DKIM, or DMARC records. Emails sent from this site are likely to be rejected or spam-foldered.”

is:

• accurate,
• understandable at a high level,
• actionable (with links),
• and far safer than silently changing mail behavior.

It reframes the problem correctly:

“Email reliability depends on DNS and a mail service.”

[SirLouen]

I'm going to answer @Monarobase and @amanandhishoe

The first trouble has been discussed extensively here #60420

a configurable setting for the Envelope-From address, and/or

I cannot fully disagree, but there is a controversial topic, behind the WP motto "decisions not options", that historically hinders a lot this type of things (specially because the plebs like us cannot take decisions this is reserved for the royalty)

So basically thinking on the idea of bringing the selection of a From or even a Sender email, to the frontend it's unlikely to happen in the short run without a massive workaround something like a Canonical plugin that hardly justifies it.

For now, what we have is two things: A hook injection via phpmailer_init and a from setter hook with wp_mail_from, that also sets the Sender to the same address as the From. So there are plenty of alternatives for server operators to fix this trouble. Furthermore, think that Mail was originally meant to be a pluggable (this is why most of the code related to wp_mail is in the file pluggable.php). This has many implications, and I can't speak on the future, but for now, the intention is not to put it anywhere in the frontend.

If you want to discuss more about this "frontending" topic to avoid going too away from the purpose of this topic, I suggest you to move the never-ending discussion into #60420. I'm not going to add anything else on this topic here.

The second trouble, about defaulting or not, has been discussed in #49687

Overall, default is the way to go. The problem here, is that we did not consider, that PHPMailer (the library behind WordPress to handle email) was not overriding the defaults if there was a value already set. This is fixed for now with the workaround provided here. By 6.9.1 no workaround will be needed, and any overrides like setting your own -f will do the cut.

But be aware, that if you configure your Exim/Postfix or whatever MTA Sender directly in the config, it will completely override whatever you set in WordPress/PHPMailer/or PHP level. In WordPress we are simply defaulting.

Mail component has not been historically the rockstar of WP, hence, some updates like the removal of the Sender, 7 years ago, has impacted poorly in how hostings designed their mailing systems (forcing them to set the Sender, instead of relying on defaults, which happens to be, not only simpler to deploy for automatic installations, but also more comfortable to maintain). The problem was that the ticket that triggered that removal was unrelated to DNS checks or the liking but more probably an MTA specific bug. The truth is that no debugging was done back in the day, and we could not trace with precision what happened, but Sender address defaulting should have never been removed, and we needed to fix this.

Having something default can never be intrinsically bad. It means that you can (and should) override it if it's not convenient for your setup. But having no Sender, by default means, killing the deliverability of anyone who has a basic setup by forcing 100% of the people to set up something or be unable to send at all.

Note that all testing was done with defaults in pretty much all MTA, and deliverability was 100%. The fact that the Sender envelope address must exist is not correct. The only validity check done here is on the domain of the Sender Address and this leads us to the first point, which I won't be discussing more in this ticket but in #49687

Conclusion

Everything goes down to a single point:

It reduces deliverability for WordPress sites on hosts that already configure return paths correctly and prevents from receiving delivery errors

it does not know host-level flags (-f, rewriting rules)

This is a mistake that will be solved in 6.9.1, don't worry. WordPress will keep defaulting the Sender address, but prioritizing what has already been set server/parser level.

[Monarobase]

Thank you for your answer.

You mention that you do not want to remove the default return path configured by web hosts.

However cPanel does not use the mail.force_extra_parameters in PHP to configure the default return path. It defines the default return path with the MTA (exim) when no return path is provided by PHP.

Using mail.force_extra_parameters is not the best solution to configure the default return path.

If WordPress defines a return path than the default return path is not used.

cPanel is the most used hosting panel, millions of WordPress websites use it.

Also please don't forget that shared web hosts who want to keep a good deliverabilty reputaton for their customers have to ensure that RFC standrads are respected so sending with an invalid return path will cause the e-mails sent by WordPress to be blocked by default.

[westonruter]

Replying to SirLouen:

This is fixed for now with the workaround provided here.

This workaround is also now available through the ​Hotfix plugin. This is written up in the just-published ​WordPress 6.9 Hotfixes post on Make/Core.

[dmsnell]

A Site Health notice like:

“Your domain does not publish SPF, DKIM, or DMARC records. Emails sent from this site are likely to be rejected or spam-foldered.”

For some time I’ve been chatting with folks about the idea of a new panel in wp-admin for “Web Standards” support and this is exactly one of the things I’d like to see added there. Unfortunately I’m unable to add it myself because I’m already fully occupied with other work.

In the meantime, plugins can fulfill that purpose, but I’d love to see some work to build a design for how this could serve everyone in Core: email settings, .well-known directory paths, RSS/Atom/ActivityPub integrations, web server settings, and more.

decision to always define an Envelope-From address

@Monarobase can you help me understand this, because it was my understanding that WordPress was already sending out an Envelope-From address before this change. Here are a couple of test emails sent while I was trying to confirm the patch.

• ​before the patch was applied
  MAIL FROM:<exouser@image-build-instance-ubuntu-24-1761002402583201839.js2local>
• ​after the patch was applied
  MAIL FROM:<wordpress@149.165.153.253>

This was for a vanilla installation of WordPress on a fresh Ubuntu node. Maybe you are saying that WordPress did not send anything through PHPMailer in the before case, and PHP’s mail() auto-set it? and somehow that would be some default that hosts configure in a way that it would be valid? For reference, the auto-generated value here (before the patch was applied) was the Linux user on the server running nginx @ the local hostname and domain name, something as far as I can tell is unavailable for discovery publicly.

Have to admit the details here confuse me, and I’m leaning on everyone else’s expertise. If you can help us understand how to see what you are seeing between the call to mail() and the MTAs I would personally value that.

Specifically, before this patch, my emails were sending with an invalid mailbox; yet, you are pointing out that this patch created the problem of sending from an invalid mailbox. That’s what I’m currently struggling to understand.

[siliconforks]

Replying to dmsnell:

Maybe you are saying that WordPress did not send anything through PHPMailer in the before case, and PHP’s mail() auto-set it? and somehow that would be some default that hosts configure in a way that it would be valid?

A real-world example might be helpful here...

This user mentioned using DreamHost for hosting; curious, I did some testing on a shared DreamHost server to see how they handle mail.

If you send email from a shared DreamHost server without specifying an envelope sender, it seems that your envelope sender ends up looking something like this:

user@pdx1-shared-a2-09.dreamhost.com

Is that address "valid"? I would say, not really (I'm pretty sure that it's not a real mailbox). However: it is valid in the sense that it does pass SPF.

Received-SPF: pass (... domain of
 pdx1-shared-a2-09.dreamhost.com designates 69.163.136.89 as permitted sender)
 client-ip=69.163.136.89; envelope-from=...pdx1-shared-a2-09.dreamhost.com;
 helo=pdx1-shared-relay-02.dreamhost.com;

So if you have a website example.com running WordPress 6.8 hosted on a DreamHost server, and you send email, your message will have an envelope sender value of something like user@pdx1-shared-a2-09.dreamhost.com, which is not exactly ideal, but it will pass SPF.

If you upgrade to WordPress 6.9 and send mail, your message will now have an envelope sender of wordpress@example.com. This seems like an improvement, but will it pass SPF? If you have an SPF record for example.com, and it designates your DreamHost server as an allowed sender, then you should be fine - it should still pass SPF as before. But if you don't have an SPF record for example.com, or it's incorrect somehow, then your message will no longer pass SPF. So it's possible that you may end up having problems getting email delivered (while it was working before in version 6.8).

[SirLouen]

Replying to Monarobase:

However cPanel does not use the mail.force_extra_parameters in PHP to configure the default return path. It defines the default return path with the MTA (exim) when no return path is provided by PHP.

Can you suggest me one sample host to test this? I stopped anything cPanel ages ago, and I would like to check this scenario.

Replying to siliconforks:

Is that address "valid"? I would say, not really (I'm pretty sure that it's not a real mailbox). However: it is valid in the sense that it does pass SPF.

From my experience, these hostings tend to add their SPF domains to your DNS records as they generally control the registrar.

Still most managed MTAs in webhosts take full control of the Sender address, this is why this Exim scenario looks curious to me.

[siliconforks]

Replying to SirLouen:

From my experience, these hostings tend to add their SPF domains to your DNS records as they generally control the registrar.

Yes, usually I would expect the hosting company to do this. In fact in the case of DreamHost it does add an SPF record by default:

​https://help.dreamhost.com/hc/en-us/articles/216107737-SPF-overview

So if you're running WordPress 6.9 on a DreamHost server and the default DreamHost-created SPF record is present, you should not have any problem.

However, there's still a lot of things that can potentially go wrong here:

1. The SPF record is just a DNS record like any other and is editable; so it's possible that the user may have changed the SPF record in the past and now it no longer works properly. This would not have been a problem in WordPress 6.8 because the SPF record was essentially unused; however, now in WordPress 6.9 the SPF record will be used, so any problems with it will surface.

2. It's possible that some people might be hosting their site on a DreamHost server but might have their DNS hosted somewhere else. In this case the SPF record might not even exist.

3. Another possibility is that there may be some plugin doing something bad, like using the admin email address as the "From" address. This is not a new issue - it has been discussed before in this ticket. However, WordPress 6.9 may have exacerbated the problem, because now if there is an invalid "From" address, it will also appear as the envelope sender as well. This seems like it might be the case in this report above.

[SirLouen]

The SPF record is just a DNS record like any other and is editable; so it's possible that the user may have changed the SPF record in the past and now it no longer works properly. This would not have been a problem in WordPress 6.8 because the SPF record was essentially unused; however, now in WordPress 6.9 the SPF record will be used, so any problems with it will surface.

I wonder where could they go ignoring SPF passing nowadays? It's like the bread and butter of deliverability. Anyone with "an unused SPF" might have had a perma-spam delivery WordPress system.

[siliconforks]

Replying to SirLouen:

I wonder where could they go ignoring SPF passing nowadays? It's like the bread and butter of deliverability. Anyone with "an unused SPF" might have had a perma-spam delivery WordPress system.

But because the SPF record for the WordPress site's domain wasn't actually used, it didn't matter if there was a bad SPF record (or if there was no SPF record at all). DreamHost was using some address like user@pdx1-shared-a2-09.dreamhost.com as the envelope sender, so it would use the SPF record for dreamhost.com, not the WordPress site's domain.

Of course, such a configuration would have other problems (e.g., it would be impossible to pass DMARC). But it may have been sort of working before, at least enough to pass SPF and get the mail delivered...

[SirLouen]

Just because I'm freaking devoted to this cause, I've purchased a cPanel $2 hosting for one month @ this random hosting I've found ethernetservers.com and I have associated one random domain I own.

It's remarkable how cPanel has evolved, it doesn't have that clunky interface anymore :)

It even has this menu:

That says which DNS you are missing and how to configure them.

Basically I configured the SPF, DKIM and DMARC with the values they provided me in my domains DNS and installed the default WordPress with that Softaculous thingy that is like very strightforward

After that I got into the WordPress admin, installed my trustworthy Health Check & Troubleshooting plugin, and went straight to its tools to test an email.

I have not added a single hook, the patching plugin that @westonruter recommends, or anything else. Just a clean, 6.9 WP installation and the Health Check plugin to enable the simplest mail sending feature.

Here is the result (I have not redacted anything on purpose, so you can clearly see the whole thing):

Delivered-To: sir.louen@gmail.com
Received: by 2002:a05:7011:21c8:b0:4f3:5ee4:767e with SMTP id sh8csp536952mdb;
        Fri, 12 Dec 2025 16:23:39 -0800 (PST)
X-Google-Smtp-Source: AGHT+IEIG4AByFl/c5X3jy/ETyF955HTVaXbD12abH8uG8JZpgocwJy3FA9N4QSdpzeZM2Z7Lb8C
X-Received: by 2002:a05:6a00:1d9f:b0:7e8:450c:61a1 with SMTP id d2e1a72fcca58-7f6696a3f77mr3496250b3a.56.1765585419060;
        Fri, 12 Dec 2025 16:23:39 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1765585419; cv=pass;
        d=google.com; s=arc-20240605;
        b=XaTsgwbi/XOF9KxwkkOT17NuHtm+HazMyhDNCM8b4k2u2cUPkcOgJ26lVg5RIs7gM9
         FTwffuzKqopLwUykWgUmtI72phDxIpHrfXE9OvnWV9MY6bEVOIUvbQyX+OQB7gEi7iSU
         SvT/XUZOMDU3XQ+J6pXJGZsHB8v1RkRVmHdVVxbK+TaHFXAFF1xNYasstuuURxIw3uzF
         zX3zckCeFLUIZ39DbBLB5qEigLp+UeChcM1JK+L+SkCJIvsUApGBXHq4lrHA8bX3tIB8
         uNOPz9jgAdYaHMgxAwTcJojM3PRM+XbW9h4EKNMq0fUo2KbstC2tQOKV11TsrxX7DbWE
         tyag==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:mime-version:message-id:from:date:subject
         :to:dkim-signature;
        bh=Wm2HU/yEKd8YMPMFnCMbH7gi0dnWYAjzo7s25HE4z84=;
        fh=LnWiZB+0qsThBew1oCwmWb63UJ40SUAv5hSa6DrXbks=;
        b=MUWVVUjMxeO4ysw6qogLsix1k3JOhijBPQkGbHCPReNpPxSJc3KUO3jfDZ0bHThiSs
         JLhI2TthrEDHVaRb0kTP9hMGzWt+kaMfn9huIX/V4SXbSsS745O5vEItEOCBOHKbwPXS
         ip8QPHJUKbnYm6A6Z+P9xBmTVaOrU18X29gtOPHN4HVfRbojyaQ4ns1r66IPkwXxbbkv
         fNf6XG2WXog1L1IkfHy7/4LlaG5cKmybEg1I/5Mh6hohyA5pmLAMymxJPWNC5qzO6Rn8
         L0T2EXc7QyUdS1XSu0aRArYcYS2Bitmsj9szuS7AMi7NtSueDN2pjvqwRC2bm38/gF/h
         Qbfg==;
        dara=google.com
ARC-Authentication-Results: i=2; mx.google.com;
       dkim=pass header.i=@f1onboard.com header.s=default header.b=j0wQ9LNh;
       arc=pass (i=1);
       spf=softfail (google.com: domain of transitioning wordpress@f1onboard.com does not designate 23.83.209.81 as permitted sender) smtp.mailfrom=wordpress@f1onboard.com
Return-Path: <wordpress@f1onboard.com>
Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net. [23.83.209.81])
        by mx.google.com with ESMTPS id d2e1a72fcca58-7f4c5b4c704si11702101b3a.219.2025.12.12.16.23.38
        for <sir.louen@gmail.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 12 Dec 2025 16:23:38 -0800 (PST)
Received-SPF: softfail (google.com: domain of transitioning wordpress@f1onboard.com does not designate 23.83.209.81 as permitted sender) client-ip=23.83.209.81;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@f1onboard.com header.s=default header.b=j0wQ9LNh;
       arc=pass (i=1);
       spf=softfail (google.com: domain of transitioning wordpress@f1onboard.com does not designate 23.83.209.81 as permitted sender) smtp.mailfrom=wordpress@f1onboard.com
X-Sender-Id: ethernetserversltd|x-authuser|fonboard@jazz.cleannameservers.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6A240780790 for <sir.louen@gmail.com>; Sat, 13 Dec 2025 00:23:38 +0000 (UTC)
Received: from jazz.cleannameservers.com (trex-green-1.trex.outbound.svc.cluster.local [100.103.178.42]) (Authenticated sender: ethernetserversltd) by relay.mailchannels.net (Postfix) with ESMTPA id BAA74780F6D for <sir.louen@gmail.com>; Sat, 13 Dec 2025 00:23:37 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1765585418; b=6KoO4XlMEhP0kzSRdfL21cPAka/xQ74yGnaZPnmHk7ia8rAvzzVYnCh7MTtrelolAgNLq5 F5FDpY9ZMXSez0J2ges5/4+HCQJSu8ZS21ecA6SzVUkxRryIAjFPhkYHLNIR5xHi4V5TCR vgVTuBgSE4mOc1duKR2ohrH+xUCGXd3OG8mBwqSz9Xd7X3XQA7HiepHc1s0COK5le0+MWx P2RJxX4k84rSbWN8eUetS+izrEq456AHBR8BE4g6pFpffZLJoTE3OfbkVZkrIJVZS4dh9t iQgGLZszX3vOc1rPyByBJdY7XEbVC0Vjrbe1MdbAoB6wgFKYVwaGmVBUMr4RbQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1765585418; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=Wm2HU/yEKd8YMPMFnCMbH7gi0dnWYAjzo7s25HE4z84=; b=L9WPNiZeKI/ROKSML5A00Ba0uXsC+zNbsTh6BwozYMA8OrrODun+9dC54ZM3avGFItKbbI XllTpFPQOkS1hjCA6tVJq4UEzBa5p0W7izEggfmDLJzX4f8KPbYxZ0umzpLL83k68e/48T IRW2yLq/ZJtIvEMKoIhuXqa9UHJIW0g1gx1WeBQTeSEtYMlBIQrlJ+H2knCdw0BuVdohRH oBELFpPciK1oknwD8F6QNb5ZzFAzLEzytCAbc86o2ZXULkROXS3PVepvpPgGvPcd5JSEwV g8a/tLfJUTmiGsu8sojekHIevSfDNlrrzNTfNDCIkIwhmG4o6rYKoLnYb6wriQ==
ARC-Authentication-Results: i=1; rspamd-6ccd5b4cc5-ggwd2; auth=pass smtp.auth=ethernetserversltd smtp.mailfrom=wordpress@f1onboard.com
X-Sender-Id: ethernetserversltd|x-authuser|fonboard@jazz.cleannameservers.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: ethernetserversltd|x-authuser|fonboard@jazz.cleannameservers.com
X-MailChannels-Auth-Id: ethernetserversltd
X-Absorbed-Reaction: 5db032cc14f1fe4c_1765585418272_1774664454
X-MC-Loop-Signature: 1765585418272:3610297220
X-MC-Ingress-Time: 1765585418272
Received: from jazz.cleannameservers.com (jazz.cleannameservers.com [57.128.96.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.178.42 (trex/7.1.3); Sat, 13 Dec 2025 00:23:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=f1onboard.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:From:Date:Subject:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Wm2HU/yEKd8YMPMFnCMbH7gi0dnWYAjzo7s25HE4z84=; b=j0wQ9LNhNUPdDm8Od7EXPTooRA SrRR4rpVbv6LXLos1eaLOzrhTWhd45syJbCR6+nPHZphuQ6LZR8aaKhme0zKDB6B8ZkMWulxJk+GR FiCKwyBZYMpFUdZz9tky//rNkVOGNX92TvCiOexc+5BQbaycKkRaJSG/29d6b6e6q/pJ8qGnVa9w3 cE42kRnBXqemnn12Vd0lcqMbuQfi7s14DGNDsGmFuv90M8UVaA+KYQ/+wvssjBJS49AIQ5gp88K7i zJTraVIWhwdR6Cfc/2QOtg3zKlTtZVqg+HTQqWa4HSX83b4BwaDl4BAAXqB8ck54R6pJA6G+szTRx ZtmkYxew==;
Received: from fonboard by jazz.cleannameservers.com with local (Exim 4.98.2) (envelope-from <wordpress@f1onboard.com>) id 1vUDQ7-000000009Yv-0ruG for sir.louen@gmail.com; Sat, 13 Dec 2025 00:23:35 +0000
To: sir.louen@gmail.com
Subject: Health Check – Test Message from https://f1onboard.com
Date: Sat, 13 Dec 2025 00:23:35 +0000
From: WordPress <wordpress@f1onboard.com>
Message-ID: <lUke7Mm5v1etKFKpMmGKGg0mvNblMEenzX37sdiLCfs@f1onboard.com>
X-Mailer: PHPMailer 7.0.0 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-AuthUser: fonboard@jazz.cleannameservers.com

Hi! This test message was sent by the Health Check plugin from My Blog (https://f1onboard.com) on December 13, 2025 at 12:23 am. Since you’re reading this, it obviously works.

Additional message from admin: this is a test

Maybe the most important part:

Received: from fonboard by jazz.cleannameservers.com with local (Exim 4.98.2) (envelope-from <wordpress@f1onboard.com>) id 1vUDQ7-000000009Yv-0ruG for sir.louen@gmail.com; Sat, 13 Dec 2025 00:23:35 +0000

Yes, the envelope-from is wordpress@f1onboard.com which I have not created the inbox. I have not created any email inbox at all for that domain. I have not even added the MX records, just in case you want to inspect the DNS zone, I've just added the DMARC, the DKIM and the SPF as the "Email Deliverability" menu suggests.

Conclusion: It's pretty straightforward. This is the defaults for 99.99% of web hosts, as I've chosen the most cheapest and random host I've found out there for the test. I understand that some hosts forcefully configured the -f because we were missing it and this brought some problems. But this has been fixed, so I'm confident at this point that we are good to move on at this point.

[Monarobase]

Replying to dmsnell:

decision to always define an Envelope-From address

@Monarobase can you help me understand this, because it was my understanding that WordPress was already sending out an Envelope-From address before this change. Here are a couple of test emails sent while I was trying to confirm the patch.

• ​before the patch was applied
  MAIL FROM:<exouser@image-build-instance-ubuntu-24-1761002402583201839.js2local>
• ​after the patch was applied
  MAIL FROM:<wordpress@149.165.153.253>

This was for a vanilla installation of WordPress on a fresh Ubuntu node. Maybe you are saying that WordPress did not send anything through PHPMailer in the before case, and PHP’s mail() auto-set it? and somehow that would be some default that hosts configure in a way that it would be valid? For reference, the auto-generated value here (before the patch was applied) was the Linux user on the server running nginx @ the local hostname and domain name, something as far as I can tell is unavailable for discovery publicly.

Have to admit the details here confuse me, and I’m leaning on everyone else’s expertise. If you can help us understand how to see what you are seeing between the call to mail() and the MTAs I would personally value that.

Specifically, before this patch, my emails were sending with an invalid mailbox; yet, you are pointing out that this patch created the problem of sending from an invalid mailbox. That’s what I’m currently struggling to understand.

Hello,

Previous versions of WordPress called PHP’s mail() without the 5th parameter ($additional_params). i.e. it did not pass an explicit -f value:

mail($to, $subject, $message, $headers);

Starting with WordPress version 6.9 now explicitly sets the envelope sender by passing -f via the 5th parameter:

mail($to, $subject, $message, $headers, '-f wordpress@domain.tld');

On cPanel/Exim specifically, when mail() is called without -f, Exim is typically configured to use:

<system_user@server.hostname>

That may look odd, but it is a host-controlled default that the host can ensure is a valid mailbox. Hosts rely on this because it provides a predictable, RFC-valid envelope sender even when applications don’t specify one.

Once WordPress forces -f wordpress@…, that host-safe default is bypassed and replaced with a value that, in many real-world installs, is not a valid mailbox (and cannot be assumed to exist).

Why RFC validity matters in practice

In your tests, email delivery succeeded because most receiving systems do not reject a single message solely because the envelope sender is invalid. Modern anti-spam systems typically assign a score or probability to each message based on many signals, one of which is RFC compliance.

An invalid envelope sender usually does not cause an immediate rejection on its own; instead, it increases the message’s spam score. If the overall score remains below the rejection threshold, the message is still accepted — which explains why isolated test messages appear to work.

The problem emerges at scale. When large volumes of mail are sent with an invalid envelope sender, the accumulated scoring impact causes more messages to cross rejection or spam thresholds. At that point, messages are increasingly blocked or filtered, and the sending IP’s reputation degrades.

This is why many hosts enforce RFC compliance on outbound mail: allowing RFC-invalid messages to leave the platform reliably leads to worse deliverability over time.

[SirLouen]

Ok, @Monarobase I see where you are coming. It's not entirely true that SPF should be aligned with Sender Address. You only have to specify which hostname is authorized for sending in your behalf.

But Sender address must be aligned with From address.

And by default, here you have a problem if you default in your hosting default Sender address.

So in my example, simply by changing the SPF from v=spf1 +mx +a +ip4:57.128.96.9 ~all
to v=spf1 +mx +a +ip4:57.128.96.9 include:relay.mailchannels.net ~all

You can ensure, that despite of having a return path set to wordpress@f1onboard.com, your relay hostname is respected.

Specially because my FROM (by default) is wordpress@f1onboard.com

With the Sender address, being also the same, we align both FROM and Sender, as DMARC RFC requires.
​https://datatracker.ietf.org/doc/html/rfc7489 (3.1.2)

In relaxed mode, the [SPF]-authenticated domain and RFC5322.From domain must have the same Organizational Domain. In strict mode, only an exact DNS domain match is considered to produce Identifier Alignment.

So if you are planning to leave the default server Sender like user@pdx1-shared-a2-09.dreamhost.com

You should never be able to align it with your From: address for DMARC passing according to RFC.

Also, what is the point of having such default Return-Path?. It's a wrong practice. It is like sending a letter to your friend, and setting your postal office as the Return-Path. We have to get back to basics. I know that wrong setups have been working for ages, and as I have demonstrated, you can get your email passing with just DKIM, but as you have said:

In your tests, email delivery succeeded because most receiving systems do not reject a single message solely because the envelope sender is invalid. Modern anti-spam systems typically assign a score or probability to each message based on many signals, one of which is RFC compliance.

To ensure full deliverability, the triad must be passing (SPF+DKIM+DMARC), and in this scenario you are proposing DMARC is going to be failing due to the alignment problems. This is why PHPMailer had setFrom aligning From and Sender by default.

Now adding the relay hostname and a little mistake in the DMARC that I forgot to add the _dmarc record hostname this is the result:

Delivered-To: sir.louen@gmail.com
Received: by 2002:a05:7011:21c8:b0:4f3:5ee4:767e with SMTP id sh8csp766115mdb;
        Sat, 13 Dec 2025 04:22:33 -0800 (PST)
X-Google-Smtp-Source: AGHT+IHG0s4n/YjzLAMpY+/gw1JFU1JO5AAp5LMGDap1uamHl8sEJ2g5CsdE63w3ssJif5roCfwB
X-Received: by 2002:a05:6a00:8c11:b0:7f1:471b:64e5 with SMTP id d2e1a72fcca58-7f671b52e94mr4212163b3a.58.1765628553289;
        Sat, 13 Dec 2025 04:22:33 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1765628553; cv=pass;
        d=google.com; s=arc-20240605;
        b=jQfGfJdJuHrEwhMfZq3rUS6kgraem99sJXLZ9Do3JEMJ9DP9kxMi2J1tCy6Ri7Un8Y
         kb/QYXUZZwqvSPwh449mhcmN1SnZOSEHD2QCoxzxqGaBy0OCgps3HG4MdYBF/rxhrkkO
         xjKukQYmaBAcdA/7wGVnZeT+BMPXA2XpcvCO9G9zFCzgoy/iJPN3Dg8z/0PqqLjO41zb
         Jjbg2H3nBGyIzZRDx2aeXG6aHhc6JxPOaOjoKsW8kWXSqSF5CSjJnH1hfRnKpGRxv7zu
         BBAgLHv8DnPMhNj2zhtMta97I19a60qpNkjxS8CKHVTDWoQEf6F9Av9bwnyZY6E6PKux
         +ZBw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:mime-version:message-id:from:date:subject
         :to:dkim-signature;
        bh=3CfPD7UR79b0pwo73P1gLA2UppZDA98AF2Gz5r6D8oI=;
        fh=LnWiZB+0qsThBew1oCwmWb63UJ40SUAv5hSa6DrXbks=;
        b=P++igZ6wmU/7apC0D3Gk+N4FA5/KyXD+kpKzbBwBNoX6Rp3yb1jzLaZogzyu0lAmlt
         aGj/vDr06j5eWjN+drEsOCEjaOcPxxV+74fumGIOqmFugMaolsJB7rhYWa5hJFAW0xmR
         WH+4cXV54oayCjwcFOnrr6C0mBlyrHuFByxWZQsZv1tFE9RkUHBdyswcIbnk7dMoB9ls
         3XWoDl1fvkcXIu5ffOUi2Tz9Bh5t+NVZY57WFbFh/XqKc95RH2p5ALO44ffQCnKOAnxg
         IB4JcRfe4heUSMyc0BWgAJ+EuZAb9ZkSV+QKAXD3GMJJmhnWxkpj7Fw05J11DSrV4jW4
         9PuQ==;
        dara=google.com
ARC-Authentication-Results: i=2; mx.google.com;
       dkim=pass header.i=@f1onboard.com header.s=default header.b=DTMipAkI;
       arc=pass (i=1);
       spf=pass (google.com: domain of wordpress@f1onboard.com designates 23.83.209.27 as permitted sender) smtp.mailfrom=wordpress@f1onboard.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=f1onboard.com
Return-Path: <wordpress@f1onboard.com>
Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net. [23.83.209.27])
        by mx.google.com with ESMTPS id d2e1a72fcca58-7f4c66f352csi15626766b3a.291.2025.12.13.04.22.32
        for <sir.louen@gmail.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 13 Dec 2025 04:22:33 -0800 (PST)
Received-SPF: pass (google.com: domain of wordpress@f1onboard.com designates 23.83.209.27 as permitted sender) client-ip=23.83.209.27;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@f1onboard.com header.s=default header.b=DTMipAkI;
       arc=pass (i=1);
       spf=pass (google.com: domain of wordpress@f1onboard.com designates 23.83.209.27 as permitted sender) smtp.mailfrom=wordpress@f1onboard.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=f1onboard.com
X-Sender-Id: ethernetserversltd|x-authuser|fonboard@jazz.cleannameservers.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7F898920DD8 for <sir.louen@gmail.com>; Sat, 13 Dec 2025 12:22:32 +0000 (UTC)
Received: from jazz.cleannameservers.com (100-107-170-83.trex-nlb.outbound.svc.cluster.local [100.107.170.83]) (Authenticated sender: ethernetserversltd) by relay.mailchannels.net (Postfix) with ESMTPA id D221F920C49 for <sir.louen@gmail.com>; Sat, 13 Dec 2025 12:22:31 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1765628552; b=fj2ubN0neh22WFKz9i1IFMqsRUK4IjdxtIYrgOBHBNcjGasJyM5sbEMnAo+TxJd2PsReui 3y1gg0GKlXEsMtIse7yCCvwfKDLjGpdGntQvAA0wgnCJR0IUbI2zBDmsb8logzx9pKCvqV 7ZJdyEkpVTnfSz3ILpB1k1HEzXMkCtkBXryPY/stZek9CUs2PXY2JuB6x39i9qFiitSp4P kHvXTLRaty+ECmBG+6fpdxDBTLaGFEksqkQvHSVjaRlUKWc8UE0aT64w95Dm1k377MKD9n bYvHH3w6R3niS7S0HkCUqCVSf28OaSVNTXE3Y77t8yq8iRack/SxWTGCA/5LIQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1765628552; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:mime-version:mime-version:content-type:content-type:
	 content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=3CfPD7UR79b0pwo73P1gLA2UppZDA98AF2Gz5r6D8oI=; b=EV2IZyF61azsfBgSRUWPPvtjYyY8k/cbGH9VleKk8zwOCPcMppVJiOvyc465Rsza1lvucd +Vi3ThBUW231eC0bwJw6msG0MVsljOjgXE4sK4Ri0fn7ykc9l0Ms2+J8fSZVs2TonJ2pqO CvdRwO11wSACWDRbpFVFm8/g/n1cOuVQtxrQJXAumDWohst6phxocEJuIqHlqj0WjCBd1C fxNtSWhm5f/3otOuA67TI4XJ3Qo7CjOZJMYx8AUChXd0QfC2AU5LvecR2Q7y5RHSE8O/Cb oX+/ckH0rFbU1xP/zMcOJG89wEVfT92isV3hw1DDEQv9SyXuR6i92YM+BxfMCw==
ARC-Authentication-Results: i=1; rspamd-6ccd5b4cc5-twfbm; auth=pass smtp.auth=ethernetserversltd smtp.mailfrom=wordpress@f1onboard.com
X-Sender-Id: ethernetserversltd|x-authuser|fonboard@jazz.cleannameservers.com
X-MC-Relay: Neutral
X-MailChannels-SenderId: ethernetserversltd|x-authuser|fonboard@jazz.cleannameservers.com
X-MailChannels-Auth-Id: ethernetserversltd
X-Eyes-Army: 5a03e00a6601bedc_1765628552349_3873168343
X-MC-Loop-Signature: 1765628552349:1819422308
X-MC-Ingress-Time: 1765628552349
Received: from jazz.cleannameservers.com (jazz.cleannameservers.com [57.128.96.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.107.170.83 (trex/7.1.3); Sat, 13 Dec 2025 12:22:32 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=f1onboard.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:From:Date:Subject:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=3CfPD7UR79b0pwo73P1gLA2UppZDA98AF2Gz5r6D8oI=; b=DTMipAkI/hZNHj4DyF57nUxmMw YGZcGonGmOtusk8sOHaCzwEmWDgTgI1kS3YVpOsHmuWDvEtoHn0eSjbL5m9ifpFc5Bux/jOdh3qB7 1kq1BFnQcwa1abzkfpzSbsL6hlOX7CkStVQW8jJz7Eyy0auTrNPaUfGlYYoilfg002CM718F6EN0S 96g0pUokXJObzGI+MF7vEvp0Yia3joHU3RqJjamr3WcL2RgvixNPH/MTG0s9s/IqucREDXwMrn/gm /KCHSm5eMme0r/qfkDKQy5GoyvSBDINWhWmXoe7h0x3AdglG5vvO7q76QhFLotLqEPP5W4B5cq5Hx c4du+yfg==;
Received: from fonboard by jazz.cleannameservers.com with local (Exim 4.98.2) (envelope-from <wordpress@f1onboard.com>) id 1vUOdl-00000003srP-41sV for sir.louen@gmail.com; Sat, 13 Dec 2025 12:22:30 +0000
To: sir.louen@gmail.com
Subject: Health Check – Test Message from https://f1onboard.com
Date: Sat, 13 Dec 2025 12:22:25 +0000
From: WordPress <wordpress@f1onboard.com>
Message-ID: <c23gaMCKfqyCrMK7ATkh055FqSKml3rbzJUJMZ3M@f1onboard.com>
X-Mailer: PHPMailer 7.0.0 (https://github.com/PHPMailer/PHPMailer)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-AuthUser: fonboard@jazz.cleannameservers.com

Hi! This test message was sent by the Health Check plugin from My Blog (https://f1onboard.com) on December 13, 2025 at 12:22 pm. Since you’re reading this, it obviously works.

Additional message from admin: This is a test email

All 3 SPF, DKIM and DMARC passing, with Sender and From aligned and SPF pointing to the relay, for the rest, all defaults, both in the CPANEL hosting, no inboxes and no modifications in the WordPress side either, all default also (just Health Check, to easily send the email)

This is the minimum SPF/DMARC/DKIM configuration anyone should expect for deliverability. Having in 2025 anything less than this is, as you said, risking deliverability. And SPF/Sender is not exclusively the culprit.

[Monarobase]

Thanks for answer. Just to be clear, I wasn’t referring to SPF here — I agree it isn’t the concern for this change.

The issue I’m raising is specifically about recipient-side anti-spam behaviour and RFC compliance. Many anti-spam systems evaluate whether the envelope sender corresponds to a valid mailbox and factor invalid return paths into their scoring or reputation calculations over time (for example when bounces cannot be delivered because the mailbox does not exist).

Web hosts that block outgoing e-mail that has an invalid return path do so to protect their IP reputation.

[siliconforks]

Replying to Monarobase:

Thanks for answer. Just to be clear, I wasn’t referring to SPF here — I agree it isn’t the concern for this change.

Huh? Isn't SPF always a concern? (Did you read my comment above?)

[SirLouen]

Replying to siliconforks:

Huh? Isn't SPF always a concern? (Did you read my comment above?)

Maybe those are valid inboxes, created by the webhost?

But still, I can't really understand why anyone would prefer to sacrifice DMARC passing in exchange of return-path address validity.

The issue I’m raising is specifically about recipient-side anti-spam behaviour and RFC compliance. Many anti-spam systems evaluate whether the envelope sender corresponds to a valid mailbox and factor invalid return paths into their scoring or reputation calculations over time (for example when bounces cannot be delivered because the mailbox does not exist).

Obviously every element matters, and there was also a proposal to do quick validity checks for inboxes in Health Check in #62129

But still, if we are seriously concerned about deliverability at mass scale, owning the domain and setting it up correctly (not only the SPF, but DKIM and FQDN alignment) are like the bare basics. Following the 80% rule, satisfying most of the population, having a From = Sender is the most popular option (this was the purpose of returning this feature despite of the minor troubles we have found with PHPMailer).

For the rest, there are many tweaking options that, as I commented in #60420, anyone with expertise willing to go the extra mile to finetune the thing should know. We should not sacrifice the majority in exchange of some special needs. As I have demonstrated here, in a cheap, classic webhost, maximum deliverability is truly simple (and personally I rarely work with regular webhosts, but I'm conscious that the majority does).

[Monarobase]

The reason we consider SPF not to be the concern here is that SPF configuration has always been part of email delivery, and most hosting providers already handle this today. When domains are hosted with us, SPF is preconfigured; when they are not, customers are generally advised to copy or adapt existing DNS records. In other words, this change doesn’t materially alter the SPF situation.

From the perspective of an individual website, having From = Sender alignment can indeed improve short-term deliverability, and I agree with that. However, from a hosting provider’s perspective, there is a different — and equally important — consideration: IP reputation.

Allowing emails to be sent with invalid, non-RFC-compliant return paths leads to poorer hygiene at the IP level. Recipient anti-spam systems factor this in over time, especially when bounces cannot be delivered because the return-path mailbox does not exist. While this may not cause immediate failures, it does negatively affect the reputation of the sending IP.

So while I agree this change may improve deliverability in the short term for many individual sites, in the medium to long term it risks reducing overall deliverability by degrading hosting providers’ IP reputation.

Today, the only way to achieve maximum deliverability without that trade-off is for customers to either:

• ensure the wordpress@… mailbox actually exists, or
• explicitly configure the sender via a plugin or custom code.

Our concern is simply that the current default optimises for short-term gains while introducing longer-term risks at the infrastructure level. We hope those longer-term implications can be taken into account, not just the immediate improvements.

[siliconforks]

Replying to Monarobase:

The reason we consider SPF not to be the concern here is that SPF configuration has always been part of email delivery, and most hosting providers already handle this today. When domains are hosted with us, SPF is preconfigured; when they are not, customers are generally advised to copy or adapt existing DNS records. In other words, this change doesn’t materially alter the SPF situation.

My point is that this change can break SPF on servers where this was working before. I'm still not entirely sure if you're disputing that, or if you simply don't consider that a major problem because it's something that can easily be fixed.

[Monarobase]

Replying to siliconforks:

Replying to Monarobase:

The reason we consider SPF not to be the concern here is that SPF configuration has always been part of email delivery, and most hosting providers already handle this today. When domains are hosted with us, SPF is preconfigured; when they are not, customers are generally advised to copy or adapt existing DNS records. In other words, this change doesn’t materially alter the SPF situation.

My point is that this change can break SPF on servers where this was working before. I'm still not entirely sure if you're disputing that, or if you simply don't consider that a major problem because it's something that can easily be fixed.

I said SPF was not the issue for us because for a web host it's easy to fix for domains that use their DNS servers and also easy to check and warn customers who don't use their DNS servers.

What's not easy for a web host is to fix the issue added by WordPress 6.9 without adding a plugin to customers websites which would require their consent and would cause a lot of support requests.

We have considered the following solutions to the issue added to WordPress 6.9 :

• Rewriting all wordpress@… to system_user@… : We cannot do this because we can't be sure that a customer does not use wordpress@…
• Installing a mu plugin automaticaly on all WordPress websites to fix this issue : We refuse to install plugins without our customer's consent so this is complicated to do.
• Allow our customers to send e-mails with invalid return paths : We don't want to risk our IP's from having a poor reputation due to poor hygiene of the e-mails that our IP's send.
• Contacting all of our customers and telling them to install and configure a plugin : This will cause a huge amount of support and some customers might believe it's not an issue with WordPress and think it's an issue with our servers.

[SirLouen]

Replying to Monarobase:

What's not easy for a web host is to fix the issue added by WordPress 6.9 without adding a plugin to customers websites which would require their consent and would cause a lot of support requests.

For me, it is particularly strange that you were so relaxed before 6.9 about the fact that From and Sender were not aligned, but now you are so obsessed about the validity of the return-path inbox. Spam Scoring wise DMARC failing is way higher than this.

Rewriting all wordpress@… to system_user@… : We cannot do this because we can't be sure that a customer does not use wordpress@…

Still if you feel that is so important, can't you simply check if wordpress local is already created in your mail system and simply create aliases with wordpress@ for those that don't have it? Or if this is too complicated for you, why not simply add a catchall?

I think this is going far beyond the scope of this ticket anyway.

[Monarobase]

We agree that DMARC alignment is a very important deliverability signal, and this was indeed a limitation of the pre-6.9 behavior.

DMARC failure

• Message is usually still delivered
• Worst case: lands in spam or quarantine
• No protocol violation

Invalid return-path

• Message can be rejected outright
• Bounce handling is impossible
• Violates RFC expectations for a bounceable sender

A DMARC failure degrades deliverability of individual e-mails while an invalid return-paths break mail flow and reduce IP reputation when this happens. IP reptation affects all users and not only WordPress users.

We are not just thinking from a WordPress perspective, we are thinking for all of our customers. Should non WordPress users be impacted because the people who decide about allowing a new field in the admin interface don't consider fixing e-mail deliverability issues is important to them ?

[SirLouen]

Replying to Monarobase:

We are not just thinking from a WordPress perspective, we are thinking for all of our customers. Should non WordPress users be impacted because the people who decide about allowing a new field in the admin interface don't consider fixing e-mail deliverability issues is important to them ?

But this goes beyond this change. Also I need to get a better picture of that specific statements regarding "invalid return-path". Because its not invalid but not existing. Can you provide us with more literature regarding this issue? FWIW, this was a 2000s issue that pretty much almost no one cares anymore unless I've missing something more updated (and even though, there are plenty of easy fixes, like the ones I commented you, including the catch-all option).

For example, if you send an email, to an invalid address and the remote server bounces back to the Return-Path which happens also to be invalid, being "tagged" as invalid "Return-Path" not necessarily increases any spam score nor the IP reputation as you say. Which is the exact system that triggers this?

Definitely not SpamAssassin or derivatives.

What massively destroys the IP reputation is to mass send emails to nonexistent inboxes.

[amanandhishoe]

Replying to SirLouen:

It seems like you are conflating the Reply-To header with the SMTP envelope Return-Path. The issue is that WordPress may attempt to influence the envelope Return-Path, but that address must be deliverable, since it is where mail servers send bounce notifications.

They are different layers and serve different purposes:

• Reply-To
• An RFC 5322 message header
• Controls where a human’s email client sends replies
• Has no role in bounces, SPF, or IP reputation
• Envelope Return-Path
• Derived from the SMTP envelope MAIL FROM
• Used exclusively for bounces and delivery failures
• Evaluated by MTAs for SPF alignment, bounce handling, and reputation

The comment you quoted repeatedly slides between these two, as if they were interchangeable. They are not

Modern email systems do not care if the Reply-To address is invalid. They do care if the Return-Path address is not deliverable. They also care a great deal whether the domain exists, whether SPF aligns, and whether bounces can be accepted somewhere.

The claim that this is a “2000s issue” is outdated. Today, envelope handling affects SPF alignment, DMARC evaluation, backscatter handling, and reputation scoring at major providers. Whether SpamAssassin is involved is irrelevant; it is no longer the primary gatekeeper. Reputation systems at Gmail, Outlook, Yahoo, and others operate independently.

It is not just a matter of “there are plenty of easy fixes, like … catch-all.” Those are host-level decisions, not application-level ones. WordPress does not know the MTA, the rewriting rules, the SPF topology, or whether a catch-all exists.

You are correct when you say, “What massively destroys the IP reputation is to mass send emails to nonexistent inboxes.” But it is unrelated to the envelope discussion and does not justify WordPress intervening at the SMTP layer.

[Monarobase]

RFC 5321 defines the SMTP envelope reverse-path (MAIL FROM / Return-Path) as “the sender mailbox” and states that the Return-Path’s primary purpose is to designate the address for non-delivery / failure reports.

RFC 5322 defines a mailbox as an entity that receives mail (“A mailbox receives mail.”). 
Consequently, if the return-path value is undeliverable because it does not exist, it is not a mailbox in the RFC 5322 sense, and it defeats the RFC 5321 purpose of Return-Path handling. For non-DSN messages, RFC 5321 further states they SHOULD be sent with a valid, non-null reverse-path. 

RFC5321 :
​https://datatracker.ietf.org/doc/html/rfc5321

RFCF322 :
​https://datatracker.ietf.org/doc/html/rfc5322

[siliconforks]

Replying to SirLouen:

But this goes beyond this change. Also I need to get a better picture of that specific statements regarding "invalid return-path". Because its not invalid but not existing. Can you provide us with more literature regarding this issue?

I think the best discussion of this is probably in RFC 5321 Section 6.2:

​https://datatracker.ietf.org/doc/html/rfc5321#section-6.2

[dmsnell]

All, thank you for continuing to keep up the pace of investigation and working to resolve ambiguity, disagreement, and mutual understanding. This conversation has, unfortunately, veered far from the purpose of this ticket and itself is much broader in scope. Therefore I have created #64420 to discuss how WordPress and hosts should broadly interact with the Envelope Return-Path.

For this specific ticket I ask the following:

• Let’s limit continued discussion exclusively to the Could not instantiate mail function issue which arose in 6.9 and which has multiple existing workarounds available today as well as fixes in the pipeline for 6.9.1.

For #64420 I have further asks:

• Let’s be gracious with each other and trust that we’re all competent folks who want to see reliable email deliverability, that we have all performed due diligence, and that we might all see different aspects of the same root problem. We see different parts of the problem and have different ideas on how to resolve them, but email systems are complicated and hit different cogs of the system in different ways.
• The facts highlighted here have been extremely helpful and build shared understanding of how best to move forward. Let’s continue to share how different aspects of sending and delivering emails his our own systems. Because this is such a complicated field and so swamped by outdated or uninformed content around the web (sadly, a web search on how best to send email is not likely to return accurate, updated, and trustworthy information), let’s focus as much as we can on facts we have measured. It’s very likely that one large system is doing things differently than others.
• In many of the comments here’s it’s the side-details that have helped me most to understand the needs. Let’s continue to share the context and assumptions we bring into the discussion. I think there are likely a few different overlapping issues at the root of this conversation, including things from the perspective of the sender, of the host, of WordPress, of the recipients, of middle-man MTAs, of email clients, and more.

[SirLouen]

Replying to siliconforks:

I think the best discussion of this is probably in RFC 5321 Section 6.2:

​https://datatracker.ietf.org/doc/html/rfc5321#section-6.2

There is one single key in that section that explains the whole problem of this

To stretch the principle of delivery if possible even further, it may be a rational policy to not deliver mail that has an invalid return address, although the history of the network is that users are typically better served by delivering any message that can be delivered. Reliably determining that a return address is invalid can be a difficult and time-consuming process, especially if the putative sending system is not directly accessible or does not fully and accurately support VRFY and, even if a "drop messages with invalid return addresses" policy is adopted, it SHOULD be applied only when there is near-certainty that the return addresses are, in fact, invalid.

RFC acknowledges that determining the validity of a return address is, overall, a bad idea and should be applied in very specific scenarios. It is not even a requirement but a suggestion. SPF alignment for DMARC is not a suggestion.

Replying to amanandhishoe:

It seems like you are conflating the Reply-To header with the SMTP envelope Return-Path. The issue is that WordPress may attempt to influence the envelope Return-Path, but that address must be deliverable, since it is where mail servers send bounce notifications.

I was explicitly talking about the Return-Path, not the Reply-To. What made you infer that? If at some point it made that impression, I can confirm that I was talking exclusively about the Return Path

Reputation systems at Gmail, Outlook, Yahoo, and others operate independently.

This reminds me all the requests regarding Google/Bing Seach engine for SEO purposes. 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". As I said, Return-Path validity is not a golden rule and as it has been commented above, it seems more of a suggestion. But SPF Alignment IS a golden rule hands down, and it's explicitely stated in the RFC.

The worst part, is that system administrators can "somewhat easily" handle Return-Path deliverability, knowingly that at least for now, wordpress@hostname is the default address in WordPress (if they are providing WordPress in their service list). But what I call "exemplary users" are completely f *p if Sender address is not present, having to deal with very complex hooks and knowledge about PHPMailer to fix their problems. 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.

Please refer to this post, to continue the conversation if needed.

[dmsnell]

#64477 was marked as a duplicate.

[abdullah2019]

Replying to SirLouen:

Replying to @zoe20

Is there any temporary workaround or patch available that resolves this issue while staying on WP 6.9?

Yes, if you can add this code in a plugin or functions.php

add_action( 'phpmailer_init', static function ( $phpmailer ) {
        $phpmailer->Sender = '';
} );

Once 6.9.1 is released, you can remove it.

Replying to jorbin:

@SirLouen A single commit can close multiple tickets. As this is the one people are being directed to, it shouldn't be closed until a fix has been committed.

Yes, my intention was that: open a ticket in the External Libraries component for the PHPMailer upgrade and once fixed, close all. Anyway, if we cannot make it in time, we will need to push ​this patch for 6.9.1 as a temporary fix. This is why I was not planning to close this (just added the close tag). 👍

But personally I would prefer to keep PHPMailer in a separate ticket, because it will be including several more things than just this fix (also, it's more traceable when doing Google queries and that).

[abdullah2019]

It's not working.

[SergeyBiryukov]

In 61468:

External Libraries: Upgrade PHPMailer to version 7.0.2.

The latest version:

• Includes a fix for sendmail parameter problems in WordPress.
• Reduces memory consumption when sending large attachments.

References:

• ​PHPMailer 7.0.2 release notes
• ​Full list of changes in PHPMailer 7.0.2

Follow-up to [54937], [55557], [56484], [57137], [59246], [59481], [60623], [60813], [60888], [61249].

Props SirLouen, robinvandervliet, desrosj, siliconforks, digitalblanket, studiomondiale, jorbin, westonruter, dmsnell, zoe20, Monarobase, amanandhishoe, SergeyBiyrukov.
Fixes #64491. See #64368.

[jorbin]

@SergeyBiryukov @SirLouen Can either of you share some more information about how you tested [61468] to ensure it fixes this issue?

[siliconforks]

Replying to jorbin:

@SergeyBiryukov @SirLouen Can either of you share some more information about how you tested [61468] to ensure it fixes this issue?

It's complicated to test this because you have to install Sendmail. Not just any Sendmail clone, but the ​original Sendmail.

On a Ubuntu 24.04 machine I was able to install Sendmail with the following:

apt install sendmail

I wanted to use example.test as my domain name, so I edited /etc/hosts and added the following lines:

127.0.0.1  example.test
127.0.0.1  www.example.test

I then edited /etc/mail/local-host-names and added the following line:

example.test

Then I restarted sendmail:

systemctl restart sendmail

This was sufficient to get local delivery working. To test it, I installed WordPress 6.9 on this machine, I installed the ​Health Check plugin, and then in the admin section I went to Tools → Site Health → Tools → Mail Check. I entered an email address user@example.test where user is a local account on this machine, and clicked the Send test mail button. It displayed the following message: "We have just sent an e-mail using wp_mail() and it seems to work. Please check your inbox and spam folder to see if you received it."

To check mail on this machine I installed Mutt:

apt install mutt

Then I logged in as user and ran Mutt:

mutt

As expected, this showed the message with subject "Health Check – Test Message..." in the inbox.

Now, to trigger the error condition, I edited the file /etc/php/8.3/fpm/php.ini and added this line:

sendmail_path = /usr/sbin/sendmail -t -i -fnoreply@example.test

I restarted PHP:

systemctl restart php8.3-fpm

Then I tried sending mail again using the Health Check plugin. This time I received the dreaded error message "Could not instantiate mail function".

Now I applied the patch in [61468] and tried sending mail again. This time it was able to successfully send mail.

[SirLouen]

Replying to jorbin:

@SergeyBiryukov @SirLouen Can either of you share some more information about how you tested [61468] to ensure it fixes this issue?

Thanks @siliconforks that is a very good and simple way to test this.

Apart from what he said, I also had some unit tests going for the PHPMailer library that were not there already, checking for a ton of sendmail command parameter scenarios.

[jorbin]

It's complicated to test this

I'm specificly thinking about testing on affected systems rather than trying to create labratory conditions.

Because this is a regression that can fully break outbound email, that damaged IP reputation can hurt not just one site or application, and that reverting it (or downgrading to 6.8.3) has successfully solved the issue for every reporter, I think that the safest route for 6.9.1 is to revert [61010] rather than upgrade phpmailer. This doesn't need to preclude work in 7.0 that builds upon this attemmpt and tries to find new ways to ensure emails are successfully delivered.

[dmsnell]

thank you @jorbin. given our inability to establish any quantitative metrics on the impact of this change, whether to aid in email delivery or to hinder it, I support the revert.

perhaps we can start again in trunk and work with some of those who reported delivery issues to see if they can help provide testing and feedback that we need to avoid accidentally interrupting their service.

[SirLouen]

Replying to jorbin:

Because this is a regression that can fully break outbound email, that damaged IP reputation can hurt not just one site or application, and that reverting it (or downgrading to 6.8.3) has successfully solved the issue for every reporter, I think that the safest route for 6.9.1 is to revert [61010] rather than upgrade phpmailer. This doesn't need to preclude work in 7.0 that builds upon this attemmpt and tries to find new ways to ensure emails are successfully delivered.

With those premises, this is completely untestable. Precisely, things like RC here are completely useless because no one uses them anywhere near production (reason why no one caught this simple issue, which was theoretically "affecting deliverability").

The same is going to happen again here: no “reporter” is going to test any move towards 7.0. As Johnatan said, there was not enough critical mass to consider that this regression was urgent for a prompt 6.9.1 release for a reason is apparently impacting only a little subset of users with not ideally configured hosts according to hosting good practices.

We have reproduced the same conditions that they reported both manually and with unit tests: PHPMailer was simply bypassing the user-set (hosting-set) configuration in php.ini. With the PHPMailer patch, it will not be bypassed anymore and respect the user configs. What @siliconforks reproduced was accurately the affecting problem: PHPMailer is not overriding php.ini any more.

@siliconforks said:

Then I tried sending mail again using the Health Check plugin. This time I received the dreaded error message "Could not instantiate mail function".

As simple as this.

I not going to start a workflow keyword war. Do whatever you like.