[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