SPF vs DKIM vs DMARC - What Each One Does

SPF, DKIM, and DMARC are three email authentication standards that work together: SPF authorizes which servers may send for your domain, DKIM cryptographically signs each message so it can't be forged or altered, and DMARC ties both back to your visible From address through alignment and tells receivers what to do on failure. You need all three. Each one closes a gap the others leave open, which is why Gmail and Yahoo require the full set for bulk senders.

What each one does, in one line

The fastest way to understand the trio is to see them side by side. They aren't competing options; they're three layers of the same authentication stack, each adding something the previous one lacks.

SPF checks the envelope. DKIM checks the content. DMARC checks the From address a human actually sees.

What does SPF do?

SPF (Sender Policy Framework) publishes a list of servers allowed to send email for your domain, and receivers check the sending IP against it. It's a DNS TXT record starting with v=spf1. If the sending IP is listed, SPF passes; if not, it fails according to your -all or ~all setting.

SPF's blind spot: it validates the envelope sender (the MAIL FROM), not the visible From header. A spammer can pass SPF on their own domain while forging your domain in the From field a recipient reads. SPF also breaks on forwarding, because the forwarding server's IP isn't in your record. The full syntax, mechanisms, and the 10-lookup limit are in SPF record explained.

What does DKIM do?

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each message, so receivers can prove it came from your domain and wasn't modified in transit. Your server signs with a private key; the public key sits in a selector._domainkey DNS record. A valid signature means the content is authentic.

DKIM's strength over SPF is that it survives forwarding (as long as the message body isn't changed) and it proves integrity, not just authorization. Its blind spot is the same as SPF's on its own: DKIM can pass on the provider's domain (d=esp.com) without matching your From address. That's why alignment matters. The signing mechanics are in DKIM explained.

What does DMARC do?

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the layer that makes SPF and DKIM actually protect your visible From address, by requiring alignment and publishing a policy. A message passes DMARC only if SPF or DKIM passes and the authenticated domain matches the From domain.

DMARC adds two things neither SPF nor DKIM has:

• Alignment: the authenticated domain must match your From domain, closing the spoofing gap.
• Policy and reporting: p=none, p=quarantine, or p=reject tell receivers how to handle failures, and aggregate reports show you who sends as your domain.

Without DMARC, SPF and DKIM each leave the From address forgeable. With it, spoofers get rejected. See DMARC explained for policy detail and DMARC alignment explained for how matching works.

How they work together on a single message

When a real message arrives, all three run in sequence, and the combined result decides delivery. Here's the chain for a properly configured sender:

1. SPF checks the sending IP against your record. Pass.
2. DKIM verifies the signature using your public key. Pass.
3. DMARC checks that the SPF domain or the DKIM d= domain matches your From domain. Aligned, so pass.
4. The receiver accepts the message and reputation builds.

Break any link and DMARC catches it. If SPF and DKIM both fail to align, your p=reject policy tells the receiver to block the message, which is exactly what stops a spoofer impersonating you.

What the three records look like together

A fully authenticated domain publishes three DNS records, one per standard. Seeing them side by side makes the division of labor concrete. SPF is a TXT record on the root domain:

yourbrand.com           TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com -all"

DKIM is a TXT record under a selector, holding the public key:

mail._domainkey.yourbrand.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

DMARC is a TXT record at the _dmarc subdomain, naming the policy and report address:

_dmarc.yourbrand.com    TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=r; aspf=r"

Three records, three jobs: authorize the IP, sign the content, enforce alignment and report. None replaces another.

Common confusions, cleared up

People mix these three up in predictable ways. Here are the corrections that matter.

The recurring theme: SPF and DKIM each prove something narrow, and DMARC is the only layer that ties either one to the address a human reads. The case that catches the most senders we audit: SPF and DKIM both report pass, the team assumes DMARC is fine, but mail still fails because the sending platform signs DKIM with its own d=esp.com and uses its own envelope domain in MAIL FROM. Both pass on the provider's domain, neither aligns to the visible From, and DMARC fails the message. Signing with your own domain key fixes it. That's covered in depth in DMARC alignment explained. If repeated alignment failures trace back to a shared sending pool, dedicated IP vs shared IP email explains why a fixed IP and your own DKIM key make all three align cleanly.

Which order to set them up

Set up SPF and DKIM first, confirm both pass and align, then publish DMARC starting at p=none. DMARC has nothing to evaluate until SPF or DKIM is working, so enforcing it early just blocks your own mail. Once aggregate reports confirm every legitimate sender aligns, tighten DMARC to quarantine and then reject.

How BulkEmailSetup helps

BulkEmailSetup sets up SPF, DKIM, and DMARC together on your dedicated SMTP server, all aligned to your own domain, so your mail passes the full authentication stack that Gmail and Yahoo now require. We also help you ramp DMARC to enforcement safely. See pricing for plans.

Frequently asked questions