You can build a professional website, configure SMTP correctly, and still have your emails end up in spam folders if your domain’s email authentication isn’t set up. This usually shows up after launching a contact form, sending WooCommerce order emails, or setting up newsletter software — everything appears to work, but messages either disappear, land in spam, or trigger a warning icon in Gmail and Outlook. When I review WordPress sites with email delivery problems, a missing SPF or DKIM record is one of the most common causes, and DMARC is missing even more often than the other two.
Why This Got More Urgent in 2024
SPF, DKIM, and DMARC used to be treated as a nice-to-have — the kind of thing that mostly helped, marginally, if you got around to it. Since February 2024, Gmail and Yahoo have run active bulk-sender requirements that changed that. Any domain sending 5,000 or more messages a day to Gmail addresses is permanently classified as a bulk sender, and that classification doesn’t expire even if the volume later drops. Bulk senders are required to authenticate with both SPF and DKIM, with at least one of them aligned to pass DMARC — meaning the domain in the visible “From:” address has to match the domain that SPF or DKIM actually authenticated.
Most WordPress sites, especially a new store or blog, are nowhere near 5,000 emails a day, so the bulk-sender threshold itself may never apply directly. What matters for a smaller site is the second-order effect: Gmail and Yahoo’s spam filters generally reward properly authenticated mail and penalise unauthenticated mail across the board, not just for domains that technically clear the bulk threshold. As of late 2025, industry monitoring puts compliant senders at roughly 89% average inbox placement, against 22–34% of mail from non-compliant senders getting routed to spam — a three-to-sevenfold penalty. That gap is the real reason this now sits well above “nice to have” for any site sending real business email, regardless of volume.
What Each Record Actually Does
SPF (Sender Policy Framework) is a published list, held as a DNS TXT record, of which mail servers are allowed to send email using your domain name. If your domain sends through your hosting provider, Google Workspace, Microsoft 365, and a newsletter platform like MailerLite or Brevo, all of those services need to appear in one combined SPF record — a domain should only ever have one SPF TXT record, and a common, entirely avoidable mistake is ending up with two because a plugin or a new email service added its own without checking for an existing one. A basic record looks like v=spf1 include:_spf.google.com ~all, with the exact value depending on which services you actually use.
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message, generated from a private key your email provider holds and verified against a public key published in your DNS as another TXT record. This is what proves a message genuinely came from your domain and wasn’t altered in transit — SPF only vouches for the sending server, DKIM vouches for the message content itself. Most providers generate the DKIM record for you; you copy a selector name and a long TXT value into your DNS, and the length is normal — it’s an encryption key, not something you’re expected to read.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) sits on top of both. It tells mailbox providers what to do when a message fails SPF or DKIM alignment — let it through anyway, send it to spam, or reject it outright — and it’s also the mechanism Gmail and Yahoo’s 2024 requirements specifically check for. A DMARC record also enables spoofing protection: without one, someone can send a fake email that appears to come from your domain, and there’s no DNS-level signal telling the receiving mailbox to be suspicious of it.
Setting Up All Three
1. List Every Service That Sends Email From Your Domain
Before touching DNS, list everything that sends mail as your domain — hosting-account email, Google Workspace or Microsoft 365, any SMTP plugin, newsletter software, a CRM, or marketing automation tools. Missing one here is the single most common cause of a legitimate email quietly failing SPF after setup, since anything not on the list isn’t authorized to send as you.
2. Find Your DNS Management Area
DNS is usually managed through your domain registrar, your hosting provider, or a separate DNS platform like Cloudflare — and it’s genuinely common for these to be in different places from each other. If you’re not sure where your domain’s DNS actually lives, check the registrar first; it’s the one place guaranteed to know where the authoritative nameservers point.
3. Add the SPF Record
Your email provider(s) will give you the exact SPF value to include. Add it as one TXT record at Host @. If you already have an SPF record and need to add a new service, edit the existing record to add another include: rather than creating a second TXT record — two SPF records on the same domain is invalid and can break authentication for everything, not just the new service.
4. Add DKIM Records
Each sending service typically generates its own selector and TXT value (something like selector1._domainkey as the host). Copy each one in exactly as provided — a truncated key is a common cause of DKIM silently failing without an obvious error message.
5. Add a DMARC Record
Add a TXT record at host _dmarc. Start with a monitoring-only policy:
v=DMARC1; p=none; rua=mailto:you@yourdomain.comThe p=none tag means “don’t do anything to failing mail yet, just watch” — this satisfies the Gmail/Yahoo 2024 requirement (which only asks for DMARC to exist, not for a strict policy) while you confirm nothing legitimate is failing. The rua= tag is worth adding even though the original setup doesn’t strictly require it: it’s an email address that receives periodic aggregate reports from mailbox providers showing exactly which sources are sending mail as your domain and whether they’re passing or failing. Without it, you’re setting a policy blind; with it, you get real data before tightening anything.
6. Verify, Then Tighten the Policy Gradually
Use a tool like MXToolbox, Google’s Admin Toolbox, or Mail Tester to confirm SPF, DKIM, and DMARC are all resolving correctly. DNS changes usually appear within minutes but can take several hours to fully propagate. Once the DMARC reports (or a few weeks of clean testing) confirm nothing legitimate is failing, move the policy from p=none to p=quarantine and eventually p=reject — jumping straight to p=reject before confirming everything passes is the fastest way to accidentally block your own contact form or order confirmation emails.
After any DNS change, physically test the things that matter: submit the contact form, trigger a WooCommerce order email, opt into the newsletter, and request a password reset. Confirming the records resolve correctly in a checker tool isn’t the same as confirming a real message actually lands in an inbox.
SMTP Solves a Different Problem
SPF, DKIM, and DMARC improve trust once a message is sent — they don’t get WordPress to send the message reliably in the first place. That’s what an SMTP plugin handles, routing outgoing mail through an authenticated service instead of the shared server WordPress uses by default. If you haven’t configured this yet, see how to set up SMTP in WordPress so contact form emails don’t go missing. Most reliable WordPress sites run both: SMTP to actually deliver the message, and the three DNS records above to make sure it’s trusted once it arrives.
Common Mistakes
- Creating a second SPF record instead of editing the first. A domain should have exactly one — multiple SPF records can invalidate authentication entirely rather than combining permissions.
- Forgetting a third-party sender. Marketing tools, CRMs, and SMTP plugins that send email as your domain all need their own entry in SPF and often their own DKIM selector.
- Jumping to
p=rejectimmediately. Without confirming SPF and DKIM are both configured correctly first, an aggressive DMARC policy can block your own legitimate mail. - Editing DNS in the wrong place. A Cloudflare-fronted domain in particular often has its real, authoritative DNS records somewhere other than where the hosting account’s control panel suggests.
- Not testing real forms after the change. Contact forms, WooCommerce emails, newsletter opt-ins, and password resets should each be tested individually after any DNS update, not assumed to work because the records validate in a checker tool.
Conclusion
SPF, DKIM, and DMARC used to be an optional deliverability nicety. Since Gmail and Yahoo’s 2024 bulk-sender rules, and the real inbox-placement gap that now separates authenticated from unauthenticated mail, they’re closer to a baseline requirement for any WordPress site that depends on its emails actually arriving. Set up all three, start DMARC on monitoring mode with a reporting address, watch the reports for a few weeks, then tighten the policy once you’ve confirmed nothing legitimate breaks.
Etienne Basson works with website systems, SEO-driven site architecture, and technical implementation. He writes practical guides on building, structuring, and optimizing websites for long-term growth.