An email header is a collection of fields written by different systems at different times. Some fields express the sender's own claims; others report what a receiver observed. A useful investigation identifies who could have written each important field before deciding what it proves. A pasted header analyser cannot establish that provenance from text alone.
Preserve a complete original
Obtain the original message through the receiving system's supported export method when authorized. Retain the original bytes separately from an annotated working copy. Screenshots, forwarded copies and copied header fragments can omit duplicate fields, alter line folding or add new transport events. Record the source mailbox, collection time and the limits of access without unnecessarily distributing message content.
Preserve duplicate fields and their order. Reading two Received or Authentication-Results fields establishes what the exported message contains, not who wrote either field. A successful parse is not an authentication check.
Identify the trusted receiving boundary
Use administrator knowledge, gateway configuration and delivery logs to establish which systems handled the message inside the trusted administrative domain. Locate the authentication results those systems generated or explicitly trust. A familiar authserv-id string is insufficient if an external sender could insert the same string and the receiving boundary failed to remove or distinguish it. RFC 8601 sections 1.2 and 7.
Then connect the selected results to their evaluated identities. SPF concerns the SMTP identity used in that evaluation; DKIM identifies a signing domain; DMARC relates authenticated identifiers to the visible From domain. Do not substitute Reply-To, Sender or Message-ID for those inputs. A pass is a bounded domain-authentication result, not proof that the message is harmless or that its business request is legitimate.
Read the transport trail with a stopping point
Received fields are normally prepended as mail moves through SMTP systems. Read the trusted portion from the newest entry toward earlier hops, then stop treating the chain as established when you cross into untrusted supplied material. Correlate the connecting address, queue identifier and time with the receiving system's logs. An older claimed hop can be fabricated even when a later trusted hop genuinely received the message. RFC 5321 section 4.4.
If an earlier hop cannot be corroborated, preserve its text as a claim rather than extending the verified route through it. The presence of a later trusted receiver does not authenticate all pre-existing trace information.
Produce a short evidence-led conclusion
State the observed receiving source, trusted authentication outcome, relevant identity differences and unresolved gaps. For example, explain that the selected receiving result reports failure for the visible author domain, while an unrelated supplied result claims pass. Do not silently choose the favorable result. Where provenance is unavailable, label the conclusion conditional and ask for the original receiver evidence before taking a consequential security or business action.
Work through a hypothetical invoice review
Suppose an authorized original export displays From: accounts@brand.example and Reply-To: help@different.example. It also contains a receiver report of DMARC fail and an unrelated supplied report claiming pass. These are invented observations, not a captured incident.
First establish which report the real receiving system generated. If its logs and documented boundary corroborate the failure report, retain that reported outcome and exclude the unrelated pass claim. If provenance cannot be established, say trusted authentication is unknown rather than choosing the preferred result. Next confirm the unusual reply destination through an established contact or approved workflow before sending sensitive information.
The outcome is not a declaration that the sender is fraudulent. It is a bounded review: known message source, supported authentication result or explicit uncertainty, unexplained reply destination and a justified next check. No parser, verifier, mailbox or payment request was tested here.
Write a decision-ready header summary
- Source: identify the authorized original export and collection time.
- Trust: name the receiving system and corroborating logs or documented boundary.
- Identities: record From, evaluated SPF identity and DKIM signing domain separately.
- Scope: distinguish reported authentication from content safety and business authority.
- Next action: resolve the smallest evidence gap before changing DNS or responding to a sensitive request.