SPF vs DKIM vs DMARC: The Difference, Explained in Plain English

SPF, DKIM and DMARC are three DNS records that get mentioned in the same breath, but they answer three different questions. Here is what each one actually checks, why passing one is not enough, and how DMARC ties the other two together.

If you have ever set up a sending domain, you have been told to "add SPF, DKIM and DMARC." Most guides then dump three DNS records on you without explaining what problem each one solves. That matters, because a domain can pass SPF and DKIM and still be trivially spoofable — and a domain with DMARC but broken alignment can silently lose real mail. Let's untangle them.

The one-line versions

	Question it answers	How it works	What it protects
SPF	"Is this server allowed to send for this domain?"	A DNS TXT record listing authorized sending IPs	The envelope (Return-Path) domain
DKIM	"Was this message really signed by the domain, and is it unmodified?"	A cryptographic signature in the headers, verified against a public key in DNS	The signing domain and message integrity
DMARC	"Does the domain the recipient sees match a passing SPF or DKIM domain — and what should happen if not?"	A DNS policy record plus daily XML reports from receivers	The visible `From:` address

SPF: a guest list for your domain

SPF (Sender Policy Framework) is a TXT record on your domain that lists which servers may send email on its behalf:

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

When a mail server receives a message, it looks at the domain in the Return-Path (the invisible bounce address, not the From: line you see), fetches that domain's SPF record, and checks whether the connecting IP is on the list. On the list: pass. Not on the list: fail or softfail, depending on your -all / ~all ending.

SPF has two famous weaknesses:

Forwarding breaks it. When a message is forwarded, the forwarding server's IP is not on your list, so SPF fails even though the message is genuine.
It never looks at the visible From address. A spammer can pass SPF for their-domain.com in the Return-Path while displaying yourbank.com in the From: header. Without DMARC, nothing connects the two.

You can inspect any domain's record with our free SPF checker.

DKIM: a tamper-proof wax seal

DKIM (DomainKeys Identified Mail) has your sending server sign each message with a private key. The signature — a DKIM-Signature: header — covers the body and selected headers. Receivers fetch the matching public key from your DNS (at selector._domainkey.yourdomain.com) and verify it.

A valid DKIM signature proves two things: the message was authorized by whoever controls that DNS record, and it was not modified in transit. Unlike SPF, DKIM usually survives forwarding, because the signature travels inside the message.

DKIM's blind spot is the same as SPF's: the signing domain does not have to match the visible From: address. A message can carry a perfectly valid DKIM signature for bulk-sender.net while displaying your domain to the recipient. Look up any selector with the free DKIM checker.

DMARC: the rule that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) closes exactly the gap the other two leave open. It adds one requirement called alignment: to pass DMARC, a message needs SPF or DKIM to pass for a domain that matches the visible From address.

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

The record does two jobs:

Policy (p=): tells receivers what to do with messages that fail — none (deliver, just report), quarantine (spam folder) or reject (refuse outright). Choosing between them is its own decision — see our guide to p=none vs quarantine vs reject.
Reporting (rua=): asks every major receiver to send you a daily XML summary of who used your domain and whether they passed. Reading those is covered in how to read DMARC reports.

Why "SPF pass" can still mean "DMARC fail"

This is the single most confusing result in DMARC reports. Suppose your marketing platform sends with Return-Path bounce.platform.com (their domain) and a DKIM signature for platform.com, while the From: shows you@yourdomain.com. SPF passes and DKIM passes — for their domains. Neither aligns with yourdomain.com, so DMARC fails and your policy is applied to your own newsletter. The fix is enabling the platform's custom DKIM domain (sometimes labeled "domain authentication"), so the signature aligns.

Why you need all three

SPF alone: spoofable via the From header, breaks on forwarding.
DKIM alone: spoofable via the From header; no policy, no visibility.
SPF + DKIM without DMARC: still spoofable — nothing checks the visible From, and you get zero reporting.
All three: receivers verify the address humans actually see, you tell them what to do with failures, and you receive daily evidence of every source using your domain.

Mailbox providers now treat this stack as table stakes: Google and Yahoo require DMARC (among other things) for bulk senders, and Microsoft has announced matching requirements for high-volume senders to Outlook — details in our bulk sender requirements guide.

See where your domain stands in 10 seconds

Our free DMARC checker reads a domain's DMARC, SPF and DKIM setup and explains it in plain English — no signup. And when the daily XML reports start arriving, PlainDMARC turns them into a weekly plain-English verdict per domain, white-labeled so agencies can forward it straight to clients.

Check a domain free Create your free account

Frequently asked questions

Do I need DKIM if I already have SPF?

Yes. SPF fails on forwarded mail and only checks the hidden Return-Path domain, so on its own it neither survives normal email behavior nor protects the address recipients see. DKIM survives forwarding and, combined with DMARC alignment, is what keeps genuine mail deliverable as you tighten policy.

Can I use DMARC without SPF or DKIM?

You can publish a DMARC record with neither, but every message will fail it, because DMARC passes only when SPF or DKIM passes with an aligned domain. In practice you set up SPF and DKIM first, publish DMARC at p=none to collect reports, then tighten the policy once reports show your real senders aligned.

Which matters more for DMARC: SPF or DKIM alignment?

DKIM alignment. Because SPF breaks whenever mail is forwarded, a domain relying on SPF alignment alone will see genuine messages fail DMARC in the wild. Aligned DKIM survives forwarding, so it is the result that lets you move to p=quarantine and p=reject safely. Keep SPF anyway — it is cheap, some receivers weigh it, and it covers senders that cannot sign.