Email Authentication Essentials (SPF, DKIM & DMARC)
Master the foundations of email security by learning how SPF, DKIM, and DMARC work together to prevent spoofing and phishing. Ideal for website owners, freelancers, and small businesses.
Every domain that can send email is also a domain someone else can pretend to send email from. That is the uncomfortable fact behind most phishing and invoice-fraud attempts: with no authentication in place, anyone can type your company's name into the "From" field, and your customers, vendors, and employees have almost no way to tell the difference.
SPF, DKIM, and DMARC exist to close that gap. None of them is complicated on its own, but most explanations either flatten them into "just turn on email security" or bury you in RFC language before you understand what problem you're actually solving. This guide does neither. It walks through what each protocol checks, how the three work together, and the exact DNS records you'll need to publish to set them up properly.
Why this isn't optional anymore
Major inbox providers, including Gmail and Yahoo, now expect basic SPF, DKIM, and DMARC configuration even from senders with relatively modest volume. Missing any one of the three increasingly means your mail lands in spam, or never arrives at all — regardless of how legitimate the content is. A domain with no authentication isn't just easier to spoof; it's also a domain whose own real mail is getting harder to deliver.
The Three Layers of Email Trust
Each protocol answers a different question. Together, they cover the whole chain.
SPF
Sender Policy Framework. A DNS record listing exactly which mail servers are allowed to send email for your domain.
Checks: the connecting server
DKIM
DomainKeys Identified Mail. A cryptographic signature added to every outgoing message, proving it came from you and wasn't altered in transit.
Checks: the message itself
DMARC
Tells receiving servers what to do when SPF or DKIM fail, and sends you reports either way so you can see what's happening.
Checks: that SPF/DKIM actually match the visible sender
How the Three Work Together
Every inbound message gets checked in roughly this order, in a fraction of a second.
- 1
A message leaves your server
The receiving mail server notes which IP address actually delivered the message.
- 2
SPF check
The receiver looks up your domain's SPF record and asks: was this IP address on the approved list?
- 3
DKIM check
The receiver fetches your public key from DNS, using the selector named in the message header, and verifies the signature matches.
- 4
DMARC alignment and policy
DMARC checks whether the domain that passed SPF or DKIM actually matches the domain shown in the From address, then applies whatever policy you've published: deliver, quarantine, or reject.
SPF, in Practice
SPF lives as a single TXT record at your root domain. It lists every service authorized to send mail on your behalf, so a receiving server can compare that list against the IP address actually delivering the message.
v=spf1 include:_spf.google.com include:mailgun.org ~all
Each include: adds the approved senders of another domain's SPF record, which is how you authorize third-party tools like Google Workspace or a transactional email service. The tag at the end controls what happens when a sender isn't on the list: ~all marks unlisted senders as suspicious but mostly still lets the mail through, while -all tells receivers to reject it outright.
The catch: SPF allows a maximum of 10 DNS lookups per check. Every include:, a, and mx mechanism counts toward that limit. Cross it, and SPF stops evaluating and fails outright — even for genuinely authorized mail. This is the most common reason SPF quietly breaks after a company adds a fourth or fifth email tool.
DKIM, in Practice
DKIM works differently from SPF: instead of approving servers, it cryptographically signs the message itself. Your mail server holds a private key and uses it to sign each outgoing message; the matching public key lives in DNS at a "selector" subdomain, so any receiving server can look it up and verify the signature.
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...
Because DKIM travels with the message header rather than depending on the connecting IP, it tends to survive being forwarded between mail servers far better than SPF does — which matters more than it sounds like once mailing lists or forwarding rules get involved.
Good news: Google Workspace, Microsoft 365, and most transactional email providers generate and rotate DKIM keys for you automatically once you've added the DNS record they give you. Treat key rotation as something to periodically verify rather than manage by hand.
DMARC, in Practice
DMARC is the layer that actually makes decisions. It doesn't check anything new on its own — instead, it confirms that whichever protocol passed, SPF or DKIM, was checking the same domain that appears in the visible "From" address, then tells the receiving server what to do about it.
v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-reports@yourdomain.com
The p= tag is the policy itself, and it's worth understanding all three settings before you publish anything stricter than monitoring.
| Policy | What happens to failing mail | When to use it |
|---|---|---|
| p=none | Delivered normally; you only receive reports | Always start here |
| p=quarantine | Routed to spam or junk folder | Once reports look clean |
| p=reject | Blocked before delivery entirely | Final stage, once confident |
The rua= address is where aggregate reports get sent — daily summaries showing which sources passed or failed authentication for your domain. Reading those reports for a few weeks before tightening your policy is what separates a safe rollout from an embarrassing one.
Mistakes That Quietly Break Authentication
Two SPF records on one domain
DNS only allows a single SPF TXT record. A second one (often added by a new tool that didn't check first) doesn't add permissions, it just invalidates SPF entirely.
Jumping straight to p=reject
Skipping the monitoring stage means the first sign of a misconfiguration is your own legitimate mail silently bouncing, with no warning beforehand.
Ignoring subdomains
DMARC only covers the exact domain by default. An unprotected subdomain is exactly where an attacker will aim if your main domain is locked down.
Forgetting SPF after adding a new tool
Every new sending service needs its own include: added to SPF, and it's easy to launch a new tool without remembering this step.
A Safe Rollout Plan
Follow this order, and it's nearly impossible to break your own mail delivery.
- 1Publish SPF and DKIM for every service that legitimately sends mail on your behalf.
- 2Publish DMARC at p=none so you start collecting reports without affecting delivery.
- 3Review reports for two to four weeks and identify any legitimate source that's failing.
- 4Fix SPF or DKIM for anything legitimate that showed up as a failure.
- 5Move to p=quarantine, and watch reports closely for another stretch.
- 6Move to p=reject once quarantine has run clean for several weeks.
Tools for Testing and Monitoring
A handful of free tools make this whole process easier than digging through raw report files by hand. Lookup tools like MXToolbox or Google's Admin Toolbox let you check a domain's current SPF, DKIM, and DMARC records and flag obvious syntax problems. For ongoing monitoring, dedicated DMARC report services parse the aggregate reports your domain receives into a readable dashboard, which becomes genuinely necessary once you have more than a couple of sending sources to track.
Quick Questions
Do I need all three, or is DMARC enough?
DMARC depends on SPF and DKIM actually passing first. Without at least one configured correctly, DMARC has nothing to evaluate and fails by default.
Will this change how my email looks to recipients?
No. All three are background DNS and header checks. Nothing about the message content, formatting, or send time changes for the person reading it.
I use Google Workspace or Microsoft 365. Do I still need to do this?
Yes. Both platforms sign mail with DKIM and let you publish SPF, but you still have to add the DNS records yourself and set up DMARC manually — neither is enabled automatically.
What actually happens if I just do nothing?
Nothing breaks immediately, but your domain stays easy to spoof, and inbox providers are increasingly likely to filter or reject your unauthenticated mail outright.
None of this requires a security background — it requires patience, a DNS dashboard, and a willingness to monitor before enforcing. Set up SPF and DKIM for everything that legitimately sends mail on your behalf, publish DMARC at its softest setting, read what it tells you, and tighten the policy only once you trust the reports. That sequence, more than any single record, is what keeps a domain both deliverable and safe to receive mail from.