Email Forensics: Protocols, Headers and Spoofed Messages

SMTP handles message transfer, while submission and mailbox access serve different roles. Identify the actual protocol and negotiated protection from configuration or captured evidence, rather than infer plaintext or TLS solely from a port.

POP3 can leave copies on the server depending on settings. IMAP synchronises selected mailbox state and can cache only part of it. A provider API or webmail interface can use a different access path; modern Outlook variants need not produce traditional local containers.

TLS can conceal message contents from a passive network capture. Session endpoints, service logs and preserved messages can provide different evidence. An observed SMTP connection does not prove that a particular message was accepted or delivered.

Webmail can leave downloads, cached content, origin storage and account-related traces on an endpoint. Provider records may add information but are not the only evidentiary source.

A user agent may submit through a mail submission service, after which one or more transfer agents route the message toward a delivery service and mailbox. APIs and internal provider systems can alter the visible path; not every processing component adds an SMTP trace line.

DNS MX records guide normal domain delivery, but current DNS is not proof of historical routing. Retain relevant contemporaneous resolution or provider records where available.

SMTP servers prepend Received fields, so lower trace entries usually describe earlier claimed hops. Establish the receiver-controlled boundary first, then assess earlier claims. A bottom-up chronological reading does not authenticate the bottommost entry.

Transport logs can include queue identifiers, recipient processing, acceptance or failure status and authentication context under the actual logging policy. Preserve their time basis, coverage and retention. An accepted message is not automatically a message read by the recipient.

Preserve complete message bytes, including folded headers, MIME parts and attachments. A forwarded message or screenshot may omit or change important fields. Decode a copy and retain the original representation.

Identify trusted receiving infrastructure using provider configuration and logs. Inspect the trace fields that infrastructure added, then compare any preceding claims against independent information. Forged Authentication-Results or Received fields may already be present when a receiver accepts the message.

Use a chronological table of claimed hops, normalised timestamps, stated hosts and corroboration. Clock skew, relays, aliases and incomplete fields can explain apparent gaps; exact textual continuity is not a universal requirement.

An absent or private X-Originating-IP is not proof of spoofing or a particular NAT route. Many providers omit client addressing or expose only internal infrastructure. A transport IP identifies an observed connection endpoint, not automatically the human sender.

SPF evaluates an SMTP identity using the connecting IP and the applicable DNS policy. It does not authenticate the visible display name or every address in the message. Forwarding and policy errors can affect outcomes.

DKIM verifies a signature over selected headers and body representation under its canonicalisation and other parameters. It does not necessarily cover every displayed field or prove that the signer is the claimed human author. Missing keys, modification and configuration can affect verification.

RFC 9989 (May 2026) replaces RFC 7489 as the core DMARC specification. Implementations and historical records can follow different revisions; record the receiver context. DMARC evaluates alignment of the visible From domain with at least one passing SPF or DKIM identity. Both mechanisms need not pass. Published handling policy informs receiver decisions; it does not guarantee an identical disposition at every provider.

A message from an attacker-controlled lookalike domain can pass its own authentication checks. A legitimate forwarded message can fail some checks. Therefore authentication is one component of assessing impersonation, not a standalone maliciousness verdict.

Use trusted receiver-added results from the relevant delivery where available. Retesting against current DNS must be labelled with the test date and limitations; keys and policies may have changed since delivery. Do not upload confidential message content to a public checker without appropriate handling authority.

Analyse presented identity, actual address domains, reply destination, links, attachments and request context together. Distinguish display-name impersonation, lookalike-domain use, direct address spoofing and a compromised genuine account.

A Return-Path mismatch, tracking image, internationalised domain or missing authentication result can occur legitimately. Explain why a combination is relevant to this message rather than turn any one feature into automatic proof.

Compare displayed link text with the actual HTML destination on a safe analysis copy. Redirects and tracking services require contextual assessment. A destination in the message does not establish that anyone clicked it or submitted credentials.

Correlate any independently preserved click-side evidence using Web Browser Forensics. Keep a received lure, a navigation record and a completed account action distinct.

Legal definitions of fraud, impersonation and unauthorised access vary by jurisdiction. Describe the technical findings accurately and apply the relevant legal framework separately; a header anomaly does not establish every element of an offence.

Mailbox containers and individual-message files represent different acquisition units. Establish the client, version, account type and export method before assuming a local file holds the entire mailbox.

Preserve a consistent source copy and hash the acquired material. Parse an analysis copy with a format-compatible tool. Conversion can alter metadata or representation, so retain both the source and derived output with the conversion method.

Provider data can be obtained through authorised account access, organisational export or an appropriate legal process, depending on the case. Scope, preservation, disclosure and cross-border requirements vary by jurisdiction. A request cannot guarantee that deleted data or historical logs still exist.

Match message identifiers, queue IDs, recipients, sizes and timestamps across sources where available. A Message-ID alone is not globally unique proof of identity or content; compare the preserved records and explain discrepancies.

Record raw header values, trusted boundaries, decoded fields, attachment hashes, query/export settings and missing periods. Separate message delivery, mailbox access, human authorship and the substantive allegation.

Use a suitable validation method for important fields, including direct inspection of source records where practical. Two tools agreeing does not remove a shared parsing assumption. Certification and admissibility requirements belong to the applicable jurisdiction, not a universal email-processing checklist.