These three get thrown around like synonyms constantly — "we set up DMARC" when what actually happened was an SPF record got added, or "DKIM is failing" when the real problem is alignment. They're related, they live in the same DNS zone, and they get configured around the same time, but they do three genuinely different jobs. Understanding the difference isn't academic — it's the difference between a mail setup that actually stops spoofing and one that just has some DNS records that look official.

SPF: a list of who's allowed to send

SPF (Sender Policy Framework) is a DNS TXT record that answers one narrow question: which mail servers are authorised to send email claiming to be from this domain? It looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net -all

When a receiving mail server gets a message, it checks the IP address that actually connected against the list of authorised senders published in the sending domain's SPF record. If the connecting IP isn't on the list, SPF fails for that message.

The detail that trips people up: SPF checks the envelope sender (the MAIL FROM / Return-Path, used for bounce handling) — not the visible "From:" header a person actually reads in their inbox. A message can pass SPF cleanly while showing a completely different, forged display name. This is exactly why SPF alone was never enough to stop phishing, and it's the first reason DMARC exists.

SPF also has a hard limit that catches real configurations out in production: RFC 7208 caps SPF evaluation at 10 DNS lookups. Every include:, a, mx, ptr and exists mechanism counts toward that limit, and each include: can itself pull in more lookups from whatever it points to. Stack up a few email service providers, a CRM, a helpdesk tool and a marketing platform, each adding their own include:, and it's easy to blow past 10 without anyone noticing — the record still looks fine to read, but evaluation returns a permerror and SPF effectively stops working for the domain. This is one of the most common "SPF is definitely set up but keeps failing" causes in the wild.

The qualifier at the end matters too: -all (hardfail) tells receivers to reject anything not on the list; ~all (softfail) asks them to accept it but flag it as suspicious; ?all (neutral) says nothing useful either way. A lot of "SPF isn't stopping spoofing" reports turn out to be a record still sitting on ~all from initial testing that never got tightened.

DKIM: a cryptographic signature, not a permission list

DKIM (DomainKeys Identified Mail) works completely differently. The sending server signs each outgoing message with a private key, adding a DKIM-Signature header containing that signature. The corresponding public key is published in DNS as a TXT record at a specific location: selector._domainkey.example.com. The receiving server fetches that public key and verifies the signature against it.

Two things a valid DKIM signature actually proves: the message (or the parts of it covered by the signature) wasn't altered in transit, and it was genuinely signed by whoever holds the private key for that selector. It says nothing on its own about whether that signer is who they claim to be in the visible From address — that's an alignment question, and alignment is DMARC's job, not DKIM's.

The "selector" part explains something people often notice without understanding why: a domain can have several DKIM records active at once — google._domainkey, s1._domainkey, sendgrid._domainkey — one per sending service, each with its own key pair. This is normal and by design; it's how a domain can send genuine mail through several different platforms simultaneously, each independently verifiable, without them needing to share a key.

DMARC: the policy layer that actually ties them together

DMARC (Domain-based Message Authentication, Reporting & Conformance) doesn't add a third independent authentication mechanism. It's a policy record that does two things: it tells receiving servers what to do when a message fails SPF and/or DKIM, and it tells them where to send reports about what they're seeing.

The part that actually closes the gap SPF and DKIM leave open is alignment. Without DMARC, a message can technically pass SPF or DKIM for a domain that has nothing to do with the address in the visible From header — an attacker's own domain can pass its own SPF check just fine while the message's From address is forged to look like yours. DMARC requires the domain that passed SPF or DKIM to match (align with) the visible From domain before the message counts as a genuine DMARC pass. That alignment check is the actual anti-spoofing mechanism — SPF and DKIM alone don't enforce it.

A DMARC record's policy tag is the part with real consequences: p=none takes no enforcement action and just requests reporting; p=quarantine asks receivers to treat failing mail as suspicious (usually spam-foldered); p=reject asks them to refuse it outright. The practical, repeatedly-learned lesson here: start at p=none and actually read the aggregate reports (the rua= address) for a few weeks before moving to quarantine, and definitely before reject. Jumping straight to reject on a domain that's never been monitored is a reliable way to silently break a mailing-list forward, an old CRM integration, or some marketing tool that's been quietly sending on the domain's behalf for years without ever being properly authenticated.

Those aggregate reports are also the most underused part of the whole setup. They're literally a list of every server that tried to send mail claiming to be from your domain over the reporting period — which is often how domain owners first discover shadow-IT tools, forgotten integrations, or actual abuse of their domain, none of which shows up any other way.

Why all three, and not just the "best" one

They cover different, overlapping parts of the same problem, and none of them is sufficient alone. SPF stops unauthorised mail servers from successfully claiming to speak for the domain at the connection level. DKIM proves a message's content and origin weren't tampered with in transit. DMARC forces the two to actually mean something by requiring alignment with what the recipient sees, and gives visibility into what's happening across all three. Drop any one and there's a real gap: no SPF means anyone can stand up a server and claim your domain; no DKIM means a message can be modified in transit without detection; no DMARC (or DMARC left at p=none forever) means SPF and DKIM can both technically pass while the visible sender is still forged.

The misconfigurations that show up constantly

• Two SPF records on one domain. RFC 7208 only permits one SPF TXT record per domain. A second one (often left behind after a migration) makes evaluation undefined — different receivers handle it differently, and results become inconsistent in ways that are genuinely hard to debug from the outside.
• Blowing the 10-lookup SPF limit silently, usually after adding "just one more" email service provider without checking what it costs.
• DKIM keys that are never rotated, or old selectors left active for services that were decommissioned years ago — not a security hole by itself, but dead weight that makes auditing harder.
• DMARC parked at p=none indefinitely with nobody actually reading the reports — technically present, functionally decorative.
• No explicit subdomain policy, leaving subdomains that have never sent a legitimate email wide open for spoofing, since DMARC's subdomain handling doesn't always inherit the way people assume it does.

The only way to know which of these actually apply to a given domain is to check it directly rather than assume the initial setup still matches what's live today — records drift as services get added and dropped over the years.