How do I preserve and interpret a complete email header?¶

title: How do I preserve and interpret a complete email header? subtitle: Preserve the original message first, then identify the first trace record added by infrastructure you trust. slug: how-do-i-preserve-and-interpret-a-complete-email-header series: email-evidence section: technical-interpretation pathway_order: 14 section_order: 1 status: draft public_safe: true video_ready: true sources: - 'RFC 5321: Simple Mail Transfer Protocol' - 'RFC 5322: Internet Message Format' - 'RFC 6376: DomainKeys Identified Mail' - 'RFC 7208: Sender Policy Framework' - 'RFC 9989: Domain-based Message Authentication, Reporting, and Conformance' content_type: spoken_script branch: Email evidence

How do I preserve and interpret a complete email header?¶

Preserve the original message first, then identify the first trace record added by infrastructure you trust.

Script¶

You’ve been given an email and want to work out where it came from. Before interpreting the header, preserve the complete original message.

A screenshot, printout or forwarded copy may show what the recipient saw, but it may lose the technical information needed to understand routing, authentication, attachments and message structure.

The preferred evidence is usually the original message exported in a format that retains the full source, such as an EML file, or an appropriate mailbox export made through the organisation’s normal evidence process.

Preserve the original in the mailbox where possible, the complete raw header, the message body, plain-text and HTML versions, attachments, embedded content, the mailbox and folder where it was found, the account or tenant details, the acquisition time and method, and any integrity record required by local procedure.

If somebody needs to send the message to you, attaching the original message file is usually better than pressing Forward. Forwarding creates a new email. It may quote the visible text while losing or changing parts of the original structure.

Once the message is preserved, identify the trust boundary.

An email header contains fields created by different systems. Some are supplied by the sender or the sender’s software. Others are added by mail servers as the message moves through the delivery process.

A hostile sender can place false-looking fields into a message before it reaches a genuine provider. So you can’t simply find the bottom Received line and call the IP address there the sender’s address.

Each mail server normally adds its own Received field at the top of the existing chain. That means the newest hop appears near the top and earlier claimed hops appear further down.

Start with infrastructure you know belongs to the recipient or their provider. Work down through the Received fields while the systems can be identified. Find the first trusted server that accepted the message from outside that environment.

Its record of the connecting system, IP address and time is often the most useful boundary.

Anything below it may still describe genuine earlier routing. It may also contain values inserted before the message reached trusted infrastructure.

Now interpret each field for the narrow question it answers.

The visible From field is the address shown to the recipient. It can be spoofed.

Reply-To tells the email client where replies should go. A difference between From and Reply-To can be relevant, but legitimate mailing systems also use different addresses.

Return-Path usually reflects the envelope return address used for delivery failures. It isn’t necessarily the same as the visible sender.

Message-ID is intended to identify a particular message version. It can help match records across systems, but it doesn’t prove authorship.

The main Date field usually comes from the sender’s system. It may be wrong because of clock settings, timezone errors or manipulation. Timestamps added by trusted receiving systems may provide stronger evidence of when the message was handled.

Authentication-Results may contain SPF, DKIM and DMARC results. Trust those results only when they were added by a receiving system whose behaviour you understand. A sender can insert a fake-looking Authentication-Results line before delivery.

SPF checks whether the connecting server was authorised to use a particular envelope-sender domain. An SPF pass doesn’t prove the visible From address is genuine or that a named person sent the message.

DKIM checks a domain-controlled signature over the signed body and selected headers. A valid signature can support that the signed material hasn’t changed in a way that breaks the signature since it was signed. It still doesn’t identify the individual who wrote the email.

DMARC checks whether authenticated SPF or DKIM identifiers align with the domain shown to the recipient. A pass is useful domain-level evidence. It isn’t proof of human authorship.

Preserve the MIME structure as well. The message may contain separate HTML and plain-text bodies, embedded objects and attachments. What the mail client displays is only one rendering of the underlying message.

Work through the evidence in a controlled order. Preserve the original. Identify the recipient’s genuine mail systems. Find the first trusted external handover. Record the connecting server, IP address, time and protocol. Compare From, Reply-To, Return-Path and authentication results. Then seek provider-side message trace, account audit and access records where available.

The common mistake is to turn one technical field into a person.

“The recipient’s provider recorded this message as arriving from this mail server and IP address at this time” may be accurate.

“This IP address proves the suspect wrote the email” usually isn’t.

If the question is which mail system delivered the message, the trusted Received chain may answer it.

If the question is which account sent it, you may need provider records.

If the question is which device or person composed it, the header alone will rarely be enough. Look for account access, device evidence, drafts, browser or application data, recovery information and other corroboration.

A complete email header is a route map with conditions attached. Preserve it properly, trust only the fields added by systems you can identify, and keep each conclusion within what that field actually shows.

A complete email header can show how a message was handled, but it rarely proves who composed or sent it without supporting provider, account or device evidence.

Related questions¶

• Which Received line can I trust?
• Can an email header identify the sender?
• What do SPF, DKIM and DMARC actually prove?
• What can I do with an IP address found in an email header?