SPF, DKIM and DMARC: what each one actually proves

Three DNS records get mentioned in the same breath so often that they blur into one thing called “email authentication”. They are not one thing. They make three different claims, they are checked at three different moments, and two of them are almost useless without the third. Knowing which is which is the difference between fixing a deliverability problem and guessing at it.

The shape of the problem

SMTP was designed without any notion of who is allowed to send as whom. Anyone who can open a connection can write From: ceo@yourcompany.com and the protocol will carry it. Every authentication mechanism since is an attempt to bolt an answer onto that, from the outside, using DNS — because DNS is the one place a domain owner can publish something the whole internet can read and nobody else can forge.

So all three records are statements published by the domain owner and checked by the receiving server. Infrabox is neither of those parties. It publishes on your behalf, into the DNS zone for your domain, and then the receiver decides what it thinks.

SPF: which servers may send for this domain

SPF is a list of IP addresses and hostnames permitted to send mail for your domain, published as a TXT record. When a message arrives, the receiver looks at the connecting IP, fetches your SPF record, and asks whether that IP is on the list.

yourdomain.com.  TXT  "v=spf1 include:_spf.google.com ~all"

include:_spf.google.com delegates the actual list to Google, which is the only sane way to do it — Google’s sending IPs change and you do not want to be tracking them. ~all is a soft fail: anything not on the list is suspicious, not rejected outright.

Two things about SPF trip people up constantly:

• It checks the envelope sender, not the From header you see. The address SPF validates is the one in the SMTP MAIL FROM command, which the recipient never sees. A message can pass SPF perfectly while displaying a completely different From address. This is exactly the gap DMARC exists to close.
• It breaks on forwarding. When a mailing list or a forwarding rule relays your message, the connecting IP becomes the forwarder’s, which is not on your list. SPF fails through no fault of anyone. This is not a bug you can fix; it is why a second, unrelated mechanism exists.

There is also a hard limit worth knowing: a receiver is required to give up after ten DNS lookups while evaluating your record. Chain enough include: statements together — one per tool you have ever connected — and you exceed it, at which point the whole record errors out rather than degrading gracefully.

DKIM: this message was not altered after signing

DKIM takes a different approach entirely. Instead of asking where a message came from, it asks whether the message is intact. The sending server hashes a defined set of headers plus the body, signs that hash with a private key, and attaches the signature as a DKIM-Signature header. The matching public key sits in DNS.

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

google there is the selector — the label naming which key was used. The signature header carries the selector, so a receiver reads it, constructs the DNS name, fetches the public key, and verifies. Multiple selectors can coexist, which is how key rotation works without a gap.

What a DKIM pass actually tells the receiver is narrow and specific:

• the signing domain holds the private key matching a published public key, and
• the signed headers and body have not changed since that signature was made.

That is the whole claim. It says nothing about whether the message is wanted, whether the sender is reputable, or whether the content is true. A spammer can sign their mail with valid DKIM all day. What DKIM provides is a stable identifier — a domain that reputation can be attached to and that cannot be borrowed by someone else. Unlike SPF, it survives forwarding, because the signature travels inside the message rather than depending on the connection.

DMARC: tying the checks to the address people see

Here is the gap both previous records leave open. SPF validates the envelope sender. DKIM validates the signing domain. Neither of them is necessarily the From: header that the recipient actually reads. A message can pass both and still display someone else’s domain in the mail client.

DMARC closes that by adding a requirement it calls alignment: it is not enough for SPF or DKIM to pass, the domain that passed has to match the domain in the visible From header.

DMARC passes if either check passes and is aligned. That “either” is deliberate: it is what lets a forwarded message survive on DKIM alone when SPF has been broken by the hop.

_dmarc.yourdomain.com.  TXT  "v=DMARC1; p=none; rua=mailto:reports@yourdomain.com"

The p= policy tells receivers what to do with unaligned mail claiming to be from you: none (do nothing, just report), quarantine (treat as suspicious), or reject (refuse at the door). rua= is where aggregate reports get sent — that is the feedback loop, and it is the only way you will find out that some tool you forgot about has been sending unaligned mail as you for six months.

Starting at p=none is not weakness, it is sequence. You publish the record, read the reports until you recognise every source sending as your domain, and only then tighten the policy. Going straight to p=reject on a domain whose sending sources you have not inventoried is how organisations lose their invoicing email.

Which of these Infrabox publishes

Two steps of the provisioning pipeline do this work, and they are separate for a reason.

• The Workspace & DNS step writes MX, SPF and DMARC into your zone with the values Google expects. This is the step people most often get wrong by hand — a stray include: pushing you over the ten-lookup limit, or a DMARC record that was never published at all.
• The DKIM step generates the key, publishes the public half at the selector, and switches signing on for the domain. It is a separate step because it happens through Google’s Admin Console rather than an API, and it is the piece most cold-email setups skip precisely for that reason.

These are records in your domain’s zone. Section 4 of the Acceptable Use Policy asks you not to edit them, which is less about control than about the fact that a hand-edited SPF record is the single most common way a working setup stops working.

Reading a failure

When mail is landing badly, the useful question is not “is authentication set up” but “which of the three claims is failing, and at which hop”. Look at the Authentication-Results header on a message that actually arrived somewhere:

Authentication-Results: mx.example.com;
       spf=pass (sender IP is 209.85.x.x) smtp.mailfrom=yourdomain.com;
       dkim=pass header.d=yourdomain.com;
       dmarc=pass action=none header.from=yourdomain.com

Three verdicts, and each names the domain it judged. If dmarc=fail while both SPF and DKIM say pass, you have an alignment problem, not an authentication problem — something is signing or sending under a domain that is not the one in your From header. That is a completely different fix, and it is the one nobody finds without reading this header.