SPF vs DKIM vs DMARC: what each one proves, and what it doesn't

Email was designed without any way to prove who sent a message. SPF, DKIM and DMARC were added later, each covering a different gap. Together they let a receiver answer: "Did this message really come from the domain in the From line?"

They don't answer: "Is this message safe?" or "Did the person want it?"

How do SPF, DKIM and DMARC compare?

SPF: was this server allowed to send?

SPF lists the IP addresses allowed to send mail using your domain in the envelope sender: the hidden bounce address, not the From line people read.

It proves: the connecting server was on the list published by the envelope domain.

It doesn't prove:

• Anything about the From address the reader sees. A spammer can use their own envelope domain, pass SPF, and put your name in From.
• That the message wasn't changed.
• Much after forwarding, because the forwarder's IP isn't on your list.

SPF also has a hard limit of 10 DNS-querying mechanisms. Exceed it and the result is PermError. See how to fix too many SPF lookups, or start with what SPF is and how receivers check it.

DKIM: did this domain sign this message?

DKIM adds a DKIM-Signature header made with a private key. The receiver fetches the public key from DNS and verifies it.

It proves: the domain in d= took responsibility for the message, and the signed headers and body weren't altered since signing.

It doesn't prove:

• That the signing domain is the one in From. Any domain can sign any message.
• That the content is honest. A compromised account produces perfectly signed phishing.
• That the message wasn't replayed. A validly signed message can be resent to other people.

An unknown DKIM selector isn't a failure. Selectors are names the sender chooses, and DNS can't list them. For the signature tags, keys and what breaks them, see what DKIM is and how it works.

DMARC: does the authenticated domain match the From line?

DMARC closes the gap. A message passes when SPF or DKIM passes for a domain aligned with the From domain. You publish a policy saying what receivers should do with mail that fails, and where to send reports. Our guide to what DMARC is covers the policy and its reports in more depth.

It proves: the visible From domain authorized this message through SPF or DKIM.

It doesn't prove:

• That the message is safe. Attackers authenticate their own domains.
• Anything about look-alike domains (examp1e.com, example-billing.com).
• That receivers will follow your policy. They make the final decision.

RFC 9989 removed the pct tag, added t (test mode) and np (policy for non-existent subdomains), and replaced public suffix list lookups with a DNS tree walk for finding the organizational domain. Existing v=DMARC1 records still work.

How do SPF, DKIM and DMARC work together?

1. Your invoicing tool sends an invoice from billing@example.com, using bounces.invoicetool.example as the envelope sender, signed with d=example.com.
2. SPF: passes for bounces.invoicetool.example. Not aligned with example.com.
3. DKIM: passes for example.com. Aligned.
4. DMARC: passes, because DKIM passed with alignment.

Now remove the custom DKIM. DKIM passes only for invoicetool.example, SPF still isn't aligned, and DMARC fails. At p=reject, your invoices bounce.

What else appears in the same checks?

These aren't authentication, but they appear in the same checks:

What do people get wrong about SPF, DKIM and DMARC?

"We have SPF, so nobody can spoof us." SPF checks the envelope sender, which readers never see. Without DMARC at enforcement, an attacker can use their own envelope domain, pass SPF for it, and put your domain in the visible From line.

"DKIM encrypts our email." It doesn't. DKIM signs messages; anyone along the way can still read them. Encryption in transit is TLS, which MTA-STS helps enforce.

"p=reject will block our own mail." Only mail that fails both aligned SPF and aligned DKIM. If you've read your reports and fixed your senders first, legitimate mail keeps flowing. The risk comes from skipping the monitoring stage, not from the policy itself.

"DMARC stops phishing." It stops one kind: exact-domain spoofing at receivers that enforce it. Look-alike domains, display-name tricks ("IT Support" random@freemail.example) and compromised real accounts all pass or bypass it.

"An unknown DKIM selector means DKIM is broken." Selectors are names the sender chooses and can't be listed from DNS. If a checker can't guess yours, enter the s= value from a real message header.

"A domain with no MX is misconfigured." Not if it doesn't receive mail. It should say so with a Null MX record, MX 0 ., plus v=spf1 -all and a p=reject DMARC policy, so nobody can send as it either.

"We only need this if we send newsletters." Every domain that sends any email benefits. Gmail requires SPF or DKIM from all senders, not just bulk ones, according to Google's sender guidelines.

What do receivers do with the results?

The standards say what to check, not exactly what to do. Each receiver combines the results with its own signals. A failed SPF check under ~all is usually just one negative signal. A DMARC failure under p=reject is a strong instruction that most large receivers follow, though they may make exceptions, for example for mailing lists that carry trustworthy ARC results. A full pass is a positive signal, but content and reputation filtering still decide whether the message reaches the inbox, the junk folder or quarantine.

In what order should you set them up?

1. Inventory your senders. Every service that sends with your domain in From.
2. Publish SPF listing your mail platform and any outbound relay. One record only.
3. Enable DKIM with your domain in every service. Prefer 2048-bit keys.
4. Publish DMARC at p=none with a rua address.
5. Read the reports, fix gaps, then move toward p=reject. Our staged DMARC rollout has the detail.
6. Add MTA-STS and TLS-RPT for transport security.

How iBlockSpam helps

Our free checkers test each record: SPF, DKIM, DMARC, and all of them together in the Email Health Check. For mail you receive, iBlockSpam adds spam, virus, malware, phishing and spoofing protection at the MX. That matters because passing authentication doesn't make a message safe.

Next steps

1. Check all three records at once with the free Email Health Check.
2. Fix SPF and DKIM for every sending service, then publish DMARC at p=none with the DMARC Record Generator.
3. Move toward enforcement with DMARC from none to reject.

If you'd rather not read aggregate reports yourself, iBlockSpam's DMARC monitoring shows which of your senders pass SPF, DKIM and DMARC, and it's included in both plans on our pricing page.

Browse our other SPF, DKIM and DMARC guides.