Rolling Thunder Security · Codex · Social Engineering · Phishing

The Email
Autopsy

Take a phishing email apart line by line. Open the .eml file, click any header to see what it does and what it gives away, walk the Received: chain back to the originating IP, and read the SPF / DKIM / DMARC verdict the receiving server already wrote for you. Every annotation in the autopsy is real and reusable on any message you receive.

One .eml · fully annotated Click any line · see what it means End result · spot the phish
01
The Format

The .eml File

An .eml file is just plain text. It is the message exactly as the mail server saw it. Every header, every signature, every line of the body, in the order the protocol delivered them.

When you "save" or "export" an email from any modern mail client, what you get is a single text file with the extension .eml. The format is defined by RFC 5322. You can open it in any text editor. There are no fancy structures, no databases, no binary blobs. The first half of the file is the headers, separated from the body by a single blank line, and the body is whatever the sender included (plain text, HTML, attachments encoded as MIME parts, or all three).

Every mail client also has a way to show you the raw .eml of a message you have already received, without saving it as a file. The button is called different things in different apps, but it always exists. Learn where it lives in the clients you use.

Gmail (web)

  1. Open the message
  2. Click the three-dot menu at the top right of the message
  3. Choose Show original
  4. A new tab opens with the full raw .eml and the SPF / DKIM / DMARC results at the top

Outlook (desktop)

  1. Open the message in its own window (double-click)
  2. File > Properties
  3. Read the Internet headers field at the bottom of the dialog
  4. For the full .eml: drag the message to your desktop

Outlook (web / Microsoft 365)

  1. Open the message
  2. Click the three-dot menu at the top right
  3. View > View message source

Apple Mail

  1. Open the message
  2. View > Message > Raw Source (or ⌥⌘U)
  3. Or View > Message > All Headers for just the header block

Thunderbird

  1. Open the message
  2. View > Message Source (or Ctrl+U)

Any client

  1. If all else fails: forward the message to yourself as an attachment
  2. The attached message will arrive as a .eml file
  3. Save it to disk and open with a text editor
02
Reference

The Headers Worth Knowing

Hundreds of headers exist. A dozen do most of the work. Get familiar with these and you can read any email.

