Problem Overview
The recent update to WordPress 5.7 (released on 10 March 2021) has effectively broken the ability for WordPress to send emails on most websites.
This is because it now, foolishly, sets the "Sender" email address to be whatever WordPress (or a plugin) has set for the "From" email address. The "Sender" email address on properly-configured web servers is a legitimate email account. But the "From" address used by WordPress is rarely a legitimate email address; common examples are wordpress@<domain> and mail@<domain>.
Mail servers that receive an email from a non-existent email address will reject the email. Therefore, emails sent from WordPress using these "From" addresses are unlikely to be received.
Quick Workaround — Email Hosted By Us
To quickly mitigate this problem across most of our hosting customers, we have created email forwarders for the commonest WordPress "From" addresses, so that an email address like wordpress@<domain> will be seen as valid. We have applied this to all hosting accounts where a WordPress installation has been detected.
This was put in place on 18 March 2021, however the WordPress update was released on 10 March 2021, so any websites that updated to 5.7 between these dates, and attempted to send an email, will have most likely had that email not delivered (and no bounce would have been received by the website administrator, for the same reason).
Quick Workaround — Email Hosted Externally
Our mitigation described above will not work for domains where the email is hosted externally (e.g. Office 365), because we cannot create an email forwarder on another service provider.
In these cases, you should arrange for email forwarders to be created on that email service provider. If you are not sure which email address(es) your WordPress and plugins use, we recommend adding the following, which appear to be the commonest:
wordpress@<domain>mail@<domain>email@<domain>
Permanent Solution
We are hoping that WordPress will soon release another update to fix this problem. WordPress are tracking the bug here: https://core.trac.wordpress.org/ticket/52822
Technical Details
For those interested, we have included more technical details below about the change that was made and why it is a problem.
What's the difference between a "Sender" address and a "From" address?
The "From" address is part of the email message itself and is what is shown to recipients and what is used when a recipient presses reply.
The "Sender" address is like the return address that's written on the back of the envelope, and is what will receive a non-delivery report. The "Sender" is what mail servers first check for authenticity, e.g. through SPF.
When you send email from your mailbox, these are usually the same email address. But when a third-party service sends an email on your behalf — such as a website — it is unlikely to be the same, because the service cannot properly authenticate itself as the genuine operator of that "From" address. Instead, it will commonly use a system-generated email address, using the service's own domain name, which can be properly authenticated. In the case of cPanel hosting accounts, the format of that system-generated email address is <user>@<server> where <user> is the cPanel username and <server> is the cPanel server's hostname — so an example address might be acmeserv@cp75.pre.net.au. This is a valid email account, which passes SPF and DKIM checks, and will be used as the "Sender" address in lieu of a website overriding it.
Why is this a problem?
When a mail server receives an email, one of the many checks it does to ensure legitimacy is verify that the "Sender" address can itself receive email. Otherwise, it would have nowhere to send a non-delivery report, and that would permit anonymous and unaccountable emails to be sent, which is undesirable. (Mail servers do not perform this check on the "From" address, because that's not used for non-delivery reports.)
Further, mail servers will also check the domain of that "Sender" address and verify, using SPF, that the sending domain explicitly permits this server to send mail on behalf of that domain name.
WordPress, by default, sets the "From" address to always be of the format wordpress@<domain>. It's possible for plugins to override that and use, for example, the Site Administrator email address in Settings, or an email address configured in that plugin. But many do not. So, a majority of emails sent by WordPress websites will have the "From" address set to wordpress@<domain> or something similar (as examples, Divi's contact form uses mail@<domain>, and Elementor's contact form uses email@<domain>).
It is unlikely that these addresses have been set up as an email address. This is not normally a problem because notifications sent by the website are usually not intended to be replied to by the recipient — and if they are, a "Reply-To" header would be included for that purpose.
But now that this address is also being used as the "Sender", the receiving mail server will reject the email if that email address is not set up to receive email.
As a result, for any affected sites (where the "From" address is an email address that doesn't receive email, such as wordpress@<domain>), any email sent by WordPress will not be accepted by the receiving mail server. And nobody will receive the non-delivery report, either.
It may also be the case that, even if the email address was configured, if the email is hosted externally and the domain's SPF record does not permit the website's server to send on behalf of that domain, once again a receiving mail server would reject the email.
How we applied our quick workaround
We identified all hosting accounts that contain a WordPress installation, and for those hosting accounts, we created email forwarders for wordpress@<domain>, mail@<domain> and email@<domain>, and forwarded those to the system-generated email account, <user>@<server>, that already exists on every hosting account and is what is used by default as the "Sender" for any website that is not overriding that setting.
