DMARC vs SPF vs DKIM: What's the Difference?

If you've started looking into email authentication, you've probably run into three acronyms: SPF, DKIM, and DMARC. They sound similar, they're often mentioned together, and it's not always clear why you need all three.

Here's the short version: SPF checks who's allowed to send email for your domain. DKIM proves an email hasn't been tampered with. DMARC ties them together with a policy that tells receiving servers what to do when checks fail.

Each solves a different piece of the email security puzzle. Let's break them down.

SPF: Who's Allowed to Send?

SPF (Sender Policy Framework) is a DNS record that lists the servers authorized to send email on behalf of your domain. When a receiving server gets an email claiming to be from yourcompany.com, it checks the SPF record to see if the sending server is on the list.

How SPF Works

1. You publish a TXT record in DNS listing your authorized mail servers
2. A receiving server gets an email from your domain
3. It looks up your SPF record and checks the sending server's IP against it
4. If the IP is listed, SPF passes. If not, it fails

Example SPF Record

v=spf1 include:_spf.google.com include:amazonses.com -all

This says: "Google Workspace and Amazon SES are authorized to send for my domain. Reject everything else."

What SPF Protects Against

• Unauthorized servers sending email as your domain
• Basic spoofing attempts where attackers use their own servers

SPF Limitations

• 10-lookup limit: SPF records can't exceed 10 DNS lookups, which becomes a problem when you have many third-party senders
• Forwarding breaks it: When an email is forwarded, the sending IP changes, so SPF fails
• Envelope vs. header: SPF checks the envelope sender (Return-Path), not the From header that users actually see—attackers can exploit this gap

DKIM: Is the Email Authentic?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing emails. The receiving server uses a public key published in your DNS to verify the signature hasn't been altered in transit.

How DKIM Works

1. Your mail server signs outgoing emails with a private key
2. The signature is added as a header in the email
3. The receiving server retrieves your public key from DNS
4. It verifies the signature matches the email content
5. If the signature is valid, DKIM passes

Example DKIM DNS Record

selector1._domainkey.yourcompany.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0G..."

What DKIM Protects Against

• Email tampering: Any change to the signed headers or body invalidates the signature
• Man-in-the-middle attacks: Interceptors can't modify the email without detection
• Replay with modification: Attackers can't take a legitimate email, change the content, and resend it

DKIM Limitations

• Doesn't prevent spoofing on its own: An attacker can sign emails with their own DKIM key while spoofing your From address
• Partial signing: Not all headers are always signed, leaving room for manipulation
• Key management: Private keys need to be rotated periodically and kept secure

DMARC: The Policy Layer

DMARC (Domain-based Message Authentication, Reporting & Conformance) builds on SPF and DKIM by adding two critical things: alignment checks and an enforcement policy.

Without DMARC, a message can pass SPF or DKIM but still be spoofed. DMARC closes this gap by requiring that the domain in the From header matches (aligns with) the domain authenticated by SPF or DKIM.

How DMARC Works

1. A receiving server gets an email and runs SPF and DKIM checks
2. DMARC then checks alignment—does the From header domain match the SPF or DKIM domain?
3. If alignment passes, the email is delivered
4. If alignment fails, the receiving server follows your DMARC policy (none, quarantine, or reject)
5. The receiving server sends you a report about the results

Example DMARC Record

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; pct=100

This says: "Reject 100% of emails that fail DMARC alignment, and send me aggregate reports."

What DMARC Adds

• Alignment enforcement: Closes the gap between what SPF/DKIM check and what users see in the From field
• Policy control: You decide whether failing emails are delivered, quarantined, or rejected
• Visibility: Aggregate and forensic reports show exactly who's sending email as your domain

How They Work Together

Think of email authentication like building security:

Layer	Analogy	What It Does
SPF	Guest list	Checks if the sender is authorized
DKIM	Tamper-proof seal	Proves the message wasn't altered
DMARC	Security policy	Enforces rules and reports violations

Here's what happens when an email arrives at a receiving server:

Incoming email from "you@yourcompany.com"
  │
  ├─ SPF Check: Is the sending server authorized?
  │   └─ Alignment: Does the envelope domain match the From domain?
  │
  ├─ DKIM Check: Is the signature valid?
  │   └─ Alignment: Does the signing domain match the From domain?
  │
  └─ DMARC Decision:
      ├─ Either SPF or DKIM passes with alignment → DELIVER
      └─ Both fail alignment → Apply policy (none / quarantine / reject)

An email only needs to pass one of the two checks (SPF or DKIM) with proper alignment to pass DMARC. But having both configured gives you redundancy—if forwarding breaks SPF, DKIM can still validate the message.

Why You Need All Three

It's tempting to think one protocol is enough. Here's why it's not:

SPF Alone

• Doesn't verify the From header users see
• Breaks when emails are forwarded
• Doesn't prevent content tampering

DKIM Alone

• Doesn't specify which servers can send
• Doesn't tell receivers what to do with failures
• An attacker can sign with their own key while spoofing your domain

SPF + DKIM Without DMARC

• No alignment requirement—authentication can pass even on spoofed emails
• No enforcement policy—receivers decide on their own what to do
• No reporting—you have zero visibility into who's using your domain

All Three Together

• SPF verifies the sending server
• DKIM verifies the message integrity
• DMARC ensures alignment, enforces your policy, and gives you reporting

This is why Google, Yahoo, and Microsoft now require all three for bulk senders.

Common Misconceptions

"DMARC replaces SPF and DKIM"

No. DMARC depends on SPF and DKIM. It's a policy layer on top, not a replacement.

"I only need SPF because I use Google Workspace"

Google Workspace configures DKIM for you, but you still need a DMARC record to enforce alignment and get reporting. Without DMARC, spoofed emails using your domain can still reach inboxes.

"DKIM alone prevents spoofing"

DKIM proves a message is authentic from the signing domain, but without DMARC alignment, an attacker can sign with their own domain while putting your address in the From field.

"Setting up all three is too complicated"

It used to be. But tools that automate DNS record management have eliminated most of the manual work, especially for common providers like Cloudflare and Route53.

Quick Comparison

	SPF	DKIM	DMARC
What it checks	Sending server IP	Message signature	Alignment + policy
DNS record type	TXT on domain	TXT on selector subdomain	TXT on _dmarc subdomain
Protects against	Unauthorized senders	Message tampering	Spoofing with policy enforcement
Works alone?	Partially	Partially	No (requires SPF and/or DKIM)
Provides reporting?	No	No	Yes
Survives forwarding?	No	Usually	Depends on SPF/DKIM result

Getting Started

If you haven't set up email authentication yet, here's the recommended order:

1. Configure SPF — List all services that send email for your domain
2. Enable DKIM — Most email providers offer this in their admin console
3. Publish a DMARC record — Start with p=none to monitor without affecting delivery
4. Review DMARC reports — Identify legitimate senders that fail authentication
5. Fix issues and enforce — Move to p=quarantine, then p=reject

The monitoring phase is critical. Jumping straight to enforcement without understanding your email ecosystem will block legitimate emails from third-party services you forgot about.

---

Want to skip the manual setup? BrightPost automates SPF, DKIM, and DMARC configuration with automatic DNS updates for Cloudflare and Route53. Check your domain's authentication status with our free scanner and get to full enforcement faster.