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

Three Protocols, One Goal

SPF, DKIM, and DMARC are three separate email authentication protocols that work together to prevent email spoofing and improve deliverability. Each serves a distinct purpose, and you need all three for complete protection. Here's a quick summary before we dive deep:

Protocol	What It Does	How It Works	Protects Against
SPF	Declares which servers can send email for your domain	DNS TXT record listing authorized IPs	Unauthorized servers sending as your domain
DKIM	Cryptographically signs email messages	Public/private key pair; signature in email header	Message tampering in transit
DMARC	Ties SPF and DKIM together with a policy	DNS TXT record specifying policy + alignment	Domain spoofing in the visible "From" address

SPF: The IP Allowlist

Sender Policy Framework (SPF) is the simplest of the three to understand. It's essentially a list of IP addresses and third-party services that are permitted to send email on behalf of your domain.

How SPF Works

1. You publish a TXT record in your DNS: v=spf1 include:_spf.google.com -all
2. A receiving server gets an email claiming to be from your domain
3. The server checks the connecting IP address against your SPF record
4. If the IP is authorized → SPF passes. If not → SPF fails.

What SPF Checks

SPF validates the envelope sender (the Return-Path or MAIL FROM address), not the "From" header that recipients see. This is an important distinction. An attacker can fail SPF on the envelope but still display your domain in the visible From header. This is exactly the gap that DMARC fills.

SPF Limitations

• 10 DNS lookup limit: Complex SPF records with many includes can exceed this and break entirely
• Forwarding breaks SPF: When email is forwarded, the forwarding server's IP isn't in your SPF record, so SPF fails
• Only checks envelope sender: Doesn't protect the visible From header on its own

Check your SPF record →

DKIM: The Digital Signature

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to your outgoing emails. The receiving server can verify this signature to confirm the message hasn't been tampered with and that it was authorized by the domain owner.

How DKIM Works

1. Your email server has a private key used to sign outgoing messages
2. The corresponding public key is published as a DNS TXT record at selector._domainkey.yourdomain.com
3. When sending, your server generates a hash of specified email headers and the body, encrypts it with the private key, and adds it as a DKIM-Signature header
4. The receiving server retrieves the public key from DNS, decrypts the signature, and compares the hash
5. If the hashes match → DKIM passes. If not → DKIM fails (message was altered or not signed by the key owner).

What a DKIM Signature Looks Like

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.com; s=google;
  h=from:to:subject:date:message-id;
  bh=base64encodedBodyHash;
  b=base64encodedSignature

Key fields: d= is the signing domain, s= is the selector (used to look up the public key), h= lists the signed headers, and b= is the actual signature.

DKIM Strengths

• Survives forwarding: Unlike SPF, DKIM signatures remain valid when email is forwarded because the signature is part of the message itself
• Proves message integrity: Detects if the email was modified after sending
• Supports multiple signers: Different services can sign with different selectors

DKIM Limitations

• Doesn't specify a policy: DKIM alone doesn't tell receivers what to do when verification fails
• Mailing lists can break it: Lists that modify subject lines or add footers invalidate the signature
• Key management complexity: Rotating keys, managing selectors across multiple services

Check your DKIM records →

DMARC: The Policy Layer

Domain-based Message Authentication, Reporting & Conformance (DMARC) builds on top of SPF and DKIM. It adds two critical capabilities: alignment checking and policy enforcement.

How DMARC Works

1. You publish a TXT record at _dmarc.yourdomain.com: v=DMARC1; p=reject; rua=mailto:[email protected];
2. A receiving server checks SPF and DKIM as usual
3. DMARC then checks alignment: does the domain that passed SPF or DKIM match the visible "From" domain?
4. If alignment passes → DMARC passes. If not → the server applies your policy (none, quarantine, or reject).
5. The server sends aggregate reports to the address in your rua tag

Why Alignment Matters

This is the key concept. Without DMARC, an attacker could:

• Set up their own server with valid SPF for evil.com
• Send email where the envelope is evil.com but the visible From is yourcompany.com
• SPF passes (for evil.com), but the recipient sees yourcompany.com

DMARC catches this because the SPF-authenticated domain (evil.com) doesn't align with the From domain (yourcompany.com). For our detailed guide on DMARC, see What is DMARC? The Complete Guide.

Check your DMARC policy →

How They Work Together

Think of the three protocols as layers:

1. SPF verifies the sending server is authorized (IP-level check)
2. DKIM verifies the message is authentic and unaltered (cryptographic check)
3. DMARC enforces a policy based on alignment of either SPF or DKIM with the visible From domain (identity check)

A message passes DMARC if either:

• SPF passes AND the SPF domain aligns with the From domain, OR
• DKIM passes AND the DKIM signing domain aligns with the From domain

You don't need both to pass, just one with alignment. However, configuring both SPF and DKIM gives you redundancy. SPF can break during forwarding, but DKIM survives. DKIM can break when mailing lists modify content, but SPF may still pass. Having both means DMARC is more resilient.

Which Should You Set Up First?

The recommended order is:

1. SPF first. It's the simplest to implement: a single DNS TXT record. Most email providers give you the exact record to add. See our SPF setup guide.
2. DKIM second. This requires configuration in your email provider's admin panel (to enable signing) and publishing the public key in DNS. It's more involved than SPF but still straightforward with modern providers.
3. DMARC last. DMARC depends on SPF and DKIM being in place. Start with p=none to collect reports, then gradually move to enforcement. See our DMARC guide for the full process.

Common Misconceptions

"I have SPF, so I don't need DKIM or DMARC"

SPF alone only checks the envelope sender, not the visible From address. Without DMARC, an attacker can still spoof your domain in the From header. And SPF breaks during email forwarding, so DKIM is the backup that survives forwarding. You need all three.

"DMARC replaces SPF and DKIM"

DMARC doesn't replace anything. It sits on top. Without SPF and DKIM, DMARC has nothing to check alignment against. You must have at least one (ideally both) of SPF and DKIM before DMARC can do anything useful.

"p=none means DMARC is working"

A p=none policy tells receivers to take no action on failing messages; it only generates reports. While it's a necessary first step, it doesn't actually protect your domain. Your domain is only protected when you move to p=quarantine or p=reject.

"SPF's 10-lookup limit is per query"

The 10-lookup limit is total across all nested includes. If your record includes Google (_spf.google.com) which itself includes 3 other domains, those all count toward your 10. Use our SPF checker to see your actual lookup count including nested records.

"DKIM key size doesn't matter"

It does. 1024-bit DKIM keys are considered the minimum, and 2048-bit keys are now the standard recommendation. Google Workspace defaults to 2048-bit. If you're still using 1024-bit keys, rotate to 2048-bit. The security improvement is significant and the performance cost is negligible.

"Email authentication stops all phishing"

SPF, DKIM, and DMARC prevent exact domain spoofing, meaning someone sending email as @yourcompany.com. They don't prevent lookalike domains (@your-company.com, @yourcompany.co) or display name spoofing. Full phishing protection requires additional measures like domain monitoring and user training.

Check All Three at Once

Wondering where your domain stands? Our free domain security scanner checks your SPF, DKIM, and DMARC records simultaneously, identifies misconfigurations, and gives you specific recommendations. It also checks SSL/TLS, DNSSEC, and security headers for a complete picture of your domain's security posture.

Scan your domain now →