SPF, DKIM, and DMARC Explained Simply (No Jargon)

Email authentication has three acronyms that get thrown around constantly: SPF, DKIM, and DMARC. They sound similar, but they each do a different job -- and understanding the difference makes it much easier to fix problems when your emails aren't landing.

Here's the analogy we find works best: think of your domain as a company, and every email as a letter it sends out.

SPF: the approved sender list

SPF (Sender Policy Framework) is like a list your company publishes saying "these are the only mailrooms authorized to send letters on our behalf." It's a single DNS TXT record listing IP addresses and services allowed to send email as your domain.

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

When an email arrives, the receiving server checks: "did this come from an IP on the sender's approved list?" If not, SPF fails.

Weakness on its own: SPF checks the sending server, not the actual message. It also breaks when email gets forwarded, since the forwarding server isn't on your approved list.

DKIM: the tamper-proof seal

DKIM (DomainKeys Identified Mail) is like a wax seal stamped on every letter, made with a private stamp only your company has. The receiving mailroom has a public copy of what a genuine seal looks like (published in DNS) and can verify the letter wasn't opened or altered in transit.

Technically, DKIM cryptographically signs parts of your email (headers and body) using a private key. The receiving server looks up your public key at a DNS record like:

selector1._domainkey.yourdomain.com

and verifies the signature matches.

Strength over SPF: DKIM survives forwarding, since the signature travels with the message itself rather than depending on which server relayed it.

DMARC: the policy that ties it together

Here's the part most people miss: SPF and DKIM don't tell receiving servers what to actually do if a message fails. That's DMARC's job.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is a policy statement published in DNS that says three things:

1. Alignment requirement -- the domain in SPF/DKIM must match the visible "From" domain, not just any authorized sender.
2. What to do on failure -- p=none (do nothing, just report), p=quarantine (send to spam), or p=reject (block entirely).
3. Where to send reports -- an rua= email address that receives daily aggregate XML reports showing every server that sent mail as your domain, and whether they passed or failed.

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

Why you need all three together

A domain with only SPF is fragile. A domain with SPF + DKIM but no DMARC has no enforcement -- spoofed mail using a different domain in the From header can still slip through, and you'll never know it's happening because there are no reports. All three together give you protection and visibility.

The 10-minute setup checklist

1. Publish an SPF record listing every service that sends mail for you, ending in -all (test it with the Free SPF Checker and stay under the 10-DNS-lookup limit).
2. Enable DKIM signing in your email provider (Google Workspace or Microsoft 365 setup guide) and verify the public key with the Free DKIM Checker.
3. Publish a DMARC record starting at p=none to collect DMARC aggregate (RUA) reports risk-free.
4. After a couple of weeks of clean reports, follow our DMARC rollout guide to move to p=quarantine, then p=reject.

See exactly where your domain stands

Rather than parsing raw DNS records yourself, run a free scan and get a plain-English breakdown of your SPF, DKIM, and DMARC setup with a 0-100 score.

Scan your domain for free →