[wp-trac] [WordPress Trac] #64420: Default Envelope Return-Path can tarnish IP reputation for mail-sending hosts.

Tue Dec 16 00:13:57 UTC 2025

#64420: Default Envelope Return-Path can tarnish IP reputation for mail-sending
hosts.
-------------------------+------------------------------
 Reporter:  dmsnell      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Mail         |     Version:  6.9
 Severity:  normal       |  Resolution:
 Keywords:  close        |     Focuses:
-------------------------+------------------------------
Changes (by SirLouen):

 * keywords:   => close
 * type:  defect (bug) => enhancement
 * milestone:  Future Release => Awaiting Review

Comment:

 Let's talk about 6.9 pre-era and post-era to illustrate the whole point.

 In the 6.9 pre-era, what we encountered was mostly, hostings taking care
 of all-things-mailing, and some users just skipping all through it, with
 3rd-party plugins.

 To some extent this is what WP pretended the `wp_mail` to be. But
 personally, from the first day I used WP, I thought it was weird that
 something so important like “mail communications” was so weak by default
 and immediately required of 3rd parties to make it happen (or a lot of
 tweaking and even knowledge about `PHPMailer`).

 But one of the most important aspects in the 6.9 pre-era we found, was a
 `MAIL FROM` not aligning with the From address.

 Lets imagine the following example:

 I'm a good WP user, with basic knowledge about mailing and deliverability.
 I've been taught that SPF/DKIM/DMARC are influential things, and I want
 all 3 of them to pass easily, without much fuzz.

 We all know it's true that WordPress is not helping anyone to set a
 `From:` address. And this is a pain point, but at least, it's clearly
 documented a `wp_mail_from` hook to set such. I, as a good WP user, don't
 really want to deal with `PHPMailer` at all, and in fact, as a regular
 user, I should not even know that `PHPMailer` even exists (in fact, today
 could be PHPMailer and tomorrow could be `symfony/mailer`). So basically,
 knowing that I need to set this hook, to set my `From:` address I proceed
 accordingly, setting the `From:`for example to `hello at example.com`, an
 email I own and I can receive emails within my webhost mail client.

 Then, following my web host's mail configuration guideline, I set up the
 SPF record with the mail relay address, my DKIM with the RSA that the
 webhosting provides, and finally the DMARC with the corresponding receiver
 policy.

 And finally, I start sending emails with my WP site to find, that SPF is
 miserably softfailing, because the `Sender` and the `From` SPF are not
 aligned for some reason.

 How can we solve this? Originally,
 [https://core.trac.wordpress.org/ticket/49687#comment:6 the solution was
 this]: Having to hook, to the PHPMailer init hook, learning that PHPMailer
 exists, and how it works. **Definitely obnoxious** for an exemplary user.

 Here we have, an exemplary user, being hit in the ass by a WordPress
 decission to remove the recommended setting by `PHPMailer` of setting the
 MAIL FROM the same as the selected `From`.

 This is probably why, 99% of these users, obviously installed the `WP Mail
 SMTP` or equivalent plugin and forgot about all the obnoxious `wp_mail`
 system for obvious reasons. A silent majority that are simply ignoring the
 `wp_mail` commands because they are simply overriding it.

 But now, in the Post 6.9 era, this is switched around: With all the steps
 above, the exemplary user has a **perfectly set up and working mailing
 system**.

 Now lets go back to the Pre-6.9 era with a different type of user.

 On the other side we have the not-knowledgeable user that cannot care a
 bit about learning all this mailing concepts, and just wants a site that
 simply works and sends emails out of the box. So here is where web hosting
 system administrators need to take their decisions.

 Ensuring deliverability is something a little weird and completely lies on
 the MDA. There are some gold standards, but there are also some "fuzzy"
 ideas on what is better or not. WordPress as an agnostic software (and
 mostly relying on PHPMailer), should only follow those gold standards.

 Having this in mind, some were suggesting, they only cared about two
 things to ensure such deliverability:

 - Simple SPF passing (based on Return-Path FQDN)
 - Return-Path delivery capacity (ensuring that, in case of mail bounce,
 email could be delivered to an existing inbox).

 How to easily solve this?

 1. Setting a default hoster-controlled, return path, for example:
 `defined-alias at hosters-example.org`
 2. Creating a local inbox for such `defined-alias`
 3. Configuring the `hosters-example.org` SPF record for their mailing
 relay.

 With this scenario what we have?

 ✅ Since they control the `Sender` address (because there is no sender
 address set by WP by default), the sender is that random email, hence we
 have capacity to receive emails there
 ✅ SPF passing because they control both the DNS and the FQDN for the
 Sender address.
 ❓ Ignoring DMARC
 ❓ Most webhosts don't configure by default DKIM and solely rely on the
 domain registered in the hosting panel. So passing DKIM won't happen by
 default. Passing DKIM means passing DMARC as long as SPF softfails.

 But for many MDA, this is somewhat enought to ensure deliverability (but
 as we have seen, requirements are being strenghten with the years passing)

 But there are a couple of problem. The most important: It's impossible to
 SPF align `From:` and `MAIL FROM`, not even in relaxed mode without
 altering `PHPMailer` behaviour as we commented  before. These hosts can
 only rely on softfailing for SPF, seldomly passing DKIM and just having a
 valid `Return-Path`.

 Post 6.9 the scenario is the following for these hosts:

 ❌ Since some people are not configuring the DNS for their domains, they
 must rely on having control of the domain's DNS to help them pass SPF/DKIM
 otherwise they will have SPF failing, DKIM failing, and DMARC failing
 ❌ And since the domain SPF for the domain is failing, they won't have
 alignment.

 The wrong part here, is that webhost system administrators should have the
 tools and the skills to make everything happen.

 1. Force their users to set their NS to their DNS so they can have some
 agency over their records
 2. Ensure incoming mails to `wordpress at example.org` can be catched (or
 ignore all emails to that inbox)
 3. If they cannot enforce their users to set their NS, advice them on
 setting their DNS if they are willing to have a working mailing system
 (cPanel has this menu for example)

 Yes, its true, that before with a very weak and simple configuration, this
 poorly configured hosts had a very simplistic delivery system that to some
 extent ensured some degree of deliverability

 But this was in exchange of killing the “exemplary users” and forcing them
 to "learn" about `PHPMailer` principles (and the `phpmailer_init` which
 should not be recommended the use, unless for special cases, like setting
 `isSMTP`).

 I can understand the frustration of some web hosts, because now they have
 to significantly upgrade their systems to ensure the same degree of
 deliverability. Ensuring this, will differentiate the top web hostings
 from the very basic ones and will make available the full set of SMTP
 tools for top quality deliverability (Full SPF Alignment/DKIM/DMARC
 passing).

 Big relays like Mailgun, SendGrid and SES, won't rely on poorly configured
 DKIM/SPF records.

 But from my perspective, WordPress, simply as a software provider (and to
 some extent, as a "proxy" to PHPMailer capabilities), can only ensure to
 provide the maximum capabilities at the minimum configuration for the
 “exemplary user”.

 **This is my "use-case" when taking decisions** on what to introduce and
 what not.

 A bit long discourse, but I think I have not forgotten any of the most
 relevant elements regarding this topic.

 PS: Please keep this `close` as this discussion should get to an end at
 some point, and I don't like having tickets in `Mail` component without a
 final keyword (just like #60420)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64420#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform