SPF vs DKIM vs DMARC — What's the Difference?
Three Protocols, One Goal
If you have spent any time looking into email security, you have probably encountered three acronyms: SPF, DKIM, and DMARC. They are often mentioned together, and for good reason — they form a layered defense system that protects your domain from being used in phishing and spoofing attacks.
But each protocol does something different. Understanding how they work individually — and how they work together — is essential for anyone responsible for a domain's email security.
SPF: Who Is Allowed to Send?
SPF (Sender Policy Framework) is the simplest of the three. It answers one question: which mail servers are authorized to send email on behalf of your domain?
Here is how it works:
- You publish a DNS TXT record listing the IP addresses and services that are allowed to send email for your domain.
- When a receiving mail server gets an email claiming to be from your domain, it checks your SPF record.
- If the sending server's IP address matches your SPF record, the check passes. If not, it fails.
A typical SPF record looks like this:
v=spf1 include:_spf.google.com include:sendgrid.net -all
This says: "Google and SendGrid are authorized senders. Reject everything else."
SPF strengths:
- Simple to set up — just a single DNS TXT record
- Widely supported by mail providers
- Immediately prevents unauthorized servers from passing SPF checks
SPF limitations:
- Only checks the envelope sender (the
Return-Path), not theFromheader that users actually see - Breaks when emails are forwarded, because the forwarding server's IP is not in your SPF record
- Has a 10 DNS lookup limit, which can be a problem if you use many third-party services
DKIM: Is the Message Authentic?
DKIM (DomainKeys Identified Mail) takes a different approach. Instead of checking who sent the message, it verifies that the message has not been tampered with in transit.
Here is how it works:
- When your mail server sends an email, it adds a cryptographic signature to the message headers using a private key.
- The corresponding public key is published in your DNS records.
- The receiving mail server retrieves the public key and uses it to verify the signature.
- If the signature is valid, the message has not been altered since it was sent.
A DKIM DNS record looks something like this:
selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."
DKIM strengths:
- Survives email forwarding — the signature travels with the message
- Verifies message integrity, not just the sender's IP
- Supports multiple selectors, so different services can each have their own signing key
DKIM limitations:
- More complex to set up than SPF — requires key generation and DNS configuration for each sending service
- Does not tell receiving servers what to do when a signature fails
- A missing or invalid signature does not necessarily mean the email is malicious — it could just be misconfigured
DMARC: The Policy Layer
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and adds two critical capabilities: policy enforcement and reporting.
DMARC answers the question: "What should a receiving mail server do when an email fails SPF and DKIM checks?"
Here is how it works:
- You publish a DMARC DNS record that specifies your policy:
none(monitor only),quarantine(send to spam), orreject(block entirely). - When a receiving server gets an email from your domain, it checks SPF and DKIM.
- DMARC requires alignment — the domain in the
Fromheader must match the domain used in SPF or DKIM. This closes the gap that SPF and DKIM leave open individually. - If the email fails both aligned SPF and aligned DKIM, the receiving server applies your DMARC policy.
- The receiving server sends aggregate reports back to you, showing authentication results for all email sent from your domain.
A DMARC record looks like this:
v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; pct=100
DMARC strengths:
- Enforces policy — you decide what happens to unauthenticated email
- Provides visibility through aggregate and forensic reports
- Closes the alignment gap by checking the
Fromheader domain - Enables BIMI (brand logo display in inboxes) when set to
quarantineorreject
DMARC limitations:
- Requires both SPF and DKIM to be in place first
- Moving from
nonetorejecttakes time and careful analysis of reports - Third-party senders must be properly configured to pass alignment
How They Work Together
Think of the three protocols as layers of a security system:
| Protocol | What It Checks | Analogy |
|---|---|---|
| SPF | Is the sender authorized? | A guest list at the door |
| DKIM | Is the message genuine? | A tamper-proof seal on an envelope |
| DMARC | What happens if checks fail? | The security policy that decides what to do with unauthorized visitors |
No single protocol is sufficient on its own:
- SPF alone can be bypassed because it does not check the
Fromheader users see. - DKIM alone does not tell receivers what to do when verification fails.
- DMARC alone cannot exist — it depends on SPF and DKIM to perform the actual checks.
Together, they create a robust authentication framework. SPF verifies the sending server. DKIM verifies the message integrity. DMARC enforces policy and provides reporting.
A Quick Implementation Checklist
If you are starting from scratch, here is the recommended order:
- Set up SPF — List all services that send email on behalf of your domain in a DNS TXT record.
- Set up DKIM — Generate signing keys for each sending service and publish the public keys in DNS.
- Publish a DMARC record at
p=none— Start in monitoring mode to collect data without affecting delivery. - Analyze your DMARC reports — Identify all legitimate senders and make sure they pass SPF and DKIM alignment.
- Tighten your DMARC policy — Move to
quarantine, thenrejectonce all legitimate email is properly authenticated.
The Bottom Line
SPF, DKIM, and DMARC are not competing standards — they are complementary layers that each solve a different piece of the email authentication puzzle. Implementing all three is the only way to fully protect your domain from spoofing and give receiving mail servers the information they need to make good decisions about your email.
Start with SPF and DKIM. Add DMARC for policy and visibility. Aim for p=reject.