An email looks like a simple object: sender, subject, text, maybe attachments. In reality every message carries a set of technical information, the headers, that tells where it came from, which servers it passed through and whether the sender's domain authorised it. Knowing how to read them lets you tell an authentic message from a forged one and preserve it properly as evidence.
The visible sender proves nothing
The name and address shown in the "From" field are chosen by whoever sends the message. Technically any address can be written there, and many scams rely on exactly that. To understand who really sent an email you need to look further, at the full headers.
Every mail program lets you view them, under options such as "show original", "view source" or "message properties".
The main fields
Received
Each server that receives and forwards the message adds a Received line at the top of the headers. They are therefore read from bottom to top: the lowest line is the one closest to the origin. Each line usually shows the delivering server, the receiving server, the time and sometimes the IP address.
Lines added by the recipient's servers are the most reliable. Those further down could have been inserted by the sender and should be treated with caution.
Message-ID
This is a unique identifier assigned to the message, usually by the sending server or program. Its format and the domain it contains may or may not be consistent with the stated sender. A message claiming to come from a major mail service but carrying a Message-ID with an unusual structure deserves attention.
Date
This is the date and time declared by the sender. It should be compared with the times in the Received lines: large differences may point to a wrong clock or to tampering.
Return-Path and Reply-To
Return-Path shows where undelivered messages are returned; Reply-To shows where replies will go. If Reply-To points to an address different from the sender's, especially in a payment request, it is a typical sign of fraud.
SPF, DKIM and DMARC
These three mechanisms let a domain owner declare who is allowed to send mail on its behalf. The results of these checks often appear in a header called Authentication-Results.
| Mechanism | What it checks | Useful result |
|---|---|---|
| SPF | That the sending server is authorised by the domain | pass |
| DKIM | That a cryptographic signature on the message is valid | pass |
| DMARC | That SPF or DKIM align with the domain visible in "From" | pass |
A valid DKIM signature is particularly interesting forensically: it shows that the signed parts of the message, typically some headers and the body, have not been changed since sending, and that the message passed through a server holding the domain's key. Keys are replaced over time, however, so it is best to verify the signature as soon as possible and document the result.
How to preserve an email as evidence
Forwarding a message to another mailbox or printing it to PDF loses most of the original headers. The correct way is:
- export the message in its original format, usually an .eml file, or .msg for some programs;
- calculate the hash of the exported file;
- keep a readable printout as well, but only as a support;
- record which mailbox, which program and when it was exported;
- if possible, leave the message in the original mailbox too, without moving or changing it.
For the most important cases, acquiring the whole mailbox can be considered, which makes it possible to check the message's consistency with the rest of the correspondence.
Signs of possible forgery
- a sender domain similar but not identical to the real one, for example with a swapped letter;
- SPF, DKIM or DMARC failing for a domain that normally passes them;
- a Reply-To different from the sender;
- Received lines inconsistent in times or server names;
- a Message-ID in a format different from the usual one for that service;
- attachments with double extensions or names imitating official documents.
None of these elements alone proves forgery. It is their combination, read in context, that leads to a well-founded conclusion.
In short
- The "From" field can be forged: the real origin is in the headers.
- Received lines are read bottom to top, trusting the recipient's lines most.
- SPF, DKIM and DMARC show whether the domain authorised the sending.
- Preserve an email in its original format with a hash, not forwarded or printed.
- Anomalies should be assessed together, not one by one.