SPF, DKIM and DMARC explained: what each one proves, and why you need all three

Q: How can I see SPF, DKIM and DMARC results for a real message?

Open the message's raw source and read the Authentication-Results header, or paste the source into our email header analyzer for a decoded verdict per mechanism. Treat the three records as one system — SPF and DKIM generate proofs, DMARC connects them to the identity recipients see and reports back. Check where your domain stands right now with the email authentication checker; whatever it flags is your first fix.

2026-08-20

Three TXT records, published in DNS for a domain that sends mail:

example.com                    TXT  "v=spf1 include:_spf.espmail.net ip4:203.0.113.25 ~all"
s1._domainkey.example.com      TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."
_dmarc.example.com             TXT  "v=DMARC1; p=quarantine; rua=mailto:reports@example.com"

Together these are email authentication: the machinery that lets a receiving server decide whether a message claiming to come from example.com really did. Each record answers a question the other two can't, which is why the answer to "do I need all three?" is yes and has been since Gmail and Yahoo wrote all three into their bulk sender requirements.

This guide explains what each protocol proves, where each one breaks, and how DMARC ties the other two into something enforceable. When you want the deeper single-topic treatments, the glossary entries for SPF, DKIM and DMARC go further into each.

The problem all three exist to solve

SMTP, the protocol that moves email, was designed in an era when the network was small and trusted. It contains no built-in way to verify a sender's identity — any server can transmit a message claiming to be From: billing@yourbank.com, and the receiving server has no protocol-level reason to doubt it.

Everything about modern email filtering flows from that gap. Receivers had to invent identity verification after the fact, in layers, using the one system every domain owner already controls: DNS. If you can publish records under example.com, you can prove things about mail sent as example.com.

One more piece of background makes the rest click. Every email has two sender addresses: the envelope sender (called the return-path or MAIL FROM), used by servers for routing and bounces, and the From: header, which is what the recipient sees. They frequently differ, and legitimately so — an ESP sending your newsletter typically uses its own bounce domain in the envelope. Which address each protocol checks turns out to be the crux of the whole system.

SPF: an allowlist of sending servers

SPF (Sender Policy Framework, RFC 7208) lets a domain publish the list of servers authorized to send mail on its behalf. The receiver takes the connecting server's IP address, looks up the SPF record of the envelope sender's domain, and checks whether that IP appears in the list.

