Email Deliverability 101: SPF, DKIM & DMARC Explained
If your order confirmations and password resets keep landing in spam, the cause is almost always missing email authentication. Here's what SPF, DKIM and DMARC do — and how to set them up.
Blocking incoming spam is half the battle; the other half is making sure your own mail actually arrives. Mailbox providers like Gmail and Outlook now expect every sender to prove who they are. Fail that check and your WordPress emails get filtered — or silently dropped. Three DNS records do the proving: SPF, DKIM and DMARC.
SPF — who's allowed to send
SPF (Sender Policy Framework) is a DNS TXT record listing the servers permitted to send email for your domain. When a message arrives, the receiver checks whether it came from a listed source. If a spammer forges your
domain from an unlisted server, SPF flags it.
A typical record looks like v=spf1 include:_spf.google.com ~all. The key mistakes: listing too many includes (there's a 10-lookup limit) and forgetting to add your transactional email provider.
DKIM — a tamper-proof signature
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message using a private key held by your mail server. The matching public key lives in your DNS. The receiver verifies the signature, proving two things: the mail really came from your domain, and it wasn't altered in transit.
Your email host or transactional provider generates the key pair and gives you a DNS record to publish. Once it's in place, signing is automatic.
DMARC — the policy that ties it together
DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receivers what to do when SPF or DKIM fails, and asks them to send you reports. A starter record: v=DMARC1; p=none; rua=mailto:you@yourdomain.com.
p=none— monitor only; collect reports without affecting delivery. Start here.p=quarantine— send failing mail to spam.p=reject— refuse failing mail outright. The end goal, once you're confident.
Roll out gradually. Begin at p=none, read the aggregate reports for a few weeks to confirm all your legitimate senders pass, then tighten to quarantine and finally reject.
Jumping straight to reject risks bouncing your own mail.
Why this matters for a WordPress site
By default WordPress sends mail with PHP's mail() function from your web server — which is rarely authorised in your SPF record and never DKIM-signed. That's why so many stores find password resets and WooCommerce receipts
in the spam folder. The fixes:
- Send through an authenticated SMTP provider rather than raw
mail(). - Publish SPF, DKIM and DMARC for the exact from-address domain you send with.
- Make sure your "from" domain matches your authenticated domain — mismatches break alignment and fail DMARC.
Deliverability and anti-spam go together
Strong authentication also protects your reputation from the inbound side. When you block disposable addresses and validate mailboxes before sending confirmations, you avoid bouncing mail into dead inboxes — and high bounce rates are exactly what drag a sender's reputation down. Clean lists in, authenticated mail out.
SPF says "these servers may send as me", DKIM says "and here's cryptographic proof I sent this", and DMARC says "here's what to do if either check fails." Together they're the difference between the inbox and the spam folder.
Check your setup
Spamify includes a built-in SPF / DKIM / DMARC checker in the dashboard, so you can confirm all three records are present and valid without leaving WordPress — alongside the inbound engine that keeps junk out of your forms in the first place.
Land in the inbox, not the spam folder
Check your SPF, DKIM and DMARC records right inside WordPress, and keep your lists clean at the source.
Explore the tools
