SPF vs DKIM vs DMARC: What Each One Actually Does

Published June 3, 2026 · 6 min read · spFlat! Blog

If you've ever set up email authentication for a domain, you've come across three acronyms: SPF, DKIM, and DMARC. They're often mentioned in the same breath, but they do fundamentally different things.

The confusion is understandable. They all live in DNS, they all protect your email reputation, and they all need to work together. But confusing one for another is like confusing a lock, a key, and a security camera - they work as a system, but they're not the same thing.

Here's what each one actually does, in plain language.

The Short Version

You need at least SPF or DKIM passing for DMARC to work. And if you want reliable email delivery, you need all three.

SPF: The Visitor List

Sender Policy Framework is a DNS record that lists which IP addresses are allowed to send email for your domain. It's the oldest of the three (RFC 4408, 2006) and the most straightforward.

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

When a receiving server gets an email claiming to be from yourdomain.com, it looks up your SPF record and checks if the sending server's IP is on the list.

What SPF does well:

• Stops simple domain spoofing
• Fast to check - receivers can reject at the SMTP level
• Well-understood and widely supported

What SPF does not do:

• It does not sign or encrypt the message
• It does not prevent a legitimate sender's email from being forwarded and then failing (this is called "SPF breakage on forward")
• It does not tell receivers what to do when the check fails

DKIM: The Wax Seal

DomainKeys Identified Mail uses public-key cryptography to sign your outgoing emails. You generate a key pair, put the public key in a DNS record (selector._domainkey.yourdomain.com), and your mail server signs each outgoing message with the private key.

default._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."

When a receiver gets your email, it looks up the public key in your DNS, decrypts the signature, and checks if the message body and headers match. If they do, the email is DKIM-verified.

What DKIM does well:

• Proves the email wasn't altered in transit
• Survives email forwarding (SPF breaks, DKIM doesn't)
• Provides a cryptographic layer SPF can't match

What DKIM does not do:

• It does not verify the sender - only the signature. An attacker can set up DKIM for their own domain and sign emails that still claim to be from yours (though they'd fail DMARC alignment)
• It does not prevent someone from sending unsigned email using your domain
• It does not tell receivers what to do on failure

DMARC: The Policy Maker

Domain-based Message Authentication, Reporting & Conformance is the layer that sits on top of SPF and DKIM. It tells receiving mail servers: "If an email claiming to be from my domain fails SPF and DKIM, here's what you should do with it."

v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100

DMARC also introduces the concept of alignment: even if SPF or DKIM pass individually, the domain in the From: header must align with the domain used in the SPF check or DKIM signature. This prevents a sophisticated attack where someone sends from yourdomain.com using their own authenticated server.

Three DMARC policies:

• p=none - monitor only. No action taken. Used for gathering data before enforcing
• p=quarantine - mark failing emails as spam
• p=reject - reject failing emails outright. The strongest policy

What DMARC does well:

• Gives you control over how receivers handle unauthenticated email
• Provides daily/weekly reports (rua) showing who's sending email using your domain
• Essential for brand protection against exact-domain spoofing

What DMARC does not do:

• It does not authenticate email itself - it relies on SPF and DKIM results
• It does not fix broken SPF or DKIM configurations
• It does not help if SPF PermErrors silently invalidate your SPF checks

How they work together

Think of it as a three-layer system:

1. SPF checks who sent it (server IP)
2. DKIM checks what was sent (message integrity)
3. DMARC decides what to do when something's wrong

For DMARC to pass, an email needs at least one of SPF or DKIM to pass and be aligned with the domain in the From: header.

This is why you sometimes see emails pass DMARC even when SPF fails - DKIM was valid and aligned, which is enough. And conversely, an email can pass SPF but fail DMARC if there's no DKIM signature and the SPF domain doesn't align with the From: domain.

The most common mistakes

1. SPF is broken but you don't know it.
   This happens constantly. The record validates syntactically, so DNS tools report "OK", but nested includes push it past 10 lookups. Every SPF check returns PermError. Your DMARC reports show a shocking amount of SPF-fail mail you never knew about.
2. DMARC at p=reject with no monitoring.
   If you flip to reject before confirming all your legitimate senders pass authentication, you will silently lose email. Start at p=none, read your reports, then step up.
3. DKIM selector rot.
   DKIM keys can expire or get rotated without updating your DNS. A selector that worked last year may return NXDOMAIN today, breaking DKIM verification for any email still signed with the old key.
4. Third-party senders not covered.
   You set up DMARC for your domain, but your CRM sends marketing email through a different subdomain with no SPF or DKIM. Those emails fail authentication entirely.

Where to start

If you're setting this up for the first time or auditing an existing configuration:

1. Check your SPF record - get the full lookup count including nested includes
2. Verify DKIM is publishing correctly for each email service you use
3. Start DMARC at p=none with a report address (rua) you actually check
4. Review reports for 2-4 weeks before moving to p=quarantine or p=reject
5. Monitor continuously - provider IP changes, key rotations, and new services all affect your authentication chain