Why Your WordPress Emails Land in Spam (and How I Fix It for Good)

Every few weeks a client sends me some version of the same message: “My contact form stopped working.” Nine times out of ten the form is working perfectly — the emails are just landing in spam, or getting silently dropped before they ever reach an inbox. Password resets, WooCommerce order receipts, booking confirmations, invoice notifications: when WordPress email fails, it fails quietly, and you usually only find out after a customer complains.

I’ve fixed this on dozens of sites now, and the process is almost always the same. Here’s exactly how I diagnose WordPress email deliverability and set it up so messages actually arrive.

Why WordPress email breaks by default

Out of the box, WordPress sends mail using PHP’s built-in mail() function. That means the email leaves directly from your web server, with no authentication and no reputation behind it. To a modern inbox provider, that looks almost identical to how spam is sent.

Three things go wrong at once. Your hosting server’s IP address is often shared with hundreds of other sites, some of which may already be blacklisted. Your domain usually has no records telling Gmail or Outlook that this server is allowed to send on its behalf. And the “from” address is frequently something like [email protected] instead of your real domain. Any one of these is enough to get filtered. Together, they’re fatal.

The good news: none of it is hard to fix. It just has to be done deliberately.

Step 1: Stop sending through PHP mail()

The single highest-impact change is to route WordPress email through authenticated SMTP instead of the server’s mail() function. Authenticated SMTP means WordPress logs into a real mail service with credentials before sending, exactly like your email client does.

On most sites I install a plugin like WP Mail SMTP or FluentSMTP, then connect it to a proper sending service rather than a personal Gmail account. My defaults are Amazon SES for high-volume or budget-conscious stores, and Postmark when transactional deliverability matters most — Postmark is built specifically for receipts and password resets, not marketing blasts, and it shows.

The moment email flows through an authenticated service on a reputable IP, a huge share of deliverability problems disappear. But there’s a second half most people skip.

Step 2: Authenticate your domain with SPF, DKIM, and DMARC

These three DNS records are how you prove to inbox providers that mail claiming to be from your domain is legitimate. If you only remember one thing from this article, remember that skipping these is why “I already set up SMTP and it’s still going to spam” happens.

SPF (Sender Policy Framework)

SPF is a DNS record listing which servers are allowed to send email for your domain. When you start sending through SES, Postmark, or Google Workspace, you add their sending servers to your SPF record. Receiving servers check it and, if the sender isn’t on the list, treat the message as suspicious. One thing to watch: a domain can only have a single SPF record, so if you use multiple services you merge them into one line rather than creating several.

DKIM (DomainKeys Identified Mail)

DKIM adds a cryptographic signature to every message. Your sending service signs outgoing mail with a private key, and a matching public key lives in your DNS. The receiving server verifies the signature, which proves the email genuinely came from you and wasn’t altered in transit. Every serious sending provider gives you the exact DKIM records to paste into your DNS — it’s copy, paste, verify.

DMARC (Domain-based Message Authentication)

DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails both — quarantine it, reject it, or just monitor. I always start new setups at p=none to collect reports without risking legitimate mail, confirm everything passes for a week or two, then tighten to quarantine and eventually reject. DMARC is also increasingly non-negotiable: Gmail and Yahoo now require it for anyone sending meaningful volume.

Step 3: Send from a real, consistent address

I make sure every automated email uses a proper address on the site’s own domain — something like [email protected] — and that this address matches the domain you’ve authenticated. Mismatched or generic server addresses undermine all the DNS work above. For WooCommerce specifically, I set the “from” name and address under WooCommerce → Settings → Emails so receipts and shipping notices stay consistent with the rest of the site’s mail.

Step 4: Test properly, then keep an eye on it

I never assume a fix worked just because a test email showed up in my own inbox. My go-to is Mail-Tester: send a message to the address it gives you and it scores your setup out of ten, flagging any SPF, DKIM, DMARC, or content issues. I aim for a solid 9 or 10 before I hand a site back.

I also turn on email logging — most SMTP plugins include it — so there’s a record of what WordPress tried to send and whether the provider accepted it. When a client says “the customer never got their receipt,” that log answers the question in seconds instead of guesswork.

The short version

If your WordPress or WooCommerce emails are landing in spam, work through it in order: route mail through authenticated SMTP with a reputable provider, add SPF, DKIM, and DMARC records for your domain, send from a real address on that domain, then test with Mail-Tester and enable logging. Do all four and your emails stop disappearing — reliably, not just for a week.

This is one of those fixes that’s invisible when it’s working and expensive when it isn’t. If you’re not sure where your site stands, send yourself a password reset and a test order right now. If either one lands in spam, you’ve got some DNS records to add — and now you know exactly which ones.