Phishing Email Analysis: Headers, URLs, Attachments

Phishing is still the most common way attackers get a first foothold, so phishing email analysis is a core skill for every SOC analyst. The good news is that a systematic routine beats intuition. Check the headers, check the links, check the attachment, then decide. This guide gives you that routine, with commands you can run in a safe lab.

This is Part 8 of 30 in the Blue Team Learning Path. In Part 7 we learned why behaviour matters more than single indicators. Phishing is where you apply it: the lure is the technique, and the sender domain is only an indicator.

Key takeaways

• Never open attachments or click links on your normal machine. Use an isolated analysis environment.
• Read the full headers: the visible From address proves nothing.
• SPF, DKIM and DMARC results tell you whether the sender domain was authenticated, not whether the mail is safe.
• Defang every indicator before you paste it into a ticket.

Set up a safe analysis environment first

Treat every sample as hostile. Work in a virtual machine with no shared folders, snapshots enabled and network access that you control. Save the message as an .eml file or export it as a message source, rather than forwarding it in a way that rewrites the headers. If you do not have a lab yet, Part 10 shows how to build one for free.

For our own readers who just want to recognise a scam as a user, the shorter guide on spotting phishing emails is a better starting point. This post is for analysts who must investigate and report.

Step 1: read the email headers

Every mail server that handles a message adds a header, and those headers are the evidence trail. In most clients you can find them under “View source”, “Show original” or “Message details”. Read them in this order.

• From, Reply-To and Return-Path: the visible sender, the address replies go to, and the envelope sender. Attackers often make these three disagree.
• Received: each server adds one at the top, so read from bottom to top to follow the real path. The lowest entry is closest to the sender.
• Message-ID: normally contains the sending system’s domain. A mismatch with the From domain is worth noting.
• Authentication-Results: the receiving server’s verdict on SPF, DKIM and DMARC.

Here is a short, fictional example of the part you care about:

Return-Path: <bounce@mailer.example.net>
Received: from mailer.example.net (203.0.113.25) by mx.victim.example
Authentication-Results: mx.victim.example;
  spf=pass smtp.mailfrom=mailer.example.net;
  dkim=pass header.d=mailer.example.net;
  dmarc=fail header.from=payroll-update.example
From: "HR Payroll" <hr@payroll-update.example>
Reply-To: <collect@free-mail.example>

Notice the trap. SPF and DKIM pass, but for the sending service’s domain, not for the From domain. DMARC fails because neither aligns with the visible From address. A tired analyst sees “pass” and moves on. A careful one sees the mismatch and the unrelated Reply-To.

Common lure types and what they aim for

Knowing the goal of the email helps you choose which evidence to check first.

• Credential harvesting: a fake login page for email, cloud storage or a payroll portal. Focus on the link, the landing page domain and who submitted credentials.
• Malware delivery: an invoice, a shipping notice or a “scanned document” that carries a macro, script or archive. Focus on the attachment and on process creation after it was opened.
• Business email compromise: a plain-text message from an executive asking for a payment or gift cards. There may be no link and no attachment at all, so the evidence is in the headers, the Reply-To address and the request itself.
• Callback phishing: a message with only a phone number. Your detection has to rely on sender reputation and content, not on technical indicators.

The same message can combine two goals, for example a link to a document that asks for a login and then offers a download. Treat each part separately and record every indicator.

Following the Received chain

Each mail server prepends its own Received line, so the newest hop is at the top. Reading from the bottom, the first line usually shows where the message entered the mail system. Compare the connecting IP address with what the From domain should use. If a message claims to come from a bank but entered through an unrelated hosting provider, that is a strong signal. Be careful, though: the lowest lines can be forged by the attacker, and only the lines added by your own trusted servers are reliable. Anything below the first hop you control is a claim, not a fact.

Step 2: understand SPF, DKIM and DMARC

