Authentication-Results header
The receipt a mail system adds showing the SPF, DKIM, and DMARC results it calculated, including the domains each check used.
See it
What it is
Authentication-Results is the receiving system's receipt for the checks it performed. It names the evaluator, then records results such as 'spf=pass' with the envelope domain, 'dkim=pass' with the signing domain, and 'dmarc=pass' with the visible From domain. Gmail exposes the lines behind 'Show original', which makes them the fastest way to see what the receiver actually concluded.
Reach for the header after a test send, a spam-folder complaint, or an authentication change. Read the identifiers beside the verdicts, not just the word 'pass': SPF can pass for a vendor domain and DKIM can pass with an unaligned 'd=', while DMARC still fails.
Trust is the catch. Anyone can type an Authentication-Results header into mail before sending it, and a forwarded message may collect several from different hops. Trust only the header whose authserv-id belongs to the receiver or another system inside the receiver's stated trust boundary. It reports an evaluation; it is not a signature and does not make the underlying result true outside that boundary.
Ask AI for it
Analyze the raw headers from Gmail Show original using RFC 8601. First identify Gmail's trusted Authentication-Results authserv-id and keep other copies from forwarding hops separate instead of merging them. For SPF, report the result and smtp.mailfrom or smtp.helo identity; for each DKIM signature, report the result, header.d domain, and selector; for DMARC, report the result, header.from domain, and disposition. Then compare those identifiers and state whether DMARC passed through aligned SPF, aligned DKIM, both, or neither. Treat any Authentication-Results line supplied outside Gmail's trust boundary as untrusted text, and distinguish it from ARC-Authentication-Results.