SPF, DKIM and DMARC: how the three work together

People often ask whether they need SPF, DKIM, or DMARC — as if they had to pick one. They don't. The three are layers that stack, each covering a gap the others leave open. Understand how they fit together and email authentication stops feeling like alphabet soup and starts making sense. This guide walks through each layer and shows how they combine into real protection.

A quick model of how email travels

Every email has two "from" identities, and confusing them is the root of most authentication misunderstandings:

• The envelope sender (also called MAIL FROM or Return-Path) — used during the SMTP delivery conversation, invisible to the reader.
• The header From: — the friendly address shown in the inbox.

SPF checks the first. DKIM signs the message. DMARC ties everything back to the second — the one humans actually see. Keep that distinction in mind and the rest falls into place.

SPF: who is allowed to send

SPF (Sender Policy Framework) is a list, published in your DNS, of the servers allowed to send mail for your domain. When a receiver gets a message, it checks the sending server's IP against that list — evaluated against the envelope domain.

your-domain.com.  IN TXT
  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

SPF has two well-known limits. First, it authenticates the envelope, not the visible From:, so on its own it doesn't stop someone displaying your domain to a reader. Second, it breaks on forwarding: when a message is relayed, the sending IP changes and SPF fails. And it has a hard cap — no more than ten DNS lookups during evaluation, or it errors out. SPF is necessary but not sufficient.

DKIM: the signature that proves integrity

DKIM (DomainKeys Identified Mail) takes a different approach. The sending server signs each message with a private key; the receiver fetches the matching public key from your DNS and verifies the signature. If it checks out, two things are proven: the message wasn't altered in transit, and it was genuinely signed by the holder of that domain's key.

selector1._domainkey.your-domain.com.  IN TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkq... (public key)"

DKIM survives forwarding far better than SPF, because the signature travels with the message. But — and this is the catch DMARC fixes — a valid DKIM signature only proves that some domain signed the message. It doesn't, by itself, require that domain to be the one in your From: header.

The gap both leave open

Here's the attack that SPF and DKIM, individually, don't stop. An attacker registers evil.com, sets up flawless SPF and DKIM for it, and sends mail that passes both checks — for evil.com. Then they put From: ceo@your-company.com in the header. SPF passed (for the envelope, evil.com). DKIM passed (signed by evil.com). Yet the reader sees your CEO's address. Both layers are green, and the spoof sails through. Something has to connect the authentication back to the visible domain. That something is DMARC.

DMARC: alignment ties it together

DMARC adds one decisive rule on top of SPF and DKIM: alignment. A message passes DMARC only if it passes SPF or DKIM and the authenticated domain matches the From: domain.

Replay the attack with DMARC in place. The attacker's mail passes SPF and DKIM for evil.com — but evil.com does not match your-company.com in the From:, so alignment fails, so DMARC fails, and your policy (ideally p=reject) refuses the message. The same alignment check is what makes DMARC stronger than the sum of its parts. If you want the foundational overview first, read what is DMARC.

There are two flavors of alignment:

• SPF alignment — the Return-Path domain matches the From: domain.
• DKIM alignment — the signing domain (d=) matches the From: domain.

DMARC needs only one of them to align (and pass) for the message to be authenticated. In practice, DKIM alignment is the more reliable target, because it survives forwarding where SPF does not.

Why you want all three

A robust setup uses every layer for what it's best at:

• SPF declares your legitimate sending servers and gives receivers a fast first check.
• DKIM proves integrity and origin, and keeps working through forwarders and mailing lists.
• DMARC binds both to the visible domain, tells receivers what to do on failure, and — crucially — sends you the reports that let you see every source claiming to be you.

Drop any one and you have a hole: SPF without DMARC doesn't protect the From:; DKIM without DMARC doesn't enforce alignment; DMARC without working SPF/DKIM has nothing to align against.

Putting it in order

The right deployment sequence follows the dependencies. Publish SPF and DKIM first and make sure your legitimate sources pass and align. Then publish DMARC at p=none to start collecting reports, fix any unaligned senders the reports reveal, and finally ramp the policy to quarantine and reject. We cover that progression step by step in how to get to p=reject without breaking email.

A worked example: tracing one message

Theory clicks faster with a concrete case. Imagine your CRM sends a receipt as billing@your-company.com from the CRM provider's servers. Here's how the three layers evaluate that single message:

1. SPF checks the envelope (Return-Path) domain against your published record. Most third-party platforms use their own bounce domain for the envelope, so SPF passes — but for the CRM's domain, not yours. That's a technically valid SPF pass that does nothing for DMARC, because it isn't aligned with your From:.
2. DKIM checks the signature. If you set the CRM up to sign with d=your-company.com — typically by adding a CNAME the provider gives you — the signature verifies against the public key in your DNS, and the signing domain is yours.
3. Alignment is the deciding step. Did SPF align? Only if the envelope domain matched your-company.com, which it usually doesn't for third parties. Did DKIM align? Yes — d=your-company.com matches the From: domain.
4. DMARC verdict. DMARC needs only one aligned pass. DKIM aligned and passed, so the message passes DMARC — even though SPF didn't align at all. The receipt is delivered and trusted.

This example explains a rule that surprises many teams: DKIM alignment is the workhorse of real-world deployments. Third-party senders rarely align SPF (their envelope is theirs), but they can almost always be made to align DKIM through a branded signing domain. So when you read your aggregate reports, a source showing DKIM-aligned is a solved source; one failing both alignments is your next task to fix.

See your three layers at a glance

Want to know how your domain scores on all three right now? Our free analyzer checks SPF, DKIM and DMARC together and shows exactly where the gaps are — including whether your sources actually align, not just whether records exist.

And when it's time to close those gaps, Marc, the DMARC copilot, identifies each sending source, generates the precise SPF, DKIM and DMARC records to publish, and guides your domain to full enforcement. Analyze your domain → or get started.