DMARC vs SPF vs DKIM: How the Three Records Fit Together

25 May 2026 · 13 min read

DMARC vs SPF vs DKIM: how they fit together

Three DNS records carry almost the entire weight of email authentication: SPF, DKIM and DMARC. They are constantly named together, usually in the same breath, and that habit creates a quiet misconception that they are three versions of the same thing, or three steps in one process, where two of them are optional once you have the third. None of that is true. They prove different things, they fail in different ways, and two of them are deliberately useless on their own as anti-spoofing controls. DMARC is the one that gives them teeth, but DMARC has nothing of its own to verify; it borrows the results of the other two.

This article is a comparison, not a setup walkthrough. The aim is that by the end you can say, for any given record, exactly what it proves, what it does not prove, what an attacker can still do despite it, and how DMARC stitches the other two into a verdict your recipients can act on. If you already have all three published and just want to know why a message still fails, the failure mode itself is covered in DMARC fails but SPF and DKIM pass; here we stay on the conceptual map.

The one thing all three are trying to defend

Every internet email carries two different "from" identities, and the gap between them is the entire reason these records exist.

The envelope sender, also called MAIL FROM, the Return-Path or the bounce address. This is set during the SMTP conversation, before the message body is even sent. Bounces go here. Recipients almost never see it.
The header From, the From: line rendered in the mail client. This is the identity a human reads and trusts. It is the brand.

Nothing in the base email protocol forces these two to match, and nothing forces either of them to be true. An attacker can connect to a receiving server and announce any MAIL FROM they like, then write any From: header they like. That is spoofing in its purest form, and it is why a phishing message can say it is from your bank with no clever trickery at all. SPF, DKIM and DMARC are three different attempts to close that gap. The difference between them is which identity each one checks, and whether it bothers to connect that check back to the From line the victim actually sees. For the deeper distinction between these two identities, see header From versus envelope From.

SPF: does this server have permission to send for this domain

SPF, the Sender Policy Framework, answers one question: is the IP address connecting to me allowed to send mail for the envelope sender's domain? It is a published list of authorised sources.

You publish it as a TXT record on the domain that appears in the envelope sender. A typical record looks like this:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.0/24 -all

Read left to right, that says: mail for this domain may come from whatever Google's SPF include lists, whatever SendGrid's lists, and that one /24 block of IPs; anything else (-all, a hard fail) is unauthorised. The receiving server takes the connecting IP, looks up the SPF record of the MAIL FROM domain, expands all the include and other mechanisms, and checks whether the IP matches.

What SPF genuinely proves: this connection came from an IP the domain owner authorised. That is real and useful.

What SPF does not prove, and this is the crux:

It says nothing about the From header your recipient sees. SPF validates the envelope sender. An attacker can pass SPF for their-throwaway-domain.com in the envelope while putting you@yourbank.com in the visible From. SPF is perfectly happy; it was never asked about the From line.
It breaks the moment mail is forwarded. The forwarding server connects from its own IP, which is not in your SPF record, so SPF fails for a message that is completely legitimate. Forwarding rewrites the path, not the record.
It is fragile by design. SPF expansion is capped at ten DNS lookups. Stack up a few providers, each with their own include, and you blow past the limit and the record returns permerror, which most receivers treat as a non-pass. This is one of the most common real-world SPF failures; see SPF PermError: too many DNS lookups.

So SPF, alone, is close to worthless against spoofing of your brand, because the brand lives in a header SPF never inspects. It is necessary plumbing, not a defence. If you want the full mechanism set, including the ~all versus -all distinction and macros, RFC 7208 explained and SPF macros explained go deep, and you can inspect any live record with the SPF checker.

DKIM: was this message signed by a key the domain controls, and is it unaltered

DKIM, DomainKeys Identified Mail, takes a completely different approach. Instead of asking about the connection, it cryptographically signs the message. The sending server hashes a defined set of headers and the body, signs that hash with a private key, and stamps the result into a DKIM-Signature header. The matching public key lives in your DNS.

A signature header looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourdomain.com; s=selector1;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=Cg3f2k...signaturebytes...

The two values that matter most for the comparison with SPF:

d=yourdomain.com is the signing domain. The receiver fetches the public key from selector1._domainkey.yourdomain.com and uses it to verify the signature.
bh= is the body hash. If the body changes by a single byte after signing, the hash no longer matches and DKIM fails.

What DKIM genuinely proves: a message was signed by whoever controls the private key for the d= domain, and the signed headers and body were not modified in transit. Unlike SPF, this travels with the message. Forward it five times and, as long as nobody rewrites the signed content, the signature still verifies. That portability is exactly why DKIM is the mechanism you most want carrying your authentication.

