An inbox screenshot rarely contains enough evidence to diagnose an authentication problem. Start with the exact received message in the affected mailbox. Preserve when and where it was obtained, then collect the full original-message view. This keeps a later analysis tied to the actual copy that produced the reported experience.
Obtain the message-level evidence
References: RFC 6376 §3.7.
Google's browser instructions are to open the email, use More beside Reply, choose Show original and copy the full header. Choose the affected message rather than a different item in the same conversation. Save the available original-message artifact separately when a byte-preserving export is available; a copied header alone does not include everything needed to reverify DKIM. Gmail header instructions.
Record mailbox context, collection time and whether the artifact is a raw export, copied text or screenshot. An analyst should know if line endings, folding or MIME content may have changed during collection. Do not forward the message inline and describe the resulting new message as an untouched original.
Read identities as well as outcomes
References: RFC 8601 §5.
Google explains that the mailed-by and signed-by information can help inspect authentication, while an unauthenticated message is not automatically spam and an authenticated message is not automatically safe. Treat the visual indicators as an entry point, then retain the full evidence for technical analysis. Gmail authentication help.
In the trusted Authentication-Results field, preserve the SPF result and its evaluated identity, the DKIM result and signing domain, and the DMARC result and visible From domain. Do not combine results from unrelated hops into one imagined receiver verdict. A message may carry multiple signatures or authentication-result fields, so record their order and scope. RFC 8601.
Keep received evidence distinct from rechecking
References: RFC 6376 §3.6, RFC 6376 §6.
The receiver's result describes its evaluation at processing time. A local DKIM check today evaluates the bytes and key material available today. A key rotation, a changed DNS answer or a modified export can produce a different result without proving the original receiver was wrong. Header text records a claimed observation; it is not itself a new cryptographic verification. RFC 6376 sections 3 and 6.
The accompanying synthetic message has two Authentication-Results fields. The parser returns both rather than silently choosing the first. This is an extraction test, not a Gmail capture or a trust algorithm. In a real investigation, the receiving service and trusted route must establish which result is relevant.
Share the smallest useful artifact
References: RFC 8601 §7.
Keep the original restricted. Create a separately labeled diagnostic copy when full message contents or personal addresses are unnecessary. Preserve domain relationships and timestamps needed for the question, and disclose any edits. For signature verification, arrange an authorized secure transfer of the unmodified bytes rather than pretending a redacted copy can always be checked.
Google also describes an online header analyzer, but pasting evidence into any analyzer transmits it to that service. Review the recipient, data and organizational sharing rules before doing so. End with a clear statement of what was observed in Gmail, what was inferred and what remains untested.
Read the annotated sample without granting trust
References: RFC 8601 §5.
The retained annotation register lists every raw field in order with its actual generator, claimed origin and trust limit. From is an author-supplied identity; To is a displayed recipient rather than proof of the SMTP envelope. Message-ID, Date and Subject are sender-controlled context. Each Authentication-Results field claims a reporting service and result, but neither trusted.example nor untrusted.example establishes genuine receiver provenance. List-ID names the claimed list; the unsubscribe fields describe an action mechanism, not list ownership. In the classification sample, CAT, DIR, SCL and BCL are invented Microsoft-style verdicts, not observations from Microsoft. No Received chain, SPF envelope identity or connecting IP was established.
Use this map as an annotated teaching example. For a real message, replace each assumed origin with collection and receiver evidence, and leave any unverified boundary explicitly unresolved.