SPF vs DKIM vs DMARC: How They Work Together

SPF, DKIM, and DMARC are not three competing choices; they are three layers of one system. SPF checks which servers may send for your domain, DKIM cryptographically verifies the message was not tampered with, and DMARC ties both back to the address your recipients actually see and tells receivers what to do when a check fails. You want all three, not one. For how they fit into the broader sending picture, read Email authentication explained.

Understanding why you need the full stack starts with seeing where each layer falls short alone. None of them is sufficient by itself, which is the whole reason DMARC exists. If you would rather just confirm what a domain currently publishes, how to check SPF, DKIM, and DMARC walks through the lookups.

What SPF checks, and what breaks it

SPF (Sender Policy Framework) publishes a list of servers authorized to send mail for your domain. A receiving server takes the envelope sender domain, looks up its SPF record, and asks one question: did this message come from an allowed IP? The mechanism is defined in RFC 7208.

The weakness is forwarding. When a message is forwarded, the sending IP changes to the forwarder's server, which usually is not in your SPF list, so SPF fails even though the mail is legitimate. SPF also validates the envelope sender, not the From: address your recipient reads, so on its own it does nothing to stop someone spoofing your visible address.

What DKIM checks, and what breaks it

DKIM (DomainKeys Identified Mail) signs the message with a private key. The receiver fetches the matching public key from DNS and confirms two things: the message really came from the signing domain, and its signed content was not altered in transit. The signature survives forwarding, which is exactly where SPF fails. DKIM is specified in RFC 6376.

DKIM's gap is policy. A valid signature proves integrity and origin, but it says nothing about what should happen when the signature is missing or invalid. A signature can also be valid for a domain that has nothing to do with the From: address a reader sees, so DKIM alone still leaves the visible identity unprotected.

What DMARC adds: alignment and policy

Here is the part that unifies everything. DMARC (Domain-based Message Authentication, Reporting and Conformance) does not add a new authentication check; it builds on the two you already have. It requires that SPF or DKIM not only pass, but pass for a domain that aligns with the visible From: address. That alignment requirement is what finally protects the address your recipient actually reads. DMARC is defined in RFC 7489.

DMARC then adds a policy and a feedback loop. The policy (p=none, p=quarantine, or p=reject) tells receivers what to do with mail that fails alignment, and aggregate reports show you who is sending under your name. SPF closes the server question, DKIM closes the integrity question, and DMARC closes the identity question while telling the world how to enforce it.

A message passes DMARC if either check aligns and passes. That is why running both SPF and DKIM gives resilience: forwarding can knock out SPF, but an aligned DKIM signature keeps the message authenticated.

Side-by-side comparison

Layer	What it checks	What breaks it	Where it lives
SPF	Whether the sending server's IP is authorized	Forwarding changes the IP; ignores the visible From	TXT record on the root domain (v=spf1)
DKIM	Message integrity and signing-domain origin	Says nothing about policy; signer can differ from visible From	TXT record at selector._domainkey
DMARC	Whether SPF or DKIM aligns with the From and what to do on failure	Needs at least one underlying check to pass with alignment	TXT record on the _dmarc subdomain (v=DMARC1)

The order to deploy them

Roll them out in the order that keeps legitimate mail flowing. First, publish SPF and configure DKIM signing so your real mail authenticates cleanly. Once both are in place, add DMARC at p=none. That monitoring mode changes nothing for recipients but turns on the aggregate reports, letting you confirm every legitimate sending source aligns before you tighten the policy. When the reports are clean, move to p=quarantine, then p=reject.

Skip the monitoring step and you risk a strict policy silently dropping your own newsletters or invoices. Patience at p=none is cheaper than a blocked sending stream.

Curious whether a domain has the full stack in place? Run a free lookup at the site root (/) and review its SPF and DMARC records in seconds.