How SPF, DKIM and DMARC work together, and what to do when one fails

SPF proves a message came from a server the domain's owner listed. DKIM proves the message was not altered after it was signed. DMARC does not inspect the message at all - it tells a receiver what to do when SPF or DKIM fails, and only takes effect once the passing record is also aligned to the From: address. That last part is the one most setups get wrong: a domain can publish a perfectly valid SPF record, have it pass, and still fail DMARC.

This guide covers what each of the three proves, why alignment catches setups that look fine, what actually causes each one to fail, and the order to fix them in. It links to the checkers and parsers in our email authentication tools, each of which answers one record or one provider; this page is where the three meet.

What does each of SPF, DKIM and DMARC actually prove?Copy Anchor Link

Each protocol checks a different thing, and none of them alone proves a message is legitimate.

Try each one directly: the SPF checker reads a domain's published record and follows every include, the DKIM checker reads a signature against its selector, and the DMARC checker reads the policy and explains what a receiver does with failing mail.

Why does DMARC need alignment, not just a passing SPF?Copy Anchor Link

Because SPF and DKIM each check a different address than the one a reader actually sees, and neither one checks that address at all.

SPF checks the envelope sender (MAIL FROM), not the From: header a mail client displays. A sender can register a domain, publish a valid SPF record for it, and send mail with a completely different From: address - SPF passes and proves nothing about that visible address. DKIM has the same gap in the other direction: the domain in d= only has to match whichever private key signed the message, not the From: domain.

DMARC closes that gap by requiring alignment: the domain that passed SPF or DKIM has to match the From: domain, under one of two modes RFC 7489 defines in section 3.1:

• Relaxed (r, the default) - the organisational domain has to match. mail.example.com aligns with example.com.
• Strict (s) - the fully qualified domain has to match exactly. mail.example.com does not align with example.com under strict mode.

The aspf tag sets the mode for SPF alignment and adkim sets it for DKIM; a record that omits either defaults to relaxed. Our DMARC checker reads whichever mode a domain actually publishes and spells out what it does in practice, rather than just naming the tag - a published aspf=s means "the SPF domain must match this domain exactly," not a generic definition of strict mode.

The result that trips people up: a message can pass SPF cleanly and still fail DMARC, because the domain that passed SPF was never the one in From:. A domain drafting a DMARC record before publishing it can check its tags with the DMARC record parser, which reads the same grammar the live checker does.

What causes SPF to fail, and does flattening fix it?Copy Anchor Link

The most common cause is not a wrong server in the record - it is too many DNS lookups.

RFC 7208 section 4.6.4 caps the number of include, a, mx, ptr, exists mechanisms and the redirect modifier at 10 across the entire chain a receiver has to follow, counting every nested include a provider's own record pulls in. Exceed that and the record returns PermError, which means every server the record lists is treated as unlisted - not just the terms past the limit. A record that authorises ten legitimate senders and trips the ceiling on the eleventh lookup fails for all ten.

This happens easily once a domain sends through more than two or three providers, because each one's include: can itself cost several lookups. SPF flattening collapses an include into the literal IP ranges it currently resolves to, trading the lookup for a value that can go stale the moment the provider changes its infrastructure - it is a way back under the ceiling, not a fix for whatever caused the record to grow. Run a domain's own count against the limit with the SPF flattening explainer, and check a record you are still drafting with the SPF record parser before it is anywhere near a DNS lookup budget.

Where do I find the DKIM selector for my mail provider?Copy Anchor Link

A generic DKIM checker can read whatever selector you give it, but it cannot tell you which selector your provider actually uses - Google Workspace, Microsoft 365 and Fastmail each publish a fixed, documented value, and the published value is the only thing worth checking against. Zoho is the exception: it documents a fixed SPF include, but the DKIM selector is chosen per account when the key is generated, so only the SPF side has a fixed value to check.

Four setup checkers run this comparison directly against a domain's live DNS: the Google Workspace setup checker, the Microsoft 365 setup checker (which also flags a missing selector2 - the single most common Microsoft 365 DKIM mistake), the Fastmail setup checker, and the Zoho Mail setup checker.

