SPF vs DKIM vs DMARC: Understanding Email Authentication

The Three Pillars of Email Authentication: SPF, DKIM, and DMARC

Email was designed in an era when trust was assumed. The Simple Mail Transfer Protocol (SMTP) has no built-in mechanism to verify that an email actually came from the domain it claims to be from. This fundamental design flaw enabled email spoofing, phishing, and spam to become epidemic.

Over time, the email industry developed three complementary protocols to solve this problem: SPF, DKIM, and DMARC. Together, they form a complete email authentication framework that protects your domain from spoofing and improves deliverability for your legitimate emails.

Quick Reference Table

Protocol | What It Does | What It Checks | DNS Record Type
---------|--------------|----------------|------------------
SPF      | Authorizes which IPs can send | Envelope sender (MAIL FROM) | TXT (v=spf1)
DKIM     | Cryptographically signs email | Headers + Body (via signature) | TXT (selector._domainkey)
DMARC    | Tells receivers what to do on failure | Alignment of From domain with SPF/DKIM | TXT (_dmarc)

SPF: Authorizing Sending Servers

Sender Policy Framework (SPF) is the oldest of the three protocols, first proposed in 2003. Its purpose is simple: publish a list of IP addresses and subnets that are authorized to send email for your domain.

How SPF Works

1. You publish an SPF record in your DNS (e.g., v=spf1 include:_spf.google.com -all).
2. When someone sends an email claiming to be from your domain, the receiving server checks your SPF record.
3. If the sending server's IP address matches your SPF record, the email passes SPF.
4. If not, the email fails SPF and may be rejected or sent to spam.

What SPF Does Well

• Prevents IP-based spoofing: Attackers can't use unauthorized servers to send email as your domain.
• Relatively simple to implement: Basic SPF records require just a few includes.
• Widely supported: Every major email provider supports SPF.

What SPF Does Poorly

• Breaks on email forwarding: When an email is forwarded, the forwarding server's IP may not be in your SPF record, causing legitimate forwarded emails to fail SPF.
• 10-DNS-lookup limit: Complex SPF records can exceed this limit, causing PermError failures.
• Only checks envelope sender: SPF doesn't check the "From" header that recipients see, creating a loophole for some spoofing techniques.

DKIM: Cryptographic Signatures That Survive Forwarding

DomainKeys Identified Mail (DKIM) solves SPF's biggest weakness: the forwarding problem. Instead of authorizing IP addresses, DKIM uses public-key cryptography to sign the email itself.

How DKIM Works

1. You generate a public/private key pair and publish the public key in your DNS (as a TXT record under a selector, e.g., google._domainkey.yourdomain.com).
2. Your mail server uses the private key to cryptographically sign outgoing emails (including headers and body).
3. The signature is added as a DKIM-Signature header.
4. The receiving server fetches your public key from DNS and verifies the signature.
5. If the signature verifies, the email passes DKIM—even if it was forwarded through multiple servers.

What DKIM Does Well

• Survives forwarding: Because the signature travels with the email, forwarding doesn't break DKIM (unless the forwarder modifies the email).
• Detects tampering: Any modification to signed headers or body invalidates the signature.
• No lookup limits: DKIM doesn't have SPF's 10-lookup limit.

What DKIM Does Poorly

• More complex to implement: Requires key generation, selector management, and key rotation.
• Requires sending server support: Your email provider must support DKIM signing (most do).
• Can be broken by modification: Antivirus gateways or mailing lists that modify emails break DKIM signatures.

DMARC: Policy, Alignment, and Reporting

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the newest of the three protocols (2015). It ties SPF and DKIM together, adds domain alignment checks, and provides reporting.

How DMARC Works

1. You publish a DMARC policy in your DNS (as a TXT record at _dmarc.yourdomain.com).
2. The policy specifies what receiving servers should do when an email fails authentication (p=none, p=quarantine, or p=reject).
3. You provide email addresses to receive aggregate and forensic reports (rua and ruf).
4. Receiving servers check SPF and DKIM, then check alignment: does the domain in the From header match the SPF or DKIM domain?
5. If SPF OR DKIM passes AND aligns, DMARC passes. Otherwise, DMARC fails, and the policy (p=) is applied.
6. Receiving servers send reports to your specified addresses.

