SPF vs DKIM vs DMARC Explained

These three acronyms get lumped together so often that it's easy to assume they're interchangeable, or that any one of them alone is "email security." They're not — each one checks a different thing, and DMARC specifically exists to tie the other two together.

SPF: which servers may send for your domain

SPF (Sender Policy Framework) is a TXT record listing the mail servers authorized to send email on behalf of your domain. When a message arrives, the receiving server checks the connecting server's IP address against the sending domain's SPF record. If the IP isn't listed, the message fails SPF.

SPF's weakness is that it only checks the envelope sender — a technical address used for bounce handling — not the "From" address a person actually reads. A message can pass SPF cleanly while displaying a completely different, spoofed "From" address. SPF also breaks under forwarding, since the forwarding server's IP usually isn't in the original sender's SPF record.

DKIM: proof the message wasn't altered

DKIM (DomainKeys Identified Mail) takes a completely different approach: it doesn't care which server sent the message, it cares whether the message's content matches what the claimed sender actually signed. The sending server attaches a cryptographic signature, computed over specific headers and the body, using a private key. The receiving server fetches the corresponding public key from a DNS TXT record and verifies the signature.

Because DKIM travels with the message content rather than depending on the connecting IP, it survives forwarding far better than SPF does. Its weakness is the opposite of SPF's: DKIM proves the message wasn't tampered with, but says nothing about which domain is allowed to send on whose behalf.

DMARC: the policy that ties them together

DMARC doesn't introduce a third independent check — it's a policy layer that sits on top of SPF and DKIM results and adds one crucial requirement: alignment. A message passes DMARC if it passes SPF or DKIM, and the domain that passed matches the visible "From" domain the recipient actually sees.

That alignment requirement is what closes the specific spoofing trick both SPF and DKIM leave open on their own: a message can pass SPF for a completely unrelated domain while showing a spoofed "From" address, and without DMARC's alignment check, nothing catches that mismatch.

DMARC then tells the receiving server what to do about a message that fails alignment — deliver it anyway, quarantine it, or reject it outright — and, critically, sends the domain owner reports about what's happening. Without those reports, most domain owners have no visibility into who's sending mail as them at all.

How they fit together

StandardChecksWeak point
SPFIs the sending IP authorized?Breaks on forwarding; doesn't check "From"
DKIMWas the content signed and unaltered?Doesn't say who's allowed to send
DMARCDoes a passing result align with "From", and what to do if not?Needs SPF or DKIM already configured correctly

In practice: configure SPF, configure DKIM, then add DMARC to enforce alignment and get visibility into failures. Skipping straight to DMARC without SPF or DKIM in place gives you nothing to align against.

Frequently Asked Questions

Is one of these more important than the others?

DKIM is generally considered the most robust on its own since it travels with the message, but the real answer is that none of them is a substitute for the others — DMARC specifically requires at least one of SPF or DKIM to already be working.

Why does my email still get flagged as spam with all three configured?

SPF, DKIM, and DMARC address authentication — proving a message really came from your domain — not spam filtering, which also weighs sender reputation, content, and recipient engagement. Passing all three is necessary but not sufficient for good deliverability.

Do I need to set these up separately for every subdomain?

SPF and DKIM records are typically domain- or subdomain-specific depending on how mail is sent from each. DMARC can cascade from a parent domain to subdomains via its sp= tag, so it usually needs less per-subdomain repetition.

Stop checking this by hand

NetTests runs this kind of check on a schedule, stores historical results, and alerts your team the moment something changes.

Start monitoring free →
No credit card required  ·  Free plan available