None of these checkers can see inside your provider's admin console - they confirm what is published in DNS, not whether DKIM signing is actually switched on there.

We looked for an equivalent fixed value to check for Mailchimp, and did not find one: Mailchimp's own documentation does not publish a single SPF include or DKIM selector that applies the way Google's, Microsoft's, Fastmail's and Zoho's do, so there is no published value for a dedicated checker to compare against. If you send through Mailchimp, the general SPF checker and DKIM checker still read whatever record Mailchimp's own setup instructions told you to publish.

What does a failing or missing DMARC record look like?Copy Anchor Link

Most DMARC problems are visible in the published record itself, once you know what each tag does - and the one failure mode that is not visible is a reporting address that silently gets skipped.

A record is read tag by tag: p (the policy - none, quarantine or reject), pct (what share of failing mail gets that policy), rua and ruf (where aggregate and forensic reports go), and aspf/adkim (alignment mode, covered above). A domain still drafting a record, or one it got from a vendor, can check the text itself with the DMARC record parser; a domain that has already published one is read live by the DMARC checker.

The failure mode with no visible error is an external rua address. RFC 7489 section 7.1 requires that when a DMARC record's report address is on a different domain than the one being reported on, the receiving domain must explicitly authorise it - by publishing a TXT record at <reported-domain>._report._dmarc.<receiving-domain> containing v=DMARC1. Without that authorisation record, a receiver sending aggregate reports is required to silently skip the address. Nothing about the DMARC record itself looks wrong; the reports simply never arrive, and a domain that thinks it is being monitored is not.

How do I read what already happened in the headers?Copy Anchor Link

A message you already received or sent carries its own verdicts in the Authentication-Results header, stamped by whichever service handled it - reading that header tells you what happened to one specific message, as distinct from what a checker predicts would happen to future mail.

Paste a raw header block into the email header analyser to see every Received hop and the authentication verdicts in order, newest first, since each hop a message passes through adds its own line above the ones before it. For the Authentication-Results line on its own, the Authentication-Results header explainer reads each method's verdict and the domain it was about.

Mail delivered through Microsoft 365 carries one more thing: a compauth= result that is Microsoft's own addition, not part of any standard. Microsoft's documentation is explicit that "despite a compauth failure, the message might still be allowed if other assessments don't indicate a suspicious nature" - so compauth=fail on its own is not proof a message was blocked. The three-digit reason code next to it is the useful part. Two worth knowing by number, from Microsoft's own documentation:

• 001 - the message failed implicit authentication because the sending domain had no published authentication records at all, or had only a weaker policy (an SPF ~all/?all, or a DMARC p=none).
• 601 - the message failed because the sending domain is one of your own organisation's accepted domains, which usually means something inside your own tenant is spoofing itself.

A code that is not in Microsoft's published table is one they have not documented; guessing at its meaning is how a header gets read backwards.

What order should I fix SPF, DKIM and DMARC in?Copy Anchor Link

SPF first, then DKIM by provider, then move DMARC enforcement up only once both report clean.

1. Fix SPF first. It is the cheapest change and breaks nothing else while you make it: publish the record, confirm it resolves under the 10-lookup ceiling, and flatten only the includes that are actually pushing you over it.
2. Fix DKIM next, one provider at a time. Use the fixed selector or CNAME pattern each provider documents - the table above - rather than guessing, and confirm signing is actually switched on in that provider's own console, since no checker here can see that.
3. Publish DMARC at p=none and watch, before enforcing anything. This collects aggregate reports without rejecting or quarantining any mail. We do not yet have a tool that reads those aggregate reports - a DMARC aggregate report reader is planned but not built, so for now reading them means opening whatever your rua address receives directly.
4. Move to p=quarantine, then p=reject, only once the reports show nothing legitimate is failing. Enforcing before that point risks blocking your own mail, which is exactly what the monitoring step at p=none exists to prevent.

If you are provisioning Google Workspace or Microsoft 365 mailboxes for clients, our mailbox licences product covers the licence side of this; DNS records, including the ones this guide walks through, still have to be published separately, since licence provisioning does not configure DNS. For the domain side, see how many domains and mailboxes cold email infrastructure needs.