What DKIM does not prove, and it mirrors SPF's blind spot:

By itself, DKIM does not connect d= to the From header either. A message can carry a perfectly valid signature where d=somemarketingtool.net, signed by the marketing tool, while the visible From is you@yourdomain.com. The signature verifies. It just verifies for somebody else's domain. An attacker with their own domain and their own DKIM key can sign their spoof and get a green DKIM result.
It is sensitive to message modification. Mailing lists that append a footer, or security gateways that rewrite links, change the signed body and break the signature. Choice of canonicalisation (c=relaxed/relaxed versus simple/simple) affects how tolerant the signature is of trivial whitespace changes; see DKIM canonicalisation: simple versus relaxed.
A missing or wrong selector silently falls back. If your CNAME for the selector is wrong, the key will not resolve, and the provider's own signature is the only one left, which does not represent you.

The recurring theme should be obvious by now. SPF proves a domain controls a server. DKIM proves a domain controls a key. Neither, on its own, proves anything about the domain in the From line your user trusts. For the full specification behaviour, RFC 6376 explained covers it, and the DKIM checker resolves a published selector for any domain.

Stop and look at what we have after publishing SPF and DKIM perfectly:

SPF confirms the connecting IP is authorised for the envelope sender domain.
DKIM confirms the message was signed by, and is unaltered for, the d= domain.
The header From, the only identity your recipient actually reads, has been checked by neither.

An attacker can satisfy both records using domains they legitimately own, then write your brand into the From header, and every individual check comes back "pass". This is not a hypothetical. It is the default state of email without the third record. SPF and DKIM are authentication of some identity; they were simply never wired to the identity that matters for trust. Closing that gap is the single job DMARC exists to do.

DMARC: tie the authenticated domain to the From line, then decide what happens on failure

DMARC, Domain-based Message Authentication, Reporting and Conformance, adds two things SPF and DKIM lack: alignment and a policy.

You publish it as a TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; adkim=r; aspf=r

DMARC does not perform any cryptography or any new DNS-authorisation check of its own. It takes the results SPF and DKIM already produced and applies one extra rule.

A message passes DMARC if at least one of SPF or DKIM both passes and aligns with the domain in the header From.

Alignment is the join the other two were missing. It is a comparison between the From domain (what the human sees) and the domain that authentication actually proved:

SPF alignment: does the envelope sender domain match the From domain?
DKIM alignment: does the d= domain match the From domain?

This is why an attacker's setup collapses under DMARC. They can pass SPF for their throwaway domain, but that domain does not align with your From, so the SPF leg fails alignment. They can sign with their own DKIM key, but d=their-domain.com does not align with your From either. With no aligned, passing identifier, DMARC fails, and now your policy decides the outcome. That is the difference between "a check passed" and "a check passed as you".

Alignment has two modes, set with the adkim and aspf tags. Relaxed (the default, r) requires the same organisational, registrable domain, so mail.yourdomain.com aligns with yourdomain.com. Strict (s) demands an exact match. Relaxed is almost always what you want; an accidentally copied adkim=s is a frequent cause of self-inflicted failures.

The p= tag is the policy, the instruction to receivers about what to do with mail that fails DMARC:

p=none means monitor only. Failures are reported but still delivered. This is your starting point, because it tells you the truth without breaking anything.
p=quarantine means treat failures as suspicious, typically routing them to spam.
p=reject means refuse failing mail outright at the SMTP level. This is the real protection; it is the only setting that actually stops a spoof from reaching the inbox.

And rua= is where DMARC pays you back. Receivers email you aggregate reports, XML summaries of every source sending under your domain, with per-source SPF and DKIM alignment results. SPF and DKIM individually give you no feedback loop at all; DMARC turns the whole estate visible. The catch is that raw XML at volume is unreadable, which is what the DMARC report analyzer is for. The full standard is covered in RFC 7489 explained, and you can read a published policy with the DMARC checker or build one with the DMARC generator.

Why "one aligned mechanism is enough" changes everything

The phrase at least one in the DMARC rule is the most practically important detail in all three records, and it reshapes how you should think about SPF versus DKIM.

You do not need both to align. You need one. That single fact resolves most real-world headaches:

