Email Deliverability: SPF, DKIM and DMARC Explained
Your emails land in spam or get rejected, and everyone keeps saying you need "SPF, DKIM, and DMARC." Here's what the three records actually do — and the safe order to set them up.
Common signs of this issue
- Your legitimate emails frequently land in recipients' spam or junk folders.
- Messages bounce with errors mentioning authentication, "unauthenticated," 550 rejections, or DMARC.
- Gmail or Outlook recipients specifically don't get your mail — the strictest enforcers of these rules.
- You've seen bounce-backs for messages you never sent, or customers mention emails 'from you' that weren't — spoofing, which these records exist to stop.
- A deliverability checker or your provider flagged missing SPF, DKIM, or DMARC.
Safe checks you can do yourself
None of these require sharing passwords with anyone.
- Get your current state in two minutes: run your domain through a free email authentication checker (search the phrase — several good ones; mail-tester also works by scoring a message you send it). It reports pass/fail for each of the three, read-only, no login.
- Inventory everything that sends email as your domain before touching records — your mail provider, your website's forms, newsletter tools, CRM, invoicing software. Authentication must vouch for ALL of them; the forgotten sender is the classic reason 'we set this up and the newsletter still goes to spam.'
- Check SPF: exactly one TXT record starting
v=spf1, listing every legitimate sender (each service's docs give its include line), usually ending~all. Two SPF records = both invalid — the most common self-inflicted wound in this whole area. - Enable DKIM at each sending service (a switch or setup step in their dashboard) and publish the DNS records they hand you. DKIM is per-service — your mail provider AND your newsletter tool each sign their own mail.
- Add DMARC last, gently: a TXT record at
_dmarc.yourdomain.comstarting withv=DMARC1; p=none;plus a reporting address.p=nonechanges nothing about delivery — it just makes you compliant with Gmail/Yahoo's baseline requirement and starts reports showing who sends as you. - Re-test after DNS propagates (give it a day), fix what still fails, and only consider tightening DMARC (
p=quarantine, thenp=reject) after weeks of reports show all your legitimate mail passing.
What this usually means
The three records answer one question receivers now insist on: is this email really from this domain? SPF publishes the list of servers allowed to send for you. DKIM puts a cryptographic signature on each message that proves it wasn't forged or altered. DMARC sets the policy — what receivers should do with mail failing both checks — and sends you reports of everyone sending as your domain. Missing or broken records mean your mail arrives unvouched-for, and modern filters treat unvouched-for as suspicious.
This went from best-practice to effectively mandatory when Gmail and Yahoo began enforcing authentication requirements in 2024 — senders without SPF/DKIM and at least a p=none DMARC record now see mail quarantined or rejected outright by the world's biggest inboxes. If your deliverability degraded 'for no reason' in recent years, this is the leading suspect.
Done correctly, this is a one-time setup with occasional maintenance (add an include when you adopt a new sending service), and it's the single biggest deliverability improvement most senders can make. As a bonus, an eventually-enforced DMARC policy blocks most spoofing of your domain — protecting your customers from fake invoices 'from you' and your reputation from the fallout.
What not to do
- Don't create two SPF records — a domain gets exactly one, with all senders merged into it; a second record invalidates both and breaks what worked.
- Don't jump straight to <code>p=reject</code> on DMARC — before monitoring confirms every legitimate sender passes, a strict policy blocks your own real mail. The path is none → monitor weeks → quarantine → reject.
- Don't forget third-party senders — the newsletter tool, the CRM, the website's form mailer. Each unlisted sender fails authentication precisely after you've made the rules matter.
- Don't hand-compose record syntax from memory or forums — copy each service's exact published values; SPF in particular has sharp edges (a 10-lookup limit, one-record rule) that punish improvisation.
- Don't set-and-forget forever — glance at DMARC reports (or a free report-digest service) occasionally, and update SPF/DKIM whenever you add or drop a sending service.
When to get help
The individual records are simple; the edge cases aren't — multiple senders, the SPF lookup limit, migrating providers mid-setup, reading DMARC reports, and tightening policy without dropping your own mail. A practiced hour sets all three correctly for every sender you have and leaves DMARC monitoring in place; a follow-up later tightens policy safely. Objective acceptance test: all three pass on a checker, mail-tester scores 9–10, and a test email lands in a Gmail inbox proper. For a business that lives on email, this is among the highest-yield small jobs there is.
Not sure what to do next?
Answer a few short questions and we'll point you to the safest next step — DIY, a freelancer, or a direct review. No passwords required.
Is this a business website? If this issue may be costing you leads, sales, or trust, you may want a direct review instead of trial and error.
Frequently asked questions
Do I really need all three records?
For reliable delivery today, yes: SPF and DKIM do the proving, and Gmail/Yahoo now expect at least a monitoring-mode DMARC on top. Think of it as one system with three parts rather than three optional extras.
What does p=none actually do?
Nothing to your delivery — that's the point. It satisfies the baseline requirement, and turns on reports showing every server sending as your domain. You run p=none while confirming all your legitimate senders pass, then tighten. It's the seatbelt-check before the enforcement.
Why did my email suddenly start going to spam in 2024?
Gmail and Yahoo began enforcing sender authentication that February — unauthenticated mail that had coasted for years started getting quarantined or rejected. If your problems date to then, these records are almost certainly the fix.
Will this stop people spoofing my domain?
Once DMARC is tightened to quarantine/reject after monitoring, receivers are instructed to junk or refuse mail that fails authentication — which blocks most spoofing of your exact domain. (Lookalike domains — yourc0mpany.com — are a different scam these records can't touch.)
I set everything up but the newsletter still goes to spam. Why?
Almost always: that service isn't covered — missing from SPF, or its DKIM was never enabled. Authentication is per-sender. Run the checker against a message sent BY that service (mail-tester is ideal for this) and add what's missing.
What's the SPF 10-lookup limit I keep seeing warnings about?
An SPF record may trigger at most 10 DNS lookups; each 'include:' spends some. Domains that accumulate many services blow past it, and SPF then fails silently for everyone. Fixes: prune unused includes, or use a flattening service. It's the main reason mature SPF records deserve an occasional audit.