Treat a header as a set of claims with different authors
An email-header analyser should not award trust to every field that contains the word pass. Headers combine user-selected identities, transport trace fields, signatures and assertions added by different systems. The analyst's first task is to identify who could have supplied each claim and which system's authority the reader is prepared to accept. Without that boundary, a neat summary can make forged text look like evidence.
This is a guide to a proposed analyser, not a working EmailAuth feature. No customer header, mailbox or message was accessed. The commissioning implementation gate is explicitly open: Implement and test the promised function. An article, mock-up or specification alone is not a working tool.
Preserve a raw original and a separate display view
An authorized investigation should begin with the original received message or raw header export and a record of its source. Preserve field order, repeated fields, folding and the original bytes. A user-interface screenshot or forwarded quotation may omit important structure. Generate an annotated or redacted view as a derivative, retaining a controlled link to the original when its storage is justified.
RFC 5322 defines header fields and folding, but parsing a field correctly does not authenticate its author. Keep a parser warning for malformed or ambiguous input instead of silently repairing it into a confident verdict. A header-only import also lacks the message body needed for full DKIM verification. State that limitation before presenting any cryptographic-sounding result. RFC 5322 and RFC 6376.
Establish the receiving environment's trust boundary
Authentication-Results contains an authentication service identifier and method results. To use it, determine which service is trusted to produce assertions for this mailbox or message path, and how the receiving environment handles incoming copies of that field. A familiar-looking authserv-id string is not proof of provenance; an external sender can type the same string.
RFC 8601 makes trust a property of the producer-to-consumer context rather than a universal list of trusted hostnames. A tool cannot infer that context from the header text alone. It should accept a separately established environment profile or leave the assertion untrusted. If the message left and re-entered the boundary, or appears inside an attached message, do not assume the outer receiver endorses the embedded results. RFC 8601.
Trace fields can help reconstruct where a message travelled, but they also need provenance. Identify the portion added by the trusted receiving infrastructure before interpreting earlier Received entries. Do not treat position alone, a reverse hostname or a long chain as proof that all preceding systems are genuine. Where timestamps disagree, retain the discrepancy instead of rewriting it into an exact travel timeline.
Keep the identities in separate columns
The visible From field expresses the author identity, while Reply-To is a reply destination and may differ. The SMTP envelope identity used for SPF is another value, and a Return-Path field must be interpreted in its delivery context rather than equated automatically with the visible author. DKIM's d= value identifies a signing domain, and s= selects its key. Similar-looking domains are not interchangeable identities.
A proposed annotation should show the raw field, parsed value, asserted role and evidence source for each identity. Avoid allowing a friendly display name to hide the actual address domain. SPF's evaluation inputs and DKIM's signature fields come from their respective protocols; neither is established merely because the From address matches a brand. RFC 7208 and RFC 6376.
Explain conflicting results without choosing the nicest one
Several Authentication-Results fields can describe checks performed by different systems at different stages. One might report an upstream pass while the final receiver reports a later failure. Preserve both assertions with their source and trust status. Do not combine SPF from one untrusted field with DKIM from another to manufacture a final DMARC verdict.
Current RFC 9989 requires the relevant successful authentication to align with the author domain. A passing result for an unrelated identity can coexist with DMARC failure. Forwarding and message modification can also change what a later evaluator observes. The analyser should distinguish a receiver's reported decision from its own explanatory inference and avoid promising that headers reveal every cause. RFC 9989.
Minimize exposure when importing and sharing
Headers can disclose addresses, internal hostnames, routing information and message identifiers. Import only material the user is authorized to inspect, apply a declared retention purpose and obtain approval before uploading it to an external analyser. A redacted screenshot suitable for a ticket is not necessarily suitable for cryptographic re-verification. Keep those purposes separate.
Render imported values as untrusted text, not executable markup or instructions. Bound input size and field counts, reject unsupported structures safely, and do not automatically visit URLs found in headers. These are proposed protective requirements, not tested capabilities. OWASP's file-upload guidance supports layered validation and safe storage rather than trusting an extension or declared content type. OWASP File Upload Cheat Sheet.
Produce an annotated explanation rather than a verdict badge
The intended output is a source map: trusted receiver assertions, untrusted inherited claims, user-controlled identities and unresolved provenance. For a fictional message, a forged Authentication-Results line saying dkim=pass would remain untrusted until its origin was established. That example illustrates a decision rule; no malicious message was processed here.
The exact original-evidence gate remains: An annotated raw header marking trust boundaries and the origin of every identity and verdict. No real annotated header or tested parser is supplied. Public sources were reviewed on 8 November 2026, including current DMARC guidance. Independent checking, human messaging and privacy review, implementation fixtures, visual validation and owner publication approval are still required.