SPF, DKIM and DMARC: how the three work together

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

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 the domain's 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.example.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 the 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@example-company.com in the header. SPF passed (for the envelope, evil.com). DKIM passed (signed by evil.com). Yet the reader sees the 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.

Replayed with DMARC in place, the attack falls apart. The attacker's mail passes SPF and DKIM for evil.com — but evil.com does not match example-company.com in the From:, so alignment fails, so DMARC fails, and the published policy (ideally p=reject) refuses the message. The same alignment check is what makes DMARC stronger than the sum of its parts. For 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. There remain rare cases where a relay rewrites the message and breaks both — some mailing lists, notably; for those, a complementary mechanism called ARC steps in, and here's how it works.

Why all three are necessary

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

• SPF declares the 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 — delivers the reports that expose every source claiming to be the domain.

Drop any one and a hole opens: 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. SPF and DKIM come first, with a check that the legitimate sources pass and align. Then DMARC goes out at p=none to start collecting reports, the unaligned senders the reports reveal get fixed, and finally the policy ramps to quarantine and reject. We cover that progression step by step in how to get to p=reject without breaking email. And for the exact syntax to publish at each stage, our annotated DMARC record examples run from the most cautious to the strictest.

A worked example: tracing one message

Theory clicks faster with a concrete case. A CRM sends a receipt as billing@example-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 the published record. Most third-party platforms use their own bounce domain for the envelope, so SPF passes — but for the CRM's domain, not the sender's. That's a technically valid SPF pass that does nothing for DMARC, because it isn't aligned with the From:.
2. DKIM checks the signature. With the CRM set up to sign with d=example-company.com — typically by adding a CNAME the provider supplies — the signature verifies against the public key in the domain's DNS, and the signing domain is the right one.
3. Alignment is the deciding step. Did SPF align? Only if the envelope domain matched example-company.com, which it usually doesn't for third parties. Did DKIM align? Yes — d=example-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 in the aggregate reports, a source showing DKIM-aligned is a solved source; one failing both alignments is the next task on the list.

The verdict is there in the message headers

Watching the three layers at work takes no lab: every received message carries the verdict. The full headers of any email in the inbox contain a line the receiving server added, usually named Authentication-Results. It states the SPF result with the envelope domain that was checked, the DKIM result with the signing domain, and the final DMARC verdict. Reading a few real messages this way — one from the domain itself, one from a third-party sender, one newsletter — makes the alignment logic tangible in a way no diagram can: the identifier each layer evaluated becomes visible, and with it the reason DMARC concluded what it did. It's also the fastest first reflex when a single message misbehaves.

Three mistakes that break the stack

Even with all three records published, the same details are what bring the whole thing down. Each one passes a naive "is the record there?" check while quietly defeating the protection — which is why an analyzer that tests alignment, not just presence, matters:

• SPF exceeding ten DNS lookups. Stack too many include: statements and SPF returns a PermError — past the limit, evaluation stops and the check fails outright. That error calls for consolidating the include: statements (see our dedicated guide on the SPF ten-lookup limit).
• Misaligned DKIM. A valid signature isn't enough: the signing domain (d=) has to match the From:. A shared platform's default signature (d=platform.com) passes DKIM but doesn't align — the number-one cause of DMARC failing while "everything looks green."
• Confusing strict and relaxed. Under relaxed alignment (adkim=r/aspf=r), a sending subdomain is enough; under strict (s), an exact match is required. Switching to strict without first confirming that the sources sign on the root domain breaks legitimate mail.

Where does DMARCbis fit in?

In May 2026, DMARCbis (RFC 9989) modernized DMARC — without touching the alignment principle described here. SPF and DKIM keep exactly the same role. On the DMARC side, the pct tag goes away (replaced by t=y for testing mode), a new np tag covers non-existent subdomains, and the DNS Tree Walk replaces the Public Suffix List for determining the organizational domain. In other words: an existing SPF + DKIM + DMARC stack stays valid as-is — DMARCbis refines it, it doesn't rewrite it. For the full rundown of what's new, see what is DMARC.

The three layers at a glance

That leaves the question of where a given domain stands on all three. Our free analyzer checks SPF, DKIM and DMARC together and shows exactly where the gaps are — including whether the sources actually align, not just whether records exist. Comparison against a whole sector is possible in the DMARC Observatory, where it's clear that alignment — not the mere existence of records — is what separates truly protected domains from the rest.

And when it's time to close those gaps, Thomas, the virtual CISO, identifies each sending source, generates the precise SPF, DKIM and DMARC records to publish (DMARCbis tags included), and guides the domain to full enforcement. Analyze a domain or get started.