During our February 5, 2026, Office Hours livestream, a viewer had an interesting question about email deliverability. It was a question that perfectly compliments a recent stream Nathan, our livestream host, did on the topic: Who stole my email? Getting WordPress emails to the inbox.
They asked what might be wrong with their emails and why they are seeing “Mail delivery failed” messages. Fortunately, all they needed to begin troubleshooting was in the error message itself.
The initial question
Before we dive into diagnosing the issue, it’s important to understand the issue itself. To begin, here is the question our viewer asked.
Recently we've noticed that some emails are being put into spam with the subject line “Mail delivery failed. Returning message to sender.” When I dig into it, it isn't spam. They're returned emails containing receipts from sales being made to our website. My question is, is this a DKIM problem or WP Mail delivery problem or something else. I just want to get directions.
This description is a perfect example of how email failures look like one problem while being caused by another.
There are two parts to this question: why are those emails labelled as spam and why are they not delivering properly. Those emails are Non-Delivery Reports (NDR), or bounce messages, informing the sender–our viewer–that the receipts they tried to send were rejected by the receiver (their customers).
Those bounce messages likely landed in the spam box due to a configuration or filter on our viewer’s receiving email server. They need to simply check those and ensure there are no banned keywords or that the Spam Score is adjusted properly.
More important, however, is the second part of the question.
Bounce messages usually have the answer
When opening a bounce message for a failed delivery, we’d not blame you if you felt overwhelmed at first. It’s a lot of lines of text and, as Nathan put it, looks like gobbledygook.
Looking more closely, however, will usually reveal vital information. In the case of our viewer, who provided the error message, the message contained the core of the problem.
550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
550-5.7.26 Authentication results:
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF with IP = did not pass
We can see that Gmail did not allow the message to go through because it failed to authenticate via SPF or DKIM. Nathan discusses both of these authentication methods in the livestream we linked at the beginning of the stream, but to put it simply:
SPF: Verifies that the sending server is authorised to send email on behalf of the specific domain.
DKIM: Ensures that the email content has not been tampered with in transit.
Together, these tell inbox providers that this website is allowed to send email on behalf of this domain and nothing has happened to the content.
Gmail has some of the most stringent authentication rules and we don’t blame it. Spam is everywhere. That’s why proper email authentication is mandatory nowadays.
Why this isn’t a WordPress or plugin problem
In most cases, the email itself (a receipt of purchase in this case) is generated correctly and sent without any obvious issue. The problem happens after that, when the recipient has to decide whether to trust the sender.
That’s where SPF and DKIM come into play and can vouch for the sender. They typically live in the DNS zone of the sending domain as text records. The viewer mentioned they have contacted support, so we expect the issue to be resolved swiftly as those records are not difficult to edit or create.
A dedicated email service provider like Titan is another option and can simplify this. Emails sent through them are already authenticated and their servers have high sender reputation.
Error messages are your friends
The fastest way to find out why your emails are not sending (or why anything at all is not working) is to look at the error message you are getting.
In the case of our Office Hours viewer, it told them their emails are not properly authenticated, so Gmail didn’t let them through. Combining that knowledge with a properly configured SPF and DKIM records, or a fully dedicated email service, will ensure all future emails arrive without issue.
For stores, agencies, and anyone else selling a product or service, reliable transactional email is more than just a necessity. It shows reliability and inspires trust and confidence in clients.
And if you have any questions about your online store, want agency advice, or want to learn more about hosting and websites in general, register for our Office Hours livestreams.
FAQ
My SPF and DKIM records are already set up, so why are emails still failing?
Having SPF and DKIM records present in your DNS isn't always enough on its own; the records also need to be correctly configured for the specific server that's actually sending the email.
A common mismatch occurs when a site moves to a new hosting provider or starts using a transactional email service (like Mailgun or SendGrid) but the SPF record still only references the old server's IP. Similarly, DKIM requires a public key published in DNS that matches the private key held by the sending mail server. When authentication is still failing despite records existing, the bounce message's detailed error output is again the right starting point, since it often specifies exactly which check failed and why.
Can a customer's email provider start rejecting my site's emails even if they accepted them fine before?
Yes, and this catches many site owners off guard. Inbox providers like Gmail and Yahoo periodically tighten their sender requirements, and what passed authentication a year ago may no longer meet today's standards. Changes on the recipient side can also suddenly block emails that had been arriving fine for years. This is another reason to keep an eye on your bounce messages rather than assuming that no news is good news on the email delivery front.
Does the email address I use as the "From" address on WordPress transactional emails matter for deliverability?
It matters considerably. A very common setup on WordPress sites is to send transactional emails (order confirmations, password resets, contact form notifications) using a "From" address like [email protected] or even a generic address, while the actual sending happens through the web host's default mail server.
If the SPF record for your domain doesn't authorize that mail server to send on behalf of your domain, the email will fail authentication regardless of how legitimate the content is.
Should I be monitoring email delivery proactively, or is waiting for bounce messages enough?
Waiting for bounce messages is a reactive approach that only catches hard failures. Softer failures, where emails are silently delivered to spam folders rather than bounced, generate no error message at all. A customer whose order confirmation went straight to their spam folder may never say anything; they might just assume your site is unreliable.
Tools like Google Postmaster Tools (free for domains that send to Gmail) can give you sender reputation data and help identify when deliverability is quietly degrading before it becomes a visible problem. For high-volume transactional senders, most dedicated email services also provide delivery dashboards showing open rates, bounce rates, and spam complaint rates.