Forwarding. A forwarder breaks SPF (new connecting IP) but usually preserves DKIM (the signature travels with the body). Because DMARC needs only one aligned pass, a forwarded message with aligned DKIM still passes DMARC, even though SPF failed. This is the system working as designed, and it is the strongest argument for treating DKIM alignment as your primary goal.
Third-party senders. Getting SPF to align through an external platform means configuring a custom Return-Path on a subdomain of yours, which not every provider supports. Getting DKIM to align usually just means completing the provider's domain authentication so they sign with d=yourdomain.com. The DKIM route is normally easier and more robust.

So although SPF and DKIM look symmetrical on paper, they are not equally valuable in practice. DKIM is the one you lean on, because it survives forwarding and is generally simpler to align through providers. SPF alignment is a useful bonus, not the load-bearing wall. The decision is worked through in the SPF and DKIM alignment failure guide.

A side-by-side of what each record proves

Laying the three against each other on the questions that actually matter:

What identity does it check?

SPF checks the envelope sender (Return-Path) domain.
DKIM checks the d= signing domain.
DMARC checks the header From, by requiring SPF or DKIM to align to it.

What does a "pass" actually assert?

SPF: an authorised IP sent this, for the envelope domain.
DKIM: an authorised key signed this, for the d= domain, and it is unmodified.
DMARC: an authorised, aligned identifier vouches for the From the recipient sees.

Can an attacker pass it while spoofing your brand?

SPF: yes, trivially, using their own domain in the envelope.
DKIM: yes, using their own key and d=.
DMARC: no, because their identifiers cannot align with your From.

Does it survive forwarding?

SPF: usually no.
DKIM: usually yes.
DMARC: yes, provided one mechanism stayed aligned (normally DKIM).

Does it tell you what is sending as your domain?

SPF: no feedback.
DKIM: no feedback.
DMARC: yes, through aggregate reports.

Can it block mail?

SPF: only indirectly, via the receiver's own policy on a hard fail.
DKIM: no, a DKIM failure alone is not a delivery instruction.
DMARC: yes, explicitly, through p=quarantine and p=reject.

Read down that list and the relationship is unmistakable. SPF and DKIM are the evidence. DMARC is the rule that decides whether the evidence is about the right domain, plus the instruction for what to do when it is not, plus the reporting that lets you see your own mail flow. Remove DMARC and the other two are just two facts about domains nobody is comparing to the brand.

Where the three sit in a real deployment

In practice you do not choose between them; you publish all three, in a deliberate order, because they depend on each other.

Publish SPF and DKIM first, for every legitimate source. DMARC has nothing to evaluate until these exist and your real senders are producing aligned results. This is the inventory phase: find every system that sends as you (transactional API, newsletter tool, helpdesk, CRM, your own mail server) and authenticate each one.
Publish DMARC at p=none with a rua. Now the aggregate reports start arriving and, for the first time, you can see every source and whether each one aligns. Almost everyone discovers senders they had forgotten about, and a few they did not authorise.
Fix alignment, source by source. Complete DKIM domain authentication at each provider, add custom Return-Paths where SPF alignment matters, until the reports show every legitimate source passing on at least one aligned identifier.
Raise the policy. Only once the legitimate world is clean do you move to p=quarantine, then p=reject. Tightening earlier junks or bounces real mail. The staged approach is laid out in the enforcement journey, and the requirements page covers what Gmail, Yahoo and Microsoft now expect from bulk senders.

The ordering matters because it reflects the dependency: DMARC cannot protect a domain whose SPF and DKIM are not yet producing aligned passes, and turning DMARC to reject over a misaligned legitimate sender does real damage. The records are a stack, evaluated from the bottom up.

The practical takeaway

SPF, DKIM and DMARC are not three flavours of the same control and not three steps of one mechanism. SPF proves a server was authorised for the envelope domain. DKIM proves a key signed and protected the message for the d= domain. Each is genuinely useful and each, on its own, is blind to the From line your recipients actually trust, which is precisely the line an attacker forges. DMARC is the layer that closes the gap: it does no new verification of its own, it takes the SPF and DKIM results, demands that at least one of them aligns with the visible From, and then lets you instruct receivers to reject anything that does not. That is the whole architecture, and it only works as a stack, with SPF and DKIM as evidence and DMARC as the rule and the reporting on top.

If you would rather not assemble and maintain that stack by hand, run your domain through the DMARC checker to see what you publish today, then point it at continuous monitoring: the DMARC report analyzer shows every source broken down by aligned SPF and aligned DKIM, change alerts catch the moment a sender drifts out of alignment, and our done-for-you service takes a domain from p=none to p=reject without dropping a single legitimate message. Start with the three checkers, in order, and the picture of which record is doing what for you becomes clear within minutes.

DMARC vs SPF vs DKIM: how they fit together