SPF, DKIM, and DMARC: what each one actually checks

SPF checks which servers may send for a domain. DKIM checks whether a specific message was altered in transit. DMARC checks whether the two agree, and tells the receiver what to do when they don’t. None of the three does the other two’s job — a domain needs all three to actually stop spoofing.

SPF: which servers may send as this domain

SPF (Sender Policy Framework) is a TXT record listing the servers, IP ranges, and other domains’ records authorized to send mail claiming to be from yours. A receiver checks the connecting server’s IP against that list. It says nothing about the message itself — a server on the list can send anything, and a forwarded message (where the connecting server is the forwarder, not the original sender) routinely fails SPF through no fault of the original sender. SPF also carries a hard ceiling worth knowing about on its own: exactly 10 DNS lookups, after which the entire record silently stops being honored.

DKIM: was this specific message altered

DKIM (DomainKeys Identified Mail) signs each outgoing message with a private key, and publishes the matching public key at a DNS TXT record under a selector (selector._domainkey.example.com). The receiver recomputes the signature from the message it actually received and compares it to the one in the header — a mismatch means something changed the message (or the headers it signs) in transit. Unlike SPF, DKIM travels with the message itself and survives most forwarding, but it verifies integrity, not authorization: a message can be validly DKIM-signed by a completely different domain than the one in the visible From address.

DMARC: do SPF and DKIM actually match the From address

DMARC is the piece that closes the gap above: it requires that the domain which passed SPF or DKIM align with the domain in the visible From header — not just that some domain passed one of the two checks. A message can pass SPF for a completely unrelated sending domain and still fail DMARC, because DMARC is asking the more specific question a spoofing attack actually depends on. DMARC also carries its own published policy, telling receivers what to do with a message that fails alignment:

• p=none — report failures, take no other action. A starting point, not an end state.
• p=quarantine — deliver failing messages to spam/junk.
• p=reject — refuse failing messages outright at the receiving server.

A DMARC record without a rua reporting address is enforcing a policy blind — it can quarantine or reject spoofed mail, but nobody at the domain ever sees the aggregate reports that would reveal who’s actually being spoofed, or whether a legitimate sending source was accidentally caught by the policy.

Why all three, and not just one

SPF without DKIM breaks the moment a message is forwarded. DKIM without SPF still lets anyone send unauthenticated mail that simply lacks a signature — most receivers treat “no DKIM signature” far more leniently than “DKIM signature present but invalid.” And either one without DMARC has no alignment requirement at all, so a message can pass SPF or DKIM for some domain while still spoofing yours in the visible From address — which is the exact attack DMARC exists to close.