An email contains several identities, and they answer different questions. The SMTP envelope directs transport, author-supplied headers describe the message, receiving systems add trace information, and authentication evaluators report their findings. A convincing display name or a line saying pass is not sufficient provenance. Start by identifying which system created each value and which parts your organization can actually trust.
Distinguish envelope from content
MAIL FROM and RCPT TO belong to the SMTP transaction. They need not match the visible From and To headers. A bounce address, mailing list, alias, blind-copy recipient or forwarding rule can make the difference legitimate. The recipient set used for delivery is not reconstructed simply by reading To and Cc.
The final delivery system records the reverse path in Return-Path according to RFC 5321. That header is evidence about the envelope at delivery when its insertion boundary is trusted; it is not a universal certificate of the original author's identity. Forwarding can rewrite the envelope between hops, so compare the relevant transaction rather than assuming one address persisted throughout the route.
Attribute the visible fields
From identifies the message's author field under RFC 5322. Sender, when used, identifies the agent responsible for transmission in the field's defined sense. Reply-To supplies a suggested reply destination. Date and Message-ID assist interpretation and correlation, but they are not independently authenticated merely by appearing in the message.
DKIM verification may authenticate signed header content relative to a signing domain. It does not turn every unsigned field into verified evidence or establish that the human named in From authorized a business transaction. Inspect which signature passed, its d domain and the signed-header list. DMARC alignment concerns the visible From domain and the relevant authenticated SPF or DKIM domain, not a matching Reply-To or Message-ID.
Establish the receiving boundary
Receiving SMTP servers prepend Received trace fields. Read the trace with knowledge of the systems your organization operates and the external boundary they observed. Earlier or externally supplied trace text can be misleading. Likewise, RFC 8601 defines Authentication-Results within an understood trust boundary; an attacker can insert a header that looks like a favorable result.
Consider a hypothetical message with two Authentication-Results fields: one claims to be from receiver.example and another claims to be from forged.example. Neither label proves its own origin. Trust the first only if the receiving service’s documented boundary and logs establish that its authorized verifier inserted it; otherwise mark its provenance unresolved. The second is not evidence of authentication merely because it contains pass.
Turn the map into an investigation
For each relevant identity, record the value, source system, observed hop, trust basis and question it answers. The visible author domain answers a different question from the authenticated submission account or envelope bounce domain. Keep original bytes in restricted evidence storage and use a redacted working copy for routine discussion. Redaction can invalidate DKIM, so preserve the untouched original when verification is required.
Compare the header map with SMTP logs and trusted receiver results. In a hypothetical billing route, MAIL FROM is bounce@vendor.example while From is invoices@brand.example. The difference can be legitimate. A verified DKIM signature with d=brand.example can provide exact alignment even though the envelope domain differs. Assume an applicable DMARC policy and no unresolved evaluation error; no actual provider, signature or message was tested here.
Finish with a conclusion tied to the evidence: which domain authenticated, what route was observed and which authorization questions remain open. Do not collapse those findings into a claim that every field or requested action is trustworthy.
Use a five-column provenance note
- Value: copy the exact field or envelope identity from the original evidence.
- Producer: identify which client, relay, delivery service or verifier supplied it.
- Hop: record the transaction or receiving boundary where it was observed.
- Trust basis: explain why that system’s record is trusted, or label it untrusted.
- Meaning: state the question the value answers, and which identity or business authorization it does not prove.