HeaderHalfWhat it tells you
From:VisibleThe sender that the mail client shows the user. Free-form display name plus an address. Spoofable.
To:VisibleThe intended recipient(s). Can be different from who actually received the message (BCC, list expansion).
Subject:VisibleFree-form text the sender chose. Often the bait line.
Date:VisibleThe local clock of the sending machine when the message was composed. Can be wrong, missing, or in the wrong timezone.
Reply-To:Where a reply goes when the user hits Reply. If different from From:, that is a deliberate redirect.
Return-Path:The SMTP envelope sender (MAIL FROM), captured by the receiving server. Where bounces go. Often the most truthful "from" on the message.
Message-ID:A globally unique identifier assigned by the originating server. Format hints at the mailing infrastructure used.
Received:One stamp per relay hop. The receiving server prepends a stamp on every Received header. Reading them bottom-up tells the story of the message's path.
Authentication-Results:The receiving server's verdict on SPF, DKIM, and DMARC for this message. Single most important header for catching spoofing.
DKIM-Signature:A cryptographic signature over selected headers and (usually) the body, produced by the sending domain. Validated against a public key in DNS.
ARC-Authentication-Results:Authenticated Received Chain. When mail passes through a forwarder, ARC preserves the original auth verdict so the final receiver can still trust it.
List-Unsubscribe:An mailto: or https: that the user's client can call to unsubscribe. Mandatory for bulk senders under Gmail/Yahoo 2024 rules.
Content-Type:How the body is formatted. text/plain, text/html, or multipart/* if there are attachments.
X-Mailer:The software that composed the message. Optional. Phishers often forget to set it convincingly.
03
Interactive

The Autopsy

Below is the full text of a phishing email exactly as it would arrive in a Northgate inbox. Click any header line to read what it means and what it gives away. The most suspicious lines are colored red, the passing ones green, the warnings yellow.

This is not a real message. The domains send-mailer.co and northgate-account-reset.help-desk.io are illustrative. The IP 185.220.101.34 is in a range historically used by anonymizing relays. The Northgate mail servers and address ranges shown are realistic but not necessarily accurate.

phish-sample.eml · raw source
Phishing
Click any line in the message at left to see what it means and what it tells us.
04
Forensics

Walking the Received Chain

Every server that touches the message prepends one Received: header. The chain is read from the bottom up to retrace the path from sender to you.

This is the single most useful skill on this page. The originating IP, the one that actually composed the message, is always the bottom Received: in the file (or close to it, depending on how many internal hops the receiving organization adds). Each hop higher in the file is one step closer to your inbox. The top hop is the server that finally handed the message off to your mailbox.

03

Final hop · into your mailbox

inbound.northgate.edu (Postfix)
The Northgate mailbox server hands the message to your inbox. Reading top to bottom, this is the first Received: stamp in the file.
Target inbox
02

Edge relay · into Northgate

mx-east-3.northgate.edu · 128.210.7.45
A Northgate MX server accepts the message from the public internet and forwards it inward. Trusted because it's inside Northgate's infrastructure.
Trusted relay
01

Bulk mailer · into the public internet

mta-out.send-mailer.co · 203.0.113.42
A third-party bulk mailer service relays the message to Northgate's edge. Not a Northgate server. This is where the trust chain starts to break down.
Untrusted relay
00

Origin · the actual sender

[185.220.101.34] (unknown)
The bottom Received: stamp. This is the IP that submitted the message to the bulk mailer in the first place. The PTR (reverse DNS) lookup returns unknown, which is itself a tell.
Originating IP
Why you read bottom-up

Every server adds its own Received: on top, so the most recent hop ends up at the top of the file and the original sender ends up at the bottom. Reading bottom-up follows the actual flow of the message through time. You can verify the chain is intact by checking that each hop's "by" host matches the next hop's "from" host. If there is a gap, the chain has been forged or rewritten.

05
Forensics

Looking Up the Originating IP

Once you have the IP from the bottom of the Received chain, three quick lookups tell you almost everything you need to know about the sender.

You do not need to install anything. whois ships on every Linux and macOS install. dig -x performs the reverse DNS lookup. And free IP geolocation services give you a city-level location and the hosting provider in one click. None of these are perfect, but together they paint a picture.

// What the IP from the autopsy reveals
185.220.101.34
WHOIS owner
Block assigned to a Frankfurt-based hosting company commonly used by anonymizing relays. whois 185.220.101.34
Reverse DNS
dig -x 185.220.101.34 +short returns nothing — no PTR record. Legitimate mail servers always have a PTR.
Geolocation
Frankfurt, Germany. The supposed sender is the Northgate IT Helpdesk in West Lafayette, Indiana.
Reputation
Listed on multiple public blocklists (Spamhaus DROP, Spamcop). A receiving server consulting blocklists would have already flagged this.
Hosting type
Datacenter IP, not a residential or campus IP. A real Northgate IT employee would never send mail from a German datacenter.
Three commands to keep in your pocket

whois <ip> — who owns the block.
dig -x <ip> +short — what does the IP claim its hostname is.
curl https://ipinfo.io/<ip>/json — geolocation, ASN, hosting org in a single JSON response.

06
Forensics

Reading Authentication-Results

By the time the message reaches your inbox, the receiving server has already evaluated SPF, DKIM, and DMARC for you. The verdict lives in a single header.

The Authentication-Results: header is a one-stop summary written by the receiving mail server. Look for three keywords: spf=, dkim=, and dmarc=. Each one will read pass, fail, softfail, neutral, or none. The next page covers what each of these protocols actually does. For now, treat the verdict as a quick first pass.

SPF
FAIL

The IP that sent the message is not in the list of IPs allowed to send mail for the claimed domain. In our autopsy: send-mailer.co is not permitted to send on behalf of northgate.edu.

DKIM
NONE

No DKIM signature was attached. Either the sender did not sign the message, or the signature was stripped in transit. A legitimate northgate.edu sender would always sign.

DMARC
FAIL

Because both SPF and DKIM failed to align with the From: domain of northgate.edu, DMARC fails. The Northgate DMARC policy is p=quarantine, so the message lands in spam rather than the inbox — but some receivers still deliver to inbox with a warning.

When the verdict is all three fail

If you see spf=fail, dkim=fail (or dkim=none), and dmarc=fail on a message claiming to be from a major institution or a service you use, the message is almost certainly forged. Real organizations get their mail authentication right.

07
Habits

The Forensics Checklist

Run this list against any suspicious email and you will catch nearly every forged message you receive.

  1. Open the raw source. View original / View source / Properties > Internet headers, depending on your client. Get the full .eml in front of you.
  2. Compare From, Reply-To, and Return-Path. When any two of these disagree, the message has at least one redirection. When all three disagree, the message is almost certainly spoofed.
  3. Find the bottom Received: line. That is the originating IP. Note it for the next step.
  4. Look up the IP. whois for the owning organization, dig -x for the reverse DNS, and an IP geolocation lookup for the country. Compare against where the sender claims to be.
  5. Read the Authentication-Results header. Three keywords: spf=, dkim=, dmarc=. All three should pass for a legitimate corporate message. If any of the three says fail while the message claims to come from a brand or institution, escalate to suspicion.
  6. Inspect every link before clicking. View source on the HTML body. Look at the href values, not the displayed text. Any link whose visible text and underlying URL disagree is intentional misdirection.
  7. Save the .eml for reporting. When you report to your IT/security team, attach the raw .eml or forward as attachment. Forwarding the rendered email loses the headers, which are the entire evidence base.
08
Going Deeper

Where to Go Next

You now know how to read an email. The next page explains the three protocols that decide whether what you're reading should be trusted.

// Back to

Phishing Foundations

The concepts behind the autopsy: the two halves of an email, the Friendly From lie, the patterns every phish follows.

← back to phishing
// Next

SPF, DKIM, DMARC

What the three protocols actually do, how a receiving server evaluates them, how DMARC alignment works, and why Gmail and Yahoo now require all three.

Read the trio →