Reading the Authentication-Results header — Email Authentication Fundamentals

When a receiving server finishes its checks, it records what it found in a header. Being able to read that header is the single most useful diagnostic skill in this course, because it turns "the message went to spam" into a specific, nameable failure.

The header

Authentication-Results: mx.recipient.org;
    spf=pass (recipient.org: domain of bounces@example.com
        designates 203.0.113.25 as permitted sender)
        smtp.mailfrom=bounces@example.com;
    dkim=pass header.i=@example.com header.s=sel1;
    dmarc=fail (p=REJECT sp=NONE dis=NONE) header.from=example.com

Constructed to show every field in one place. Real headers vary in layout between providers but carry the same content.

Reading it left to right:

mx.recipient.org — the authserv-id: which system performed these checks. This matters more than it looks. See below.
spf=pass ... smtp.mailfrom=bounces@example.com — SPF passed, and crucially it tells you which identity it passed for. That is the envelope sender.
dkim=pass header.i=@example.com header.s=sel1 — a valid signature from the domain example.com using selector sel1.
dmarc=fail ... header.from=example.com — despite both of the above passing, DMARC failed. The next several modules explain how that is possible.

This header is only trustworthy inside the system that wrote it

Anyone can add an Authentication-Results header to a message before sending it. A receiving system is expected to strip headers bearing its own authserv-id on arrival, precisely to prevent an attacker forging a pass — RFC 8601 §5 is explicit about this. So the authserv-id is not a decoration: it is how you know whether the header was written by the system you trust or by whoever sent the message.

The results that matter

Result	Means	Usually indicates
pass	The check succeeded.	—
fail	The check ran and the message did not satisfy it.	A real configuration problem, or a forgery
softfail	SPF only: not authorised, but the domain is not asking for rejection.	A ~all record and a sender you forgot
neutral	The domain explicitly declined to assert anything.	A ?all record, which asserts nothing at all
none	There was nothing to check — no record published.	The control is simply not deployed
temperror	A transient failure, usually DNS.	Retry-able. Not a configuration error
permerror	The record is unusable.	Malformed syntax, two SPF records, or the lookup limit exceeded

The distinction worth internalising now is none versus fail. A result of none means the domain published nothing, so the receiver learned nothing. A result of fail means the domain published something and this message contradicted it. The first is an absence of evidence; the second is evidence.

Getting at it

Every major client can show full headers, though all of them hide the option somewhere different. In Gmail it is "Show original"; in Outlook, "View message source"; in Apple Mail, View → Message → All Headers. Send yourself a message from an outside account and read the result — you will get more from the rest of this course if you have seen one real header before the protocols are explained.

Knowledge check

A message arrives with spf=none and dkim=pass. What have you learned about the sending domain?

The domain has no SPF record, and a valid DKIM signature was verified for some domain.
SPF failed and DKIM compensated for it, so the message is authenticated.
The message is spoofed, because a legitimate sender would publish SPF.
Nothing, because the Authentication-Results header can be forged.

Correct — The domain has no SPF record, and a valid DKIM signature was verified for some domain. Both halves matter. spf=none says nothing was published to check against — an absence of evidence, not a failure. dkim=pass says a signature verified, but on its own it does not tell you the signing domain is the one in the From header; that is what header.i records and what alignment will test later.

Not this — SPF failed and DKIM compensated for it, so the message is authenticated. spf=none is not a failure — nothing was checked, because nothing was published. The distinction between "no record" and "record contradicted" is the most useful one in this table.

Not this — The message is spoofed, because a legitimate sender would publish SPF. A missing SPF record is a gap in a domain’s configuration, not evidence about any individual message. Plenty of legitimate domains publish no SPF, and the DKIM pass here is positive evidence in the other direction.

Not this — Nothing, because the Authentication-Results header can be forged. It can be forged in transit, which is why the authserv-id exists and why receivers strip headers bearing their own. Inside the system that wrote it, the header is exactly as trustworthy as that system.