DMARC Engine
Home/Blog/DMARC vs SPF vs DKIM: how they fit together
Blog

DMARC vs SPF vs DKIM: how they fit together

SPF, DKIM and DMARC are named together so often that they blur into one thing. They are not. This is a clear comparison of what each record actually proves, why SPF and DKIM are blind to the From line your recipients trust, and how DMARC ties them together with alignment and policy.

22 June 2026 · 5 min read

DMARC vs SPF vs DKIM: how they fit together

SPF, DKIM and DMARC answer different questions. SPF checks whether the sending server is allowed to send for the domain in the envelope sender. DKIM checks whether the message was signed by the domain in its signature and arrived unaltered. DMARC checks whether either of those passed for the domain in the visible From address, tells receivers what to do if not, and sends you reports. You need all three: SPF and DKIM provide the evidence, and DMARC decides whether that evidence is about your domain.

Side by side

SPFDKIMDMARC
StandardRFC 7208RFC 6376RFC 9989
Published atTXT at the envelope sender domainTXT or CNAME at <selector>._domainkeyTXT at _dmarc
ChecksThe connecting IP addressA cryptographic signature over headers and bodyWhether SPF or DKIM passed and aligned
Domain it checksEnvelope sender (Return-Path)The d= signing domainThe visible From domain
Survives forwardingUsually notUsually, if the message is not modifiedYes, if DKIM still aligns
Tells receivers what to doOnly loosely, through -all or ~allNoYes: p=none, quarantine or reject
Sends you reportsNoNoYes, aggregate reports to rua

SPF: is this server allowed to send?

An SPF record lists the servers allowed to send mail for a domain:

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

The receiver takes the connecting IP address, looks up the SPF record of the domain in the envelope sender (the MAIL FROM, also called the Return-Path), and checks whether the IP is listed.

What SPF does not do:

  • It never looks at the From header. An attacker can pass SPF for their own domain in the envelope while putting your domain in the visible From.
  • It breaks on forwarding. The forwarding server's IP is not in your record.
  • It has a ten-lookup limit. More than ten DNS lookups returns a permanent error. Fixing too many SPF DNS lookups covers the cure.

Check a record with the SPF checker.

DKIM: was this message signed, and is it intact?

DKIM signs selected headers and the body with a private key and adds the signature in a header:

Email headers
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1;
  h=from:to:subject:date:message-id; bh=...; b=...

The receiver fetches the public key from selector1._domainkey.example.com and verifies the signature. The bh= value is a hash of the body, so a changed body fails verification. Because the signature travels with the message, it usually survives forwarding.

What DKIM does not do:

  • It does not tie d= to the From header. A platform can sign with its own domain while the From address is yours, and an attacker can sign their own message with their own domain. Both pass DKIM.
  • It breaks if the message is modified. Mailing lists that add footers or gateways that rewrite links invalidate the signature.

Check a selector with the DKIM checker.

DMARC: does the evidence match the From address?

DMARC has no check of its own. It takes the SPF and DKIM results and adds alignment: a message passes DMARC only if SPF or DKIM passes and the domain it passed for matches the domain in the visible From address.

DNS record
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com
  • SPF alignment compares the envelope sender domain with the From domain.
  • DKIM alignment compares the d= domain with the From domain.
  • Relaxed alignment, the default, only needs the same organisational domain, so mail.example.com aligns with example.com. Strict alignment (aspf=s, adkim=s) needs an exact match.

This is what stops an attacker. Their SPF pass is for their own envelope domain and their DKIM signature is for their own d=, so neither aligns with your From domain and DMARC fails.

The p= tag then tells receivers what to do with failing mail: none (monitor only), quarantine (treat as suspicious, usually the spam folder) or reject (refuse it). The rua= tag asks receivers to send you aggregate reports showing every source that sent mail as your domain and whether it aligned. Neither SPF nor DKIM gives you that visibility. The DMARC report analyser turns the reports into a per-source view.

One aligned pass is enough

DMARC passes if at least one mechanism passes with alignment. That has two practical consequences:

  • Forwarding. A forwarded message usually fails SPF but keeps a valid DKIM signature, so it still passes DMARC on DKIM.
  • Third-party senders. Getting SPF to align through a sending platform needs a custom Return-Path on your domain, which not every platform supports. Getting DKIM to align usually just means completing the platform's domain authentication so it signs with d=example.com.

So DKIM alignment is the one to rely on, and SPF alignment is a useful extra. When both pass but DMARC still fails, the cause is alignment: why DMARC fails when SPF and DKIM pass shows how to find it.

Setting up all three, in order

  1. SPF and DKIM for every legitimate sender: your mailbox provider, marketing platform, CRM, help desk and anything else that sends as your domain.
  2. DMARC at p=none with a rua address, to start receiving reports.
  3. Fix alignment for each source the reports show failing.
  4. Move the policy to p=quarantine, then p=reject, once your own mail passes. p=none vs quarantine vs reject explains each step.

Run the DMARC checker to see what your domain publishes today. If you would rather have the rollout and the report reading done for you, hosted DMARC stages the policy from p=none to p=reject.

Share

See where your domain stands today

Run a free DMARC scan, then let us take you to enforced p=reject with no email outage.