Domain Alignment Explained

Alignment is DMARC's critical innovation. For SPF to align, the domain in the From header must match (or be a subdomain of) the domain in the envelope sender. For DKIM to align, the domain in the From header must match the domain in the DKIM signature's d= tag.

# Example of aligned SPF (domain.com)
From: user@domain.com
Envelope sender: user@domain.com → Aligned

# Example of misaligned SPF (domain.com vs otherdomain.com)
From: user@domain.com
Envelope sender: user@otherdomain.com → NOT aligned

DMARC Policy Levels

• p=none (Monitor): No action on failures. Receiving servers send reports but don't quarantine or reject. Use this to start.
• p=quarantine (Partial Protection): Failing emails are sent to spam folder.
• p=reject (Full Protection): Failing emails are rejected entirely. Recipients never see them.

How SPF, DKIM, and DMARC Work Together

Each protocol has strengths and weaknesses. Together, they form a complete defense.

The Email Authentication Flow

1. Email is sent from sender@yourdomain.com.
2. Sending server adds DKIM signature (if configured).
3. Recipient's server checks SPF against envelope sender.
4. Recipient's server checks DKIM signature.
5. Recipient's server checks DMARC record for your domain.
6. Recipient's server evaluates: Does SPF or DKIM pass? Does it align with the From domain?
7. If yes → DMARC pass → Email delivered normally.
8. If no → DMARC fail → Apply policy (none/quarantine/reject) and send report.

Example Scenarios

Scenario 1: All Three Working (Legitimate Email)

SPF: Pass (IP matches)
DKIM: Pass (signature verifies)
Alignment: SPF aligns (domain matches From)
DMARC: Pass → Email to inbox

Scenario 2: SPF Fails, DKIM Passes (Forwarded Email)

SPF: Fail (forwarding server IP not authorized)
DKIM: Pass (signature survives forwarding)
Alignment: DKIM aligns (domain matches From)
DMARC: Pass (DKIM pass is sufficient) → Email to inbox

Scenario 3: Both Pass, But Misaligned (Spoofing Attempt)

SPF: Pass (authorized server)
DKIM: Pass (valid signature)
Alignment: Neither aligns (SPF and DKIM domains don't match From)
DMARC: Fail → Apply policy (quarantine/reject)

Scenario 4: No Authentication (Typical Spoofing)

SPF: None (no SPF or PermError)
DKIM: None (no signature)
Alignment: N/A
DMARC: Fail → Apply policy

Implementation Order and Strategy: A Step-by-Step Plan

Implementing all three protocols at once is overwhelming. Follow this phased approach.

Phase 1: SPF (1-2 weeks)

Start with SPF. Identify all email sources, create your SPF record, publish it with ~all (SoftFail).

Check with our SPF Checker.

Phase 2: DKIM (2-4 weeks)

Configure DKIM signing for every email source (Google Workspace, SendGrid, etc.). Test signatures with our DKIM Checker.

Phase 3: DMARC with p=none (4-8 weeks)

Publish a DMARC record with p=none. Set up reporting (rua) to receive aggregate reports. Analyze reports for 30-60 days to identify any missing sources or alignment issues.

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

Phase 4: Address Issues Found in Reports (8-12 weeks)

Based on DMARC reports:

• Add any missing legitimate sources to SPF
• Configure DKIM for any sources missing signatures
• Fix any alignment issues

Phase 5: Move to p=quarantine (12-16 weeks)

Once reports show minimal unexpected failures, move to p=quarantine. Monitor for 30 days.

Phase 6: Move to p=reject (16-20 weeks)

If quarantine is successful, move to p=reject for full protection. Consider switching SPF to -all (Hard Fail) as well.