Phishing Email Analysis: Headers, EML Files, and Hidden Payloads

Start with the raw message, not the screenshot

A user reports a suspicious email. The first mistake most analysts make is working from a screenshot or a forwarded copy. Forwarding rewrites headers and often strips attachments. What you need is the original EML file: the full RFC 5322 message with every header intact.

Every major client can export it:

Ask the reporter to send the EML as an attachment, never inline. Once you have it, you can drop it straight into the free EML parser on mlab.sh, which splits headers, authentication results, body parts, URLs and attachments into a readable view. But you should also know how to read the raw thing yourself. Let's do that.

Reading the Received chain hop by hop

Every mail server that handles a message prepends a Received header. That means you read them bottom to top: the lowest one is the origin, the topmost is your own infrastructure.

Here is a synthetic example (all domains are placeholders):

Received: from mx1.yourcompany.example (mx1.yourcompany.example [198.51.100.10])
    by mailstore.yourcompany.example; Tue, 7 Apr 2026 09:14:22 +0200
Received: from relay.bulkmailer.example (relay.bulkmailer.example [203.0.113.55])
    by mx1.yourcompany.example with ESMTPS; Tue, 7 Apr 2026 09:14:21 +0200
Received: from [192.0.2.77] (unknown [192.0.2.77])
    by relay.bulkmailer.example with ESMTPA; Tue, 7 Apr 2026 09:14:19 +0200
From: "IT Support" <[email protected]>
Reply-To: <[email protected]>
Return-Path: <[email protected]>
Subject: Action required: password expires today

What to look for in the chain:

• The first hop. 192.0.2.77 connecting as unknown (no reverse DNS) to a bulk mailing relay is the real origin. Look that IP up on mlab.sh: hosting provider, ASN reputation, and whether it has appeared in other campaigns.
• Breaks in the chain. Timestamps that go backwards, or a hop claiming to be a well-known provider with an IP that does not belong to it, indicate forged headers. Anything below the first header added by your infrastructure can be fabricated by the sender.
• Mismatched identities. Three different domains in From, Reply-To and Return-Path is a classic phishing signature. Legitimate corporate mail rarely looks like that.

One rule worth internalizing: only the Received headers added by servers you trust are trustworthy. Everything earlier is attacker-controlled input.

SPF, DKIM, DMARC: what each verdict actually proves

Your gateway usually stamps an Authentication-Results header. It is the closest thing to a verdict you get for free:

Authentication-Results: mx1.yourcompany.example;
    spf=pass smtp.mailfrom=bulkmailer.example;
    dkim=pass header.d=bulkmailer.example;
    dmarc=fail header.from=yourcompany-helpdesk.example

Each mechanism answers a narrow question, and analysts routinely over-read them:

The trap: spf=pass and dkim=pass on a phishing email is normal. Attackers send from infrastructure they control, with SPF and DKIM correctly configured for their domain. In the example above, bulkmailer.example authenticates fine. The fraud lives in the From header, which claims yourcompany-helpdesk.example, a lookalike the attacker registered last week. DMARC alignment is the check that catches the mismatch, and even DMARC passes cleanly when the lookalike domain publishes its own valid records.

So treat authentication results as identity confirmation, not legitimacy confirmation. They tell you which domain to investigate, not whether to relax.

Display names, Reply-To, and other header tricks

Most phishing does not bother with technical spoofing at all. It exploits what the mail client shows:

• Display-name impersonation. "Alice Snow, CFO" <[email protected]> renders as "Alice Snow, CFO" on mobile clients that hide the address entirely.
• Reply-To diversion. The From may look plausible while Reply-To sends every response to an attacker mailbox. This is the backbone of payroll-change and invoice fraud.
• Lookalike domains. Homoglyphs (rn for m), added words (-helpdesk, -secure), or swapped TLDs. Check the registration date of the domain: a "vendor" domain registered nine days ago answers most questions.
• Encoded subjects. MIME encoded-words (=?UTF-8?B?...?=) are legitimate, but attackers use them to sneak past naive keyword filters. Decode them before judging the subject.

A few secondary headers repay attention too. Message-ID should carry a domain consistent with the sending infrastructure; a mismatch is another thread to pull. X-Mailer and similar client fingerprints can tie separate emails to one toolkit, which matters when you are clustering a campaign. And Date versus the first trusted Received timestamp reveals messages composed long before sending, a common trait of bulk kits queuing mail across time zones.

Extracting and analyzing URLs

Never click links from the analysis machine you read mail on. Extract them statically from the HTML body and look at three layers:

1. Displayed text vs actual href. <a href="https://login.credential-check.example/o365">https://portal.office.com</a> is the whole attack in one line.
2. Redirect wrappers. Marketing trackers, open redirects on legitimate sites, and URL shorteners all hide the final destination. Resolve the chain in a sandboxed environment, not your browser.
3. Per-recipient tokens. A long random path segment often encodes the target's email address, sometimes just base64. Decode it: it confirms targeting and tells you whether clicking would validate the address to the attacker.

Paste the extracted URLs into mlab.sh for enrichment: domain age, hosting, certificate history, and whether the URL or its infrastructure is already flagged. The EML parser does the extraction automatically, including URLs buried in HTML attributes and quoted-printable encoding, which manual grepping tends to miss.

Attachment analysis without detonating anything

Attachments arrive base64-encoded in MIME parts. Carve them out (or let the EML parser do it) and work hashes-first:

# Carve attachments from an EML with munpack or ripmime, then:
sha256sum invoice_2026_04.pdf.htm
file invoice_2026_04.pdf.htm

Then check, in order:

• Hash lookup first. Search the SHA-256 on mlab.sh. A known-bad hash ends the analysis in thirty seconds.
• True file type vs claimed type. file output beats the extension. A "PDF" that is actually HTML is HTML smuggling: the file assembles its payload in the victim's browser, client-side, which is exactly why the gateway missed it.
• Double extensions and unusual containers. report.pdf.exe, ISO and IMG files (which bypass mark-of-the-web on older systems), password-protected ZIPs with the password in the email body.
• Macro-enabled documents. oletools (olevba) lists embedded VBA without opening the document. Auto-exec functions plus download logic is your answer.

If a script or JavaScript file falls out of the attachment, do not read it raw in a browser. Analyze it statically; our JavaScript deobfuscation walkthrough covers that workflow.

A repeatable 10-minute triage flow

1. Obtain the original EML as an attachment.
2. Parse it (mlab.sh EML parser or manually).
3. Read the Received chain bottom-up; enrich the origin IP.
4. Check Authentication-Results; investigate the aligned domain, not just the verdicts.
5. Compare From, Reply-To, Return-Path.
6. Extract URLs; enrich domains and final destinations.
7. Carve attachments; hash lookups before any deeper analysis.
8. Record verdict and IOCs; search the mail environment for the same sender, subject pattern, and URLs to find other recipients.

Step 8 is the one teams skip. One reported email almost always means twenty delivered ones.

Phishing analysis is not magic, it is reading order: headers bottom-up, verdicts narrowly, and attachments hashes-first. Master the EML and the screenshot people can keep.