• SPF checks whether the sending server’s IP is allowed to send for the envelope domain. It is defined in RFC 7208.
• DKIM checks a cryptographic signature added by the sending domain. It is defined in RFC 6376.
• DMARC asks whether SPF or DKIM passed and aligned with the visible From domain, and tells receivers what to do if not.

A pass means the domain’s owner, or someone with access to their infrastructure, sent it. Attackers can register their own domains and make every check pass. Authentication tells you about identity, never about intent.

Step 3: analyse the links

Do not click. Instead, collect the URLs from the HTML source and inspect them as text.

1. Compare the visible text and the real href. A link that says one domain and points to another is a classic sign.
2. Look for look-alike domains. Swapped letters, extra hyphens, or a trusted brand placed in a subdomain of an unrelated domain.
3. Check for redirects and shorteners. Expand them in a sandbox or with a URL scanning service rather than a normal browser.
4. Check the age and reputation of the domain. Very new domains deserve extra suspicion.

On Linux you can pull links from a saved message for a quick first look:

grep -aoE 'href="[^"]+"' message.eml | sort -u

Email bodies are often encoded, so if this returns nothing, decode the message first or open it in a text-based mail viewer inside your lab.

Step 4: analyse attachments safely

Attachments are where phishing turns into malware. Start with static checks that never execute the file.

• Identify the real type. Run file on Linux. Names like invoice.pdf.exe or a script inside an archive are red flags.
• Hash it. Use sha256sum on Linux or Get-FileHash in PowerShell, then look the hash up in a reputation service.
• Check Office macros. The open-source olevba tool from the oletools project lists macros without running them.
• Inspect PDFs and archives for embedded links, scripts or password hints in the message body.

sha256sum invoice.docm
file invoice.docm
olevba invoice.docm

If static analysis is inconclusive, detonate the file in a sandbox that is isolated from your network. We cover the next level, malware triage, in Part 26.

Step 5: decide and respond

Put your findings into one of three buckets: malicious, suspicious or benign. Then act, following your organisation’s playbook and the containment advice in the NIST incident handling guide.

1. Find the blast radius. Search the mail gateway for the same sender, subject, URL and attachment hash across all mailboxes.
2. Remove it. Purge the message from inboxes that received it.
3. Check who interacted. Did anyone click or open the attachment? Look for proxy hits and process creation events.
4. Block and report. Block the sender, domain and URL, and report to the mail provider or abuse contact if appropriate.
5. Reset credentials for anyone who entered a password on the fake page.

If a user opened a macro document, treat the endpoint as compromised and follow your Windows triage process. Our Windows event logs guide shows what to look for afterwards.

Defang indicators before you share them

When you paste a URL or address into a ticket, chat or report, defang it so nobody clicks it by accident. Replace dots with [.] and write hxxp instead of http. For example, hxxp://login-update[.]example/verify. Most threat intelligence tools can refang the value again when you need it.

Map the attack to ATT&CK

Tag what you found so the report is useful later. Phishing with a link and phishing with an attachment are separate techniques in Initial Access, and the execution step might be a macro or PowerShell. Use the ATT&CK site to find the current IDs, as covered in Part 6.

Common pitfalls

• Trusting a pass. SPF and DKIM can pass for an attacker’s own domain. Check alignment.
• Judging by the display name. Always look at the underlying address.
• Clicking “just to see”. Use a sandbox or a scanning service.
• Only deleting the one message. Search for the whole campaign.
• Forwarding the sample as normal mail. It can rewrite headers and destroy evidence. Save it as .eml.
• Forgetting the user. A short, kind message to the reporter encourages more reports.

A checklist you can reuse

Keep a one-page checklist next to your queue: save the original, read From, Reply-To and Return-Path, follow the Received chain, read the authentication results, list and defang URLs, hash and inspect attachments, search for other recipients, contain, and record the technique. Using the same order every time makes you faster and your tickets comparable. Within a few weeks the routine becomes automatic, and you will spot the odd detail, such as a mismatched Reply-To, in seconds.

Frequently asked questions