Email Forensics: A Guide to Headers, Spoofing and Finding the True Source
Email forensics technically examines who an email truly came from and whether it was altered. Why the sender address is not evidence, the Received lines in the header and how to read them, SPF DKIM DMARC results, how to collect it as evidence (raw .eml, hash) and common mistakes.
Quick answer: Email forensics is the technical examination of who an email truly came from, when and by what path it was delivered, and whether its content was altered. The visible "From" address proves nothing; the email protocol is open to forgery and an attacker can easily fake the sender address (spoofing). The real evidence is in the email's full header: the
Receivedlines showing every server the message passed through, the authentication results (SPF, DKIM, DMARC) and the uniqueMessage-ID. In a forensic examination a screenshot is weak evidence; the raw email (.eml) and its header should be collected with integrity recorded via a hash. A correctly read header often reveals the true source of a forged email.
The most common evidence in a fraud, threat or data leak investigation is email. But the most common mistake is judging an email at the surface: looking at the sender address and saying "this person sent it." Yet the sender address is as trustworthy as a name written by hand on an envelope. The real information is in the postmarks, that is, the email header. This article explains how email forensics is done.
Why the sender address is not evidence
The email protocol (SMTP) was designed in the 1980s, an era when no one thought about forgery. So there is no built in mechanism that verifies the sender address. An attacker can write any address in an email's "From" field, just as they could write someone else's name on an envelope. This is called email spoofing.
So when examining an email, you look not at the visible address but at how the message was delivered. Three mechanisms were later added to fight forgery (SPF, DKIM, DMARC), and their results are recorded in the header. For the corporate setup of these mechanisms, see our article on email security with SPF, DKIM and DMARC.
The email header: the real evidence
Every email carries a detailed header the user normally does not see. This is the heart of forensic examination.
| Header field | What it shows |
|---|---|
Received |
Every server the message passed through, read bottom to top. Shows the true source |
From |
The visible sender. Can be fake, not evidence alone |
Return-Path |
The address bounces return to, closer to the real sender |
Message-ID |
The message's unique identifier, from the sending server |
Authentication-Results |
SPF, DKIM, DMARC verification results |
DKIM-Signature |
The message's cryptographic signature, can prove content was unchanged |
Date |
Time of sending, should be consistent with the times in Received lines |
Reading the Received lines
The most valuable section is the Received lines. Each server adds a Received line at the top when it receives the message. So the lines are read bottom to top: the bottom one is the server the message first left.
When examining, you look at: does the bottom server truly belong to the claimed sender? Do the timestamps progress consistently, or do they go backward somewhere (a sign of forgery)? Are the IP addresses in the expected geography? An attacker can fabricate the top lines but cannot control the bottom lines added by the servers that actually relayed the message.
SPF, DKIM and DMARC results
The Authentication-Results in the header tells whether the message passed authentication:
- SPF (pass/fail). Is the sending IP one of the servers that domain permits?
- DKIM (pass/fail). Is the message signed with the domain's private key and is the signature valid? If DKIM passes, it also proves the content did not change in transit.
- DMARC (pass/fail). Are the SPF and DKIM results aligned with the visible From address?
An email where all three fail is a strong sign of forgery. But note: the absence of SPF or DMARC shows not that the email is definitely fake but that it cannot be verified. The forensic conclusion emerges from assessing the whole header together.
How it is collected as evidence
Presenting an email as a screenshot is weak evidence; a screenshot is easily edited. Correct collection:
- Take the raw form. Export the email as
.emlor.msgwith all headers and attachments. This is the original form of the message. - Compute a hash. Hash the collected file and record it. This is the proof of integrity.
- Document the source. From which account, when and how it was obtained must be recorded. For chain of custody, see our article on the forensic process and chain of custody.
- Request server logs. Where possible, the logs of the sending or receiving email server independently support the header analysis.
This process is critical in corporate fraud, especially business email compromise (BEC) incidents; for detail, see our article on business email compromise and fake transfers.
What to watch for
- Time consistency. The times in the Received lines should progress sensibly. Time going backward or jumping impossibly is a sign of forgery.
- Display name versus real address. Like "John Doe [email protected]," the display name can hide the real address.
- Similar domain. Deceptive domains such as
examplebank.coinstead ofexamplebank.com. - Attachments and links. The real type of an attached file (signature, not extension) and the real target of links are also examined.
- DKIM signature. A valid DKIM signature strongly proves the message came from a specific domain and was not changed.
Common mistakes
- Trusting the sender address. The From field is easily faked, not evidence alone.
- Settling for a screenshot. Without the raw .eml and header, the evidence is weak.
- Reading the Received lines top down. The correct direction is bottom to top.
- Not hashing. Email is evidence too and its integrity must be recorded.
- Calling it definitely fake because DMARC is absent. Being unverifiable and being fake are different.
- Not requesting server logs. Supporting header analysis with independent evidence strengthens the report.
Frequently asked questions
If the sender address is fake, can I find the real sender? Often yes. The real server and IP information in the Received lines is the part the attacker cannot fabricate and leads to the source.
How do I see the email header? Most email programs have a "view source," "show original" or "download as .eml" option.
Can a deleted email be recovered? It depends. It may be recovered from a server backup, the .pst/.ost file on the device or local remnants. For corrupt .pst recovery, see our article on Outlook pst ost file recovery.
Does DKIM passing prove the email is safe? DKIM proves the message came from that domain and was not changed. But an attacker can also send an email that passes DKIM from their own domain; the evidence is assessed with the full context.
Is a screenshot useless? It can be supporting but is weak alone. Without the raw file, header and hash it is easily challenged in court.
Is email forensics used in court? As long as it is collected properly, its header analyzed and its integrity recorded with a hash, yes.
Sources
- RFC 5321 and RFC 5322, SMTP and email message format: https://www.rfc-editor.org
- M3AAWG, email authentication guidance: https://www.m3aawg.org
- OWASP, email security resources: https://owasp.org
- NIST SP 800 86, integrating forensic techniques into incident response: https://csrc.nist.gov
- ISO/IEC 27037, collection and preservation of digital evidence: https://www.iso.org
If you need to identify the true source of an email or conduct a fraud investigation, contact DSET. From our Ankara Hacettepe Teknokent laboratory we provide email forensics, incident response and expert reporting.
Kimliğinizi doğrulayın
Yetkilendirilmiş erişim alanı. Tüm giriş denemeleri kayıt altına alınır.