Reading the example record above: mail may come from anything _spf.espmail.net authorizes (your ESP's ranges, pulled in by include:), or from the IP 203.0.113.25 (say, your own mail server). The ~all at the end means "everything else should soft-fail" — suspicious, but not an instruction to reject outright.

SPF is simple, old and everywhere, and it has two structural weaknesses. First, it validates the envelope sender, not the From: header the human sees — so an SPF pass proves nothing about the visible identity. Second, it breaks on forwarding: when a message is forwarded, the forwarder's server becomes the connecting IP, which your record never authorized. There's also an operational trap — the specification caps SPF evaluation at 10 DNS lookups, and nested include: chains from multiple services blow past it surprisingly easily, invalidating the whole record. The SPF checker counts your lookups and flags this before a receiver does.

DKIM: a cryptographic signature that travels with the message

DKIM (DomainKeys Identified Mail, RFC 6376) takes a different approach. Instead of validating the transport path, the sending server signs selected headers and the body with a private key, and puts the signature in a DKIM-Signature: header. The matching public key is published in DNS — that's the s1._domainkey record above, where s1 is the selector, letting one domain hold many keys.

The receiver fetches the public key and verifies the signature. A valid signature proves two things at once: the message was authorized by whoever holds the signing domain's key, and the signed content wasn't modified in transit.

Because the signature lives inside the message rather than depending on which server delivered it, DKIM survives forwarding — the scenario that breaks SPF. Its weak points are operational instead: keys that never get rotated, and platforms that sign with their domain rather than yours. That last one matters more than it looks — a signature from espmail.net on your newsletter is valid, but it proves the ESP's identity, not example.com's. Whether your mail carries your own d= domain is checkable in seconds with the DKIM checker once you know your selector.

DMARC: the layer that makes the other two mean something

Here is the uncomfortable fact about SPF and DKIM on their own: a message can pass both and still be a spoof of your domain. Pass SPF for bounce.attacker.net, carry a valid DKIM signature for attacker.net, and display From: ceo@example.com — both checks succeed, and neither ever looked at the address the recipient sees.

DMARC (RFC 7489) closes that hole with one concept: alignment. To pass DMARC, a message needs at least one of SPF or DKIM to pass and the domain that passed must match the From: header domain. Alignment is what finally connects the cryptographic and path-based checks to the identity a human actually sees.

DMARC adds two more things neither predecessor has. A policy: the p= tag tells receivers what to do with failing mail — none (deliver, but report), quarantine (spam folder) or reject. And reporting: the rua= address receives aggregate XML summaries from receivers describing everything sent under your name, which is the only free receiver-side view of your authentication health that exists.

What DMARC policy to pick and how to ratchet it up safely is its own topic, as is the step-by-step deployment.

SPF vs DKIM vs DMARC at a glance

| | SPF | DKIM | DMARC | |---|---|---|---| | Proves | Sending IP is authorized | Message signed and unmodified | Passing domain matches visible From | | Checks which identity | Envelope sender (return-path) | Signing domain (d=) | From: header | | Survives forwarding | No | Usually | Via the DKIM path | | Tells receivers what to do on failure | No | No | Yes (p=) | | Sends you reports | No | No | Yes (rua=) | | DNS record | TXT at the domain root | TXT at selector._domainkey | TXT at _dmarc |

Two comparisons come up constantly and deserve direct answers.

SPF vs DKIM is not a choice — they fail in opposite situations. SPF dies on forwarding; DKIM survives it. DKIM breaks when content is modified in transit (some mailing lists); SPF doesn't care about content. Deploying both means a legitimate message almost always has at least one valid pass for DMARC to align.

DKIM vs DMARC confuses people because both involve the sending domain. The distinction: DKIM is evidence, DMARC is judgment. DKIM produces a verified fact ("espmail.net signed this"); DMARC decides whether that fact is relevant ("does the signer match the From domain?") and what happens if not. DKIM without DMARC is testimony no one is required to weigh.

How the three interlock in practice

For a well-configured sender using an ESP, a single delivered message looks like this: the envelope sender is bounce.example.com (a subdomain delegated to the ESP), so SPF passes and aligns in relaxed mode. The DKIM signature carries d=example.com because you added the ESP's CNAME records for custom signing. DMARC finds two aligned passes where it needs one, your p=quarantine policy never fires, and the receiver's Authentication-Results header reads spf=pass dkim=pass dmarc=pass.

Remove any layer and something degrades. Without SPF, one aligned path is gone and every DKIM hiccup becomes a DMARC failure. Without aligned DKIM, every forwarded message fails. Without DMARC, the other two verify identities no recipient ever sees — and you get no reports, no policy, and reduced standing under the bulk sender rules.

One boundary worth stating plainly: authentication proves identity, not virtue. A spammer with perfect SPF, DKIM and DMARC is still a spammer, and filters still weigh reputation and engagement on top. Passing all three removes a reason to distrust you; it doesn't create a reason to inbox you.

Related guides

Email authentication checker — test SPF, DKIM and DMARC for your domain in one pass
SPF checker — syntax validation plus the 10-lookup count
DKIM checker — verify a selector's public key
DMARC checker — policy and tag validation
SPF record — the mechanism in depth
DKIM — selectors, keys and signing
DMARC — policy, alignment and reports
Email authentication overview — the wider context, including BIMI and ARC

About this guide

Written by InboxRatio Editorial. Protocol behavior described here follows the governing RFCs (7208, 6376, 7489) and current Google and Yahoo sender documentation; deliverability effects reflect what we observe in our own controlled placement testing rather than vendor claims.

Methodology

InboxRatio runs controlled inbox placement tests: identical campaigns sent through each reviewed platform to a fixed seed list, with every placement recorded per mailbox provider. Authentication is configured on our own domains for every test, which is how the setup friction and failure modes described here get observed firsthand. Full protocol: how we test.

Last updated

21 August 2026. Reviewed against provider sender requirements quarterly.

Frequently asked questions

Do I need all three of SPF, DKIM and DMARC? Yes. Google's and Yahoo's bulk sender requirements expect all three from volume senders, and the design logic is interlocking: SPF and DKIM fail in different situations, and DMARC is the only layer that checks the From address recipients see.

Which should I set up first? SPF and DKIM in either order — both are prerequisites for DMARC to have anything to align. Then publish DMARC at p=none with a reporting address and tighten from there.

Can a message pass SPF and DKIM but fail DMARC? Easily, and it's the most common real-world failure: the passes exist but neither passing domain matches the From domain. Typical cause — an ESP signing DKIM with its own domain instead of yours. The fix is enabling custom-domain signing on your platform.

Is SPF still worth publishing if DKIM survives forwarding better? Yes. SPF is trivial to publish, gives DMARC a second alignment path when a DKIM signature breaks, and its absence is treated as a configuration gap by receivers and setup auditors alike.

Why do my authentication results say pass but mail still lands in spam? Authentication is one input among several. Reputation, complaint rates, list quality and engagement carry heavy weight — a fully authenticated message from a domain with poor standing still gets filtered. See our diagnostic guide for the full checking order.

How can I see SPF, DKIM and DMARC results for a real message? Open the message's raw source and read the Authentication-Results header, or paste the source into our email header analyzer for a decoded verdict per mechanism.

Treat the three records as one system — SPF and DKIM generate proofs, DMARC connects them to the identity recipients see and reports back. Check where your domain stands right now with the email authentication checker; whatever it flags is your first fix.