SPF, DKIM and DMARC: what each one actually proves

Almost every deliverability thread eventually arrives at "check your SPF, DKIM and DMARC", as if they were three settings of the same dial. They are not. They answer three different questions, they fail in different ways, and two of them can pass while your mail still lands in spam. Knowing which one is which is the difference between fixing a problem and changing records at random until something moves.

SPF answers: was this server allowed to send?

SPF is a DNS record listing the servers permitted to send mail for your domain. The receiving server takes the envelope sender — the return path, not the From: header your recipient sees — reads its domain, fetches that domain's SPF record, and asks whether the connecting IP is in the list.

v=spf1 include:_spf.google.com ~all

That is the whole mechanism. It says nothing about the message, only about the connection. Two consequences follow, and both catch people out.

• SPF breaks on forwarding. The forwarding server is not in your record, so the check fails through no fault of yours. This is exactly why DKIM exists.
• SPF authenticates the return path, which is often not the address in the From: header. A message can pass SPF while displaying someone else's name.
• The record is limited to ten DNS lookups. Every include: counts, and nested includes count too. Exceed it and the result is permerror, which most receivers treat as a failure.

DKIM answers: was this message altered?

DKIM signs the message. Your sending server hashes a set of headers plus the body, signs the hash with a private key, and attaches the result as a DKIM-Signature header. The receiver reads the selector and domain from that header, fetches the matching public key from DNS, and verifies.

google._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

Because the proof travels inside the message, DKIM survives forwarding — the signature is still valid three hops later. It also proves the body was not modified in transit, which SPF cannot. What it does not prove is that the signing domain has anything to do with the From: address. Anyone can sign their own mail with their own key; a valid signature only means "this domain vouches for this message", not "this message is from who it claims".

DMARC answers: do the passing checks belong to the visible sender?

DMARC is the piece that ties the other two to the address your recipient actually reads. It introduces alignment: the domain that passed SPF, or the domain that signed with DKIM, must match the domain in the From: header. One aligned pass is enough.

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

This is why a message can pass SPF and DKIM and still fail DMARC. A shared sending platform may pass SPF on its own bounce domain and sign with its own key — both green, neither aligned with your From: domain, so DMARC fails. It is also the single most common cause of the confused report where "everything passes" and nothing is delivered.

Reading a report that says you are failing

Aggregate reports arrive as XML at the rua address, one per receiver per day. They are unpleasant to read raw, but the shape is simple: a row per sending IP, with counts and the SPF/DKIM results including whether each aligned. Work in this order.

1. 1Find the rows with volume you do not recognise. That is either a forwarder, a service someone signed up for, or actual spoofing.
2. 2For rows you do recognise that fail, check alignment before anything else. A pass that is not aligned is the usual answer, and it is fixed by configuring the sender to sign as your domain rather than its own.
3. 3Only once every legitimate source is aligned should you move p=none to p=quarantine, and then to p=reject. Moving early does not make you safer; it makes your own mail disappear.

Google and Yahoo have required DMARC for bulk senders since February 2024, so p=none with a working rua address is now the floor rather than the goal. But the sequence has not changed: publish, observe, align, then enforce.

The short version

• SPF authorises the server. Breaks on forwarding. Ten-lookup limit.
• DKIM authenticates the message. Survives forwarding. Breaks when the body changes.
• DMARC requires one of them to align with the visible From: domain, and tells you when it does not.

OutreachPro checks all three for a domain before you send from it, and shows you which one is failing rather than a single red cross — because "authentication failed" and "DKIM is signing as the wrong domain" are not the same problem.