Authentication-Results (SPF, DKIM, DMARC) — Forensic Artifact Reference (E-mail)

01Location

The header block of the raw message, added by the receiving administrative domain
Mail service message trace and security portal views, which may show the same results in another form

Which domain passed SPF and DKIM, and does that domain match the one in the From field?
Which system recorded these results, and is it inside the organisation's trust boundary?
Did DMARC pass because an aligned identifier passed, and which one?

Format	Authentication-Results: <authserv-id>; <method>=<result> [reason or comment] [ptype.property=value] ... One field can hold several methods. Example from the standard: spf=pass smtp.mailfrom=example.net.
Applies to	RFC 8601 defines the field; RFC 7489 registers the dmarc method (ptype header, property from). Providers add further fields and comment text of their own.

Field	What it tells you
authserv-id	Identifies the authentication service that ran the checks. The administrative domain guarantees that it is unique, and consumers use it to decide whether to trust the field.
spf, smtp.mailfrom / smtp.helo	SPF outcome and the identity checked: the MAIL FROM mailbox or the EHLO/HELO name.
dkim, header.d / header.i	DKIM outcome and the signing domain (d tag) or signing identity (i tag) taken from the DKIM-Signature field.
dmarc, header.from	DMARC outcome and the domain of the From field it was evaluated for.
Result values	For SPF and DKIM: none, pass, fail, policy, neutral, temperror, permerror (SPF also softfail). policy: local policy found the result unacceptable (SPF: the client was authorised; DKIM: some aspect of the signature was not acceptable).
reason, comment	Free text after the result; wording differs between providers.

Find every Authentication-Results field and the Received line beside it. A trustworthy field sits above the Received line added by a server of your own organisation.
Check that the authserv-id is your own system. Fields from other systems may have been written by the sender.
For each pass, write down the domain it refers to (smtp.mailfrom, header.d) and compare it with the From domain and with the recipient's domain.
Look at the DKIM-Signature field itself (d, s, a tags) and the sender domain's published records if the question needs them. Date the lookup, since records change.
Report what each mechanism established in its own words: which identity, checked by which system, with which result. Avoid summarising the set as 'authenticated'.

RFC 8601 states that a pass does not make a message trustworthy: spam or malicious mail can pass several checks, for example when signed by the sender's own domain.
A malicious sender can forge the field using the receiving domain as the authserv-id. The standard asks border servers to remove such fields, and an unfiltered field should not be trusted.
DMARC passes only when SPF or DKIM passes for an identifier aligned with the From domain. A pass for another domain does not satisfy it.
Results describe the moment of delivery. Records and keys may have changed since, and a forwarded message can fail checks it once passed.