RFC 8601 — Authentication-Results

RFC 8601 defines the Authentication-Results header field. If you have ever opened a message’s source to find out why DMARC failed, this is the document describing what you were reading.

It is probably the most-encountered specification on this list, and the least often cited.

What one looks like

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=yourdomain.com;
  dkim=pass header.d=yourdomain.com header.s=google;
  dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=yourdomain.com

Read left to right: the authserv-id (mx.example.net) says which server performed the checks, then one clause per method with its result and the properties it was evaluated against.

The properties matter more than the results. dkim=pass header.d= tells you which domain signed — and if that is your email provider rather than you, the signature is valid and still fails alignment. Likewise spf=pass smtp.mailfrom= names the envelope domain, not the visible From:.

Why you cannot trust one you did not add

The header is plain text with no signature. Anything upstream can write one, and a forged Authentication-Results claiming dmarc=pass costs an attacker nothing.

The rule the RFC is explicit about: a receiver must delete any Authentication-Results header bearing its own authserv-id before adding its own. You can trust the header your own boundary added. Everything above it in the stack is hearsay, which is exactly the problem ARC tries to address for legitimate intermediaries.

Where you will meet it

In raw message source, and in the reasoning behind aggregate reports — the report tells you a source failed DMARC, the header on an actual message tells you which mechanism and against which identifier. When a report is confusing, finding one real message and reading its Authentication-Results is usually faster than any amount of theorising.

Read it: rfc-editor.org/rfc/rfc8601