The Complete Guide to Email Authentication: SPF, DKIM, and DMARC Explained

Quick check

See how your domain is currently configured with our free scanner.

Why Email Authentication Matters

Without proper authentication, anyone can send emails that appear to come from your domain. This is called email spoofing, and it's a favorite technique of phishers and spammers.

Email authentication solves this by:

Preventing spoofing — Only authorized servers can send as your domain
Improving deliverability — Authenticated emails are more likely to reach inboxes
Protecting your reputation — If someone spoofs your domain, it damages your sender reputation
Enabling reporting — You can see who's sending email as your domain

The three technologies that make this work are SPF, DKIM, and DMARC. Let's break each one down.

SPF: Who Can Send Email for You

SPF (Sender Policy Framework) is a DNS record that lists which servers are authorized to send email on behalf of your domain. When an email arrives, the receiving server checks if the sending server's IP address is on your approved list.

How SPF Works

You publish a TXT record listing authorized senders
Someone sends an email claiming to be from your domain
The receiving server looks up your SPF record
It checks if the sender's IP matches your authorized list
SPF passes or fails accordingly

Example SPF Record

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

v=spf1 — This is an SPF record (version 1)
include:_spf.google.com — Google Workspace servers are authorized
include:sendgrid.net — SendGrid servers are authorized
~all — Soft-fail emails from any other source

Common SPF Issues

Issue	Impact	Solution
No SPF record	Emails may be flagged as spam	Add an SPF record with your mail providers
Multiple SPF records	SPF fails completely (RFC violation)	Combine into a single record
Using +all	Anyone can spoof your domain	Change to ~all or -all
Too many DNS lookups (>10)	SPF fails with PermError	Flatten your record or reduce includes

DKIM: Digital Signatures for Email

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to your emails. This signature proves the email came from your domain and hasn't been modified in transit.

How DKIM Works

Your mail server signs outgoing emails with a private key
The signature is added to the email headers
You publish the corresponding public key in DNS
Receiving servers use the public key to verify the signature

Example DKIM Record

Published at google._domainkey.yourdomain.com:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...

Why DKIM Matters

Unlike SPF (which only checks the sending server), DKIM verifies the email content itself. Even if an email is forwarded through multiple servers, the DKIM signature stays intact, proving authenticity.

DMARC: Bringing It All Together

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together. It tells receiving servers what to do when an email fails authentication checks, and provides reporting so you can monitor authentication results.

How DMARC Works

You publish a DMARC policy in DNS
Email arrives claiming to be from your domain
Receiving server checks SPF and DKIM
Based on your DMARC policy, the email is accepted, quarantined (spam), or rejected
You receive reports about authentication results

Example DMARC Record

Published at _dmarc.yourdomain.com:

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

DMARC Policies Explained

Policy	Effect	When to Use
p=none	Monitor only, take no action	Starting out, building visibility
p=quarantine	Send to spam folder	After monitoring confirms legitimate sources
p=reject	Block the email entirely	Maximum protection, after thorough testing

The Safe Path to p=reject

Don't jump straight to p=reject. Here's the recommended rollout:

Start with p=none — Collect reports for 2-4 weeks
Move to p=quarantine with pct=10 — Test with 10% of traffic
Gradually increase pct — 25%, 50%, 100%
Move to p=reject with pct=10 — Start rejecting cautiously
Full p=reject — Maximum protection

How They Work Together

These three technologies form a defense-in-depth approach. For DMARC to pass, at least one of SPF or DKIM must pass AND align with the From domain.

Email Arrives

↓

SPF Check: Is the sender's IP authorized?

↓

DKIM Check: Is the signature valid?

↓

DMARC Check: What's the domain policy?

↓

Email Delivered / Quarantined / Rejected

Quick Setup Checklist

SPF

☐ One (and only one) SPF record exists
☐ All email services are included (Google, Microsoft, SendGrid, etc.)
☐ Record ends with ~all or -all
☐ DNS lookups are under 10

DKIM

☐ DKIM is enabled in your email provider
☐ Public key is published in DNS
☐ Key is not revoked (has actual content in p=)

DMARC

☐ DMARC record exists at _dmarc.yourdomain.com
☐ Policy is set (p=none, p=quarantine, or p=reject)
☐ Report address (rua=) is configured
☐ pct is not set to 0

Common Questions

Do I need all three (SPF, DKIM, DMARC)?

Yes, for maximum protection and deliverability. SPF and DKIM each solve different problems, and DMARC ties them together with policy enforcement and reporting.

What if I'm just using Gmail/Outlook for personal email?

If you're using @gmail.com or @outlook.com, Google and Microsoft handle authentication for you. This guide applies to custom domains (like @yourcompany.com).

How long do DNS changes take to propagate?

Typically a few hours, but can take up to 48 hours. Start with monitoring (p=none) while you wait.

Fix Guides

Verify your setup

Use our checker to confirm everything is configured correctly.