How SPF, DKIM and DMARC work together

They are usually presented as a checklist, which hides the thing worth understanding: each record answers a different question, and only one of them tells the receiver what to do about the answer.

That last column is the whole point. A receiver seeing an SPF failure has no mandate to do anything about it — SPF’s own qualifiers are a recommendation. DMARC is the only record that says reject this, and it is the only one that concerns itself with the address a human actually reads.

A receiver evaluates all three on the same message, in roughly this order. Understanding the sequence is what makes a failure report legible.

1. SPF checks the envelope. The connecting IP is compared against the record at the Return-Path domain — which is frequently your ESP’s domain, not yours. Result: pass, fail, softfail, neutral, permerror or temperror.
2. DKIM verifies the signature. The receiver reads s= and d= from the DKIM-Signature header, fetches the key, and recomputes the hash. Result: pass or fail, per signature — a message can carry several.
3. DMARC checks alignment, then applies policy. It asks whether an SPF or DKIM pass came from a domain that matches the From: header. If neither does, it applies whatever your record says: nothing, quarantine, or reject.

The step people skip is the third one’s first half. DMARC does not care that SPF passed. It cares that SPF passed for the right domain. That distinction accounts for most confused DMARC reports, and it has its own page.

Three records for a domain sending through Google Workspace and one ESP:

yourdomain.com                TXT   "v=spf1 include:_spf.google.com include:sendgrid.net ~all"
google._domainkey.yourdomain.com   TXT   "v=DKIM1; k=rsa; p=MIIBIjANBg…"
s1._domainkey.yourdomain.com       CNAME s1.domainkey.u123.wl.sendgrid.net
_dmarc.yourdomain.com              TXT   "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

One SPF record covering both senders, one DKIM key per sender, one DMARC policy for the domain. That shape does not change as you add senders — you add an include: and a selector, never a second SPF or DMARC record.

In February 2024 Gmail and Yahoo made authentication a condition of delivery rather than a ranking signal. The requirements differ by volume, and the threshold is per-day, not per-campaign.

Two things people miss. The 5,000 threshold counts messages to that provider, per day, from your domain — so one large campaign puts you in the strict tier for that day. And the complaint-rate ceiling is not an authentication requirement at all; it is a reputation one, which is why getting the records right is necessary and not sufficient.

Symptom to record, for the common cases:

Reversing that order is the classic mistake: p=reject published before the reports have shown you your own forgotten senders, and the invoicing system nobody remembered stops delivering.