SPF, DKIM, DMARC Explained: The Three-Letter Email Authentication Stack

The Three Protocols, Briefly

Email authentication protocols SPF, DKIM, and DMARC each solve a piece of the spoofing problem:

Protocol	What it does	Where it lives
SPF	Lists authorized sending servers	DNS TXT record
DKIM	Cryptographically signs messages	DNS TXT (key) + message header (signature)
DMARC	Ties SPF/DKIM results to visible From: + sets policy	DNS TXT record at _dmarc.yourdomain.com

The complete email DNS records spf dkim dmarc trio is now table stakes — Gmail, Yahoo, and Microsoft all require it for bulk senders.

SPF: Sender Policy Framework

SPF publishes which servers can send mail for your domain. Receivers check the SPF record and verify the sending IP is authorized.

A typical SPF record:

v=spf1 include:_spf.google.com include:sendgrid.net -all

Strengths:

• Simple to publish
• Prevents many spoofing attacks
• Required by all major providers

Limitations:

• Checks envelope sender (Return-Path), not visible From:
• Breaks on forwarding
• Limited to 10 DNS lookups
• Doesn't sign anything cryptographically

DKIM: DomainKeys Identified Mail

DKIM cryptographically signs each outgoing message with a private key. Receivers fetch the matching public key from DNS and verify the signature.

Components:

• Private key: held by sending infrastructure
• Public key: published in DNS at selector._domainkey.yourdomain.com
• DKIM-Signature header: added to each message

Strengths:

• Survives forwarding (signature stays with message)
• Cryptographically tamper-proof
• Multiple selectors enable key rotation

Limitations:

• More complex to set up than SPF
• Body changes (mailing list footers, etc.) can invalidate signatures
• Requires DNS publication and ESP support

DMARC: The Policy Layer

DMARC sits on top of SPF and DKIM:

1. Checks that SPF or DKIM passed
2. Checks that the passing protocol aligns with the visible From: domain
3. Tells receivers what to do with failures (none, quarantine, reject)
4. Requests reports back to sender

A starting DMARC record:

v=DMARC1; p=none; rua=mailto:[email protected]

Without DMARC, SPF and DKIM each protect their own piece — but an attacker can pass SPF with their own domain and spoof your From:. DMARC closes that gap.

How They Work Together

When Gmail receives your email:

1. SPF check: Is the sending IP authorized? Yes/No.
2. DKIM check: Does the signature verify? Yes/No.
3. DMARC check: Does at least one of SPF/DKIM pass AND align with the visible From: domain?
4. Policy enforcement: If DMARC fails, apply the policy (none/quarantine/reject).

Both SPF and DKIM need to be set up properly for DMARC to work reliably. Most senders run both for redundancy: SPF for envelope-level protection, DKIM for content-level protection.

DKIM vs SPF vs DMARC: Which to Set Up First

Order: SPF → DKIM → DMARC. You can publish all three on day one if you control your sending infrastructure. For complex setups:

1. SPF first — fastest to publish, immediate impact
2. DKIM next — requires ESP coordination
3. DMARC at p=none — monitor reports before enforcing
4. Advance DMARC to p=quarantine then p=reject over 4-12 weeks

See DMARC setup guide for the full progression.

Common Mistakes

• Publishing SPF without DKIM (or vice versa) and assuming DMARC will protect you
• Hard-coding +all or ~all in SPF (should be -all)
• Not monitoring DMARC reports before advancing policy
• Forgetting to include third-party senders (SaaS tools, CRM, e-signature) in SPF
• DKIM signing with the wrong domain (breaks alignment)

How to Verify Everything Is Working

Send a test email to [email protected]. The report shows:

• SPF: pass/fail
• DKIM: pass/fail with selector
• DMARC: pass/fail with alignment status
• Suggested fixes

Or use MXToolbox: mxtoolbox.com/SuperTool.aspx → enter your domain.

For ongoing monitoring, set up a DMARC report processor like Mailhardener, dmarcian, or Google's free Postmaster Tools.

Practitioner note: The most common SPF DKIM DMARC explained-but-not-implemented pattern: senders publish SPF and DKIM, then publish DMARC at p=none — and never advance. p=none doesn't protect you from spoofing; it only monitors. Advance to p=quarantine within 6-8 weeks of clean reports, then to p=reject after another 4-8 weeks.

Practitioner note: When auditing client deliverability, I find unauthenticated third-party senders in roughly 90% of cases. The SaaS world has exploded — Calendly, Loom, ActiveCampaign, e-signature tools, ticketing systems — and each one sending under your domain needs SPF inclusion and DKIM. DMARC reports surface these instantly.

Practitioner note: Email authentication protocols SPF DKIM DMARC are necessary but not sufficient. They prevent spoofing and improve trust, but they don't fix list quality or content issues. Authentication is the foundation; list hygiene and engagement are the building. Both are required.

If you need help implementing or troubleshooting SPF, DKIM, and DMARC across multiple sending domains and third-party tools, book a consultation. I configure authentication stacks for senders ranging from 50K to 10M+ emails/month.

Sources

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM)
• RFC 7489: DMARC specification
• Google: SPF DKIM DMARC overview
• Microsoft: SPF DKIM DMARC overview official documentation

---

v1.0 · May 2026