[wp-trac] [WordPress Trac] #60420: Default wordpress at site.com sender address can be problematic

WordPress Trac noreply at wordpress.org
Thu Aug 7 14:28:08 UTC 2025


#60420: Default wordpress at site.com sender address can be problematic
-----------------------------+------------------------------
 Reporter:  thinlinecz       |       Owner:  (none)
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Mail             |     Version:  1.5.1.2
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:
-----------------------------+------------------------------

Comment (by michael.orlitzky):

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

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


 > === Advanced User
 >
 > The advanced user, in this case, a person like you that has his main
 mail service outside, say Google Workspace, but needs the local MTA
 installed with WP to operate.
 >
 > Firstly, I'm assuming that SPF and DKIM are out of this equation
 correctly configured. Neither SPF and DKIM care about the local-part. You
 can pretty much use any randomized local part and it will still get
 through as long as the domain has the SPF pointing to your WP host and a
 DKIM selector with the public key rightly configured to match the WP local
 MTA

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

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

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

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

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


More information about the wp-trac mailing list