SPF, DKIM, and DMARC Explained (Email Authentication Guide)

The Three Pillars of Email Authentication

Email authentication is how you prove to receiving mail servers that your emails are legitimate — not spoofed, not forged, and actually sent by you. Three protocols work together to make this happen: SPF, DKIM, and DMARC.

Without authentication, anyone can send email claiming to be from your domain. ISPs know this, which is why unauthenticated email gets filtered, quarantined, or rejected outright.

Since late 2024, Google and Yahoo require all bulk senders to have SPF, DKIM, and DMARC configured. Microsoft followed in early 2025. This isn't optional anymore — it's table stakes for email deliverability.

SPF: Who's Allowed to Send

What SPF Does

Sender Policy Framework (SPF) publishes a list of IP addresses and servers authorized to send email on behalf of your domain. When a receiving server gets an email from you@yourdomain.com, it checks your domain's SPF record to verify the sending server is on the approved list.

How SPF Works

You publish a DNS TXT record listing your authorized senders
Someone sends an email "from" your domain
The receiving server looks up your SPF record
If the sending server's IP matches your SPF record, the check passes
If not, the email fails SPF

Setting Up SPF

Add a TXT record to your domain's DNS:

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

Breaking this down:

v=spf1 — Version identifier
include:_spf.google.com — Authorize Google Workspace
include:sendgrid.net — Authorize SendGrid
include:mailchimp.com — Authorize Mailchimp
-all — Reject everything else (strict). Use ~all for soft fail during testing.

SPF Limitations

10 DNS lookup limit — Each include: triggers a lookup. Complex setups hit this quickly.
Forwarding breaks SPF — When emails are forwarded, the sending IP changes but the "from" domain doesn't, causing SPF failures.
Only checks the envelope sender — Not the "From" header that users see.

DKIM: Is the Email Tampered?

What DKIM Does

DomainKeys Identified Mail (DKIM) adds a cryptographic signature to every email you send. The receiving server uses your public key (published in DNS) to verify the signature. If the email was modified in transit, the signature won't match.

How DKIM Works

Your email server generates a public/private key pair
You publish the public key as a DNS TXT record
When sending, your server signs the email headers and body with the private key
The receiving server retrieves your public key from DNS
It verifies the signature — if valid, the email hasn't been tampered with

Setting Up DKIM

Most ESPs handle DKIM key generation. You typically add a CNAME or TXT record:

selector._domainkey.yourdomain.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The selector is provider-specific — Google uses google, SendGrid uses s1 and s2, etc. Your ESP's documentation will give you the exact records.

DKIM Best Practices

Use 2048-bit keys (1024-bit is considered weak)
Rotate keys annually
Sign both headers and body
Don't over-sign — stick to critical headers (From, To, Subject, Date)

DMARC: What Happens When Checks Fail

What DMARC Does

Domain-based Message Authentication, Reporting, and Conformance (DMARC) ties SPF and DKIM together and tells receiving servers what to do when authentication fails. It also provides reporting so you can see who's sending email as your domain.

How DMARC Works

You publish a DMARC policy in DNS
An email arrives claiming to be from your domain
The receiving server checks SPF and DKIM
If both fail, DMARC tells the server what to do: nothing (none), quarantine, or reject
The receiving server sends you aggregate reports about pass/fail rates

DMARC Policies

| Policy | DNS Value | Effect | |--------|-----------|--------| | Monitor | p=none | No action on failures, just reports | | Quarantine | p=quarantine | Failed emails go to spam | | Reject | p=reject | Failed emails are blocked entirely |

Setting Up DMARC

Start with monitoring, then tighten over time:

Week 1-4: Monitor

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; pct=100"

Month 2-3: Quarantine

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

Month 4+: Reject

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; pct=100"

DMARC Alignment

DMARC requires "alignment" — the domain in the "From" header must match the domain authenticated by SPF or DKIM:

SPF alignment: The Return-Path domain matches the From domain
DKIM alignment: The DKIM signing domain matches the From domain

At least one must align for DMARC to pass.

How They Work Together

Think of it as a three-layer security system:

SPF = "This server is authorized to send for us" (identity)
DKIM = "This email hasn't been tampered with" (integrity)
DMARC = "If SPF and DKIM both fail, here's what to do" (policy)

An email passes DMARC if either SPF or DKIM passes with alignment. Both don't need to pass — but having both configured provides redundancy.

Testing Your Setup

Free Testing Tools

MXToolbox — mxtoolbox.com/spf.aspx for SPF, DKIM, and DMARC lookups
mail-tester.com — Send a test email and get a score with specific fix suggestions
Google Admin Toolbox — toolbox.googleapps.com/apps/checkmx/ for Google-specific checks
DMARC Analyzer — Parse your DMARC aggregate reports into readable dashboards

Quick DNS Checks

Check your records are published correctly:

# Check SPF
dig +short TXT yourdomain.com | grep spf

# Check DKIM (replace 'google' with your selector)
dig +short TXT google._domainkey.yourdomain.com

# Check DMARC
dig +short TXT _dmarc.yourdomain.com

Common Mistakes

SPF Mistakes

Too many DNS lookups — Exceeding the 10-lookup limit causes SPF to permanently fail
Using +all — This authorizes everyone, defeating the purpose entirely
Forgetting third-party senders — Each service that sends on your behalf needs an include:

DKIM Mistakes

Using 1024-bit keys — Upgrade to 2048-bit
Not rotating keys — Compromised keys mean anyone can sign as you
Wrong selector — The selector in DNS must match what your email server uses

DMARC Mistakes

Jumping straight to p=reject — Start with p=none to monitor, or you'll block legitimate email
Ignoring aggregate reports — The reports show you unauthorized senders you didn't know about
Not setting up rua — Without a reporting address, you're flying blind

Authentication's Impact on Deliverability

Proper authentication doesn't guarantee inbox placement, but missing authentication nearly guarantees spam folder placement. Here's what the data shows:

Emails with SPF + DKIM + DMARC have 10-15% higher inbox placement than unauthenticated email
Google's 2024 bulk sender requirements mean unauthenticated email from high-volume senders is rejected outright
DMARC p=reject protects your domain from phishing, which ISPs reward with higher trust scores

Authentication is step one. List verification and engagement optimization are the other pieces of the deliverability puzzle.

Action Plan

Check your current setup — Use MXToolbox to audit SPF, DKIM, and DMARC
Fix gaps — Add missing records, ensure all senders are authorized in SPF
Start DMARC at p=none — Monitor for 4 weeks before tightening
Review DMARC reports — Look for unauthorized senders and fix alignment issues
Tighten to p=reject — Once you're confident all legitimate senders pass
Verify your list — Authentication protects your domain; list verification protects your reputation