New order notification emails weren’t reaching an admin’s Gmail inbox — not landing in spam, simply not arriving at all — and the frustrating part was that WordPress’s own wp_mail() function consistently reported success on every attempt, which ruled out the usual first suspects: a broken mail function call, a plugin conflict, or a server outage.
Why “it says it sent” doesn’t mean “it arrived”
wp_mail() reporting true only confirms that the message was successfully handed off to the server’s local mail transport for delivery — it says nothing about what happens after that hand-off, including whether the receiving mail server (Gmail, in this case) actually accepted or silently discarded it.
The header hiding the real problem
The actual cause was in the message headers: WooCommerce’s configured “From” address was a @gmail.com email, while the message itself was physically being sent by the hosting server’s own mail transport — not by Google’s. Gmail’s SPF (Sender Policy Framework) records only authorize Google’s own infrastructure to send mail claiming to be from a @gmail.com address. A message that claims to be from Gmail but originates from an unrelated server fails that check outright, and Gmail’s spam defenses treat a failed SPF check on a message impersonating one of their own addresses as a strong spoofing signal — especially when the recipient is also a Gmail address.
The result: the message was silently dropped or spam-filtered well before it ever reached an inbox to check, which is exactly why it never showed up even in spam.
The one-line fix
The store’s own domain already had a valid SPF record in place, authorizing its hosting provider’s mail servers — it simply wasn’t being used, because the “From” address pointed at Gmail instead. Changing WooCommerce’s email “From” address to a domain the sending server is actually authorized for (orders@[storedomain].com) resolved it immediately: a test order email landed in the inbox within a minute, with no new plugin, no SMTP relay, and no DNS changes required.
Key takeaways
- “The function returned success” and “the email was delivered” are two different claims — diagnosing deliverability requires checking authentication, not just the sending call.
- Using a Gmail address as a “From” header when the message doesn’t actually originate from Google’s servers is a near-guaranteed way to fail SPF and get silently filtered.
- Check the domain’s existing SPF record before reaching for a new SMTP plugin — often the authorization already exists and just isn’t being pointed at.
Running into a similar limitation in your own WooCommerce or WordPress admin? Let’s Talk — Artintech Solution builds exactly this kind of custom store tooling.