Phishing email examples explained: what a SOC analyst looks for

A SOC analyst doesn’t decide whether an email is phishing by how it feels. They check evidence: who really sent it (headers and SPF, DKIM and DMARC results), whether the sending domain is a lookalike, where every link actually goes, and what any attachment really is. The three phishing email examples below are fictional, written for a made-up company called Acme Fintech, and each one is annotated the way an analyst would work through it.

If you’re training for a SOC role, treat each example as a practice ticket. Read the email, write down what you’d check, then compare with the annotations.

How a SOC analyst triages a reported phishing email

Most phishing investigations start one of two ways: a user clicks “Report phishing”, or the email security gateway raises an alert. Either way, the analyst works through roughly the same checklist:

1. Get the original message, with full headers, as an .eml file. Never work from a forwarded copy, because forwarding replaces the headers you need.
2. Read the authentication results: SPF, DKIM and DMARC.
3. Compare the identities: the display name, the From address, the Reply-To and the Return-Path.
4. Inspect the domains for lookalikes and check how new they are.
5. Extract and analyse the URLs without clicking them in a normal browser.
6. Analyse any attachments by type and hash, then in a sandbox if needed.
7. Scope it: who else received it, who clicked, who entered credentials.
8. Respond: purge the message, block indicators, reset credentials, and document everything.

Phishing is catalogued in MITRE ATT&CK as technique T1566, with sub-techniques for malicious attachments (T1566.001), links (T1566.002) and phishing via services such as social media or messaging (T1566.003) and voice calls (T1566.004). Tagging your ticket with the right ID helps the team spot patterns.

A 60-second primer on SPF, DKIM and DMARC

You’ll see these three results in every header, so it’s worth being precise about what each one checks:

The trap beginners fall into: a pass doesn’t mean safe. An attacker who registers their own lookalike domain can set up perfect SPF, DKIM and DMARC for it. Authentication tells you the email really came from that domain. It doesn’t tell you the domain is who it pretends to be.

Example 1: the “mailbox full” credential harvester

Here’s the email as the user saw it:

From:    Acme IT Service Desk <it-support@acme-flntech.test>
To:      finance-team@acme-fintech.test
Subject: [Action Required] Your mailbox is 98% full - messages will be held

Dear user,

Your mailbox has reached its storage limit. Incoming messages
are now being held and will be deleted after 24 hours.

To release your messages and upgrade your storage at no cost,
please validate your account below:

      [ Release held messages ]

Acme IT Service Desk

And the relevant headers from the .eml file:

Return-Path: <bounce@acme-flntech.test>
Received: from mail.acme-flntech.test (mail.acme-flntech.test [203.0.113.45])
        by mx1.acme-fintech.test with ESMTPS id 4F2A1C0E31
        for <finance-team@acme-fintech.test>; Thu, 8 Oct 2026 07:42:19 +0100
Authentication-Results: mx1.acme-fintech.test;
       spf=pass (domain of bounce@acme-flntech.test designates 203.0.113.45 as permitted sender) smtp.mailfrom=bounce@acme-flntech.test;
       dkim=pass header.d=acme-flntech.test header.s=s1;
       dmarc=pass (p=NONE) header.from=acme-flntech.test

What the analyst notices

• The domain is a lookalike. acme-flntech.test, not acme-fintech.test: the i in “fintech” has been swapped for an l. In many fonts, at a glance, they look nearly identical. Analysts read domains character by character.
• Everything passes, and that’s the point. SPF, DKIM and DMARC all pass because the attacker controls acme-flntech.test and configured it properly. The authentication results prove the email came from the lookalike domain, nothing more.
• Urgency plus a deadline. “Will be deleted after 24 hours” is designed to make someone act before thinking.
• Generic greeting and a group recipient. “Dear user” sent to a distribution list, while genuine internal IT notices usually come from a known system and address people by name.
• A process that doesn’t exist. Acme’s IT team doesn’t release mail by asking users to “validate” accounts.

The button’s real destination, found by viewing the HTML source rather than clicking, was:

<a href=“https://acme-flntech.test/owa/auth/login.php?u=finance-team%40acme-fintech.test”>

The link pre-fills the victim’s email address, a common trick that makes the fake login page feel personalised. Our guide on how to analyse a phishing link safely covers how to investigate a URL like this in an isolated environment.

When you write the URL into a ticket or chat, defang it so nobody clicks it by accident: hxxps://acme-flntech[.]test/owa/auth/login.php.

Response

Search mail logs for every recipient of messages from acme-flntech.test, purge them from mailboxes, block the domain and IP 203.0.113.45 at the gateway, and check proxy logs for anyone who visited the URL. Anyone who did visit gets a password reset and a session revocation, and the team checks their sign-in logs for logins from unfamiliar locations. That last step is where phishing turns into account takeover, which our post on how account takeovers work explains end to end.

Example 2: the payment-change request (business email compromise)

This one has no link and no attachment, which is exactly why it gets past some filters:

From:     “Chief Executive Officer” <ceo@acme-fintech.test>
Reply-To: ceo.office.acme@freemail-example.test
To:       accounts-payable@acme-fintech.test
Subject:  Confidential - vendor bank details update

Hi,

I’m in back-to-back meetings with the board today so can’t take
calls. Our supplier has changed banks. Please update their payment
details to the account below and process this week’s invoice today.

Keep this between us until the announcement.

Sent from my phone

The headers:

Return-Path: <ceo@acme-fintech.test>
Received: from vps-77.hosting-example.test (unknown [198.51.100.23])
        by mx1.acme-fintech.test with ESMTP id 9B7D2A11F0
Authentication-Results: mx1.acme-fintech.test;
       spf=fail (domain of ceo@acme-fintech.test does not designate 198.51.100.23 as permitted sender) smtp.mailfrom=ceo@acme-fintech.test;
       dkim=none (message not signed);
       dmarc=fail (p=NONE) header.from=acme-fintech.test

What the analyst notices

• This is direct spoofing of the company’s own domain. The From address looks perfect, but SPF fails because 198.51.100.23 isn’t one of Acme’s mail servers, and there’s no DKIM signature.
• DMARC failed, but the email was still delivered. Look at p=NONE. Acme’s DMARC policy is set to monitor only, so receivers are told to take no action on failures. That’s a configuration finding in its own right: the fix is to move the policy towards quarantine and then reject once legitimate senders are covered.
• Reply-To points somewhere else. Any reply from accounts payable goes to a free-mail address the attacker controls. A mismatch between From and Reply-To is one of the most reliable BEC indicators.
• Classic social engineering. Authority (the CEO), urgency (today), secrecy (“keep this between us”) and an excuse to avoid verification (“can’t take calls”).

You can check a domain’s published records yourself. In our lab DNS, Acme’s records look like this:

$ dig +short TXT acme-fintech.test
“v=spf1 ip4:192.0.2.10 ip4:192.0.2.11 include:_spf.mailprovider.test -all”

$ dig +short TXT _dmarc.acme-fintech.test
“v=DMARC1; p=none; rua=mailto:dmarc-reports@acme-fintech.test”

The SPF record lists exactly which IPs may send for the domain, and 198.51.100.23 isn’t one of them. The DMARC record confirms the p=none policy.

Response

Confirm with accounts payable that no payment was made, and if one was, escalate to the finance team immediately so they can contact the bank. Block the free-mail reply address, raise the DMARC policy change with the email team, and add a rule flagging external emails that use internal executive display names. The underlying process control matters most: any change to supplier bank details is verified by phone using a number already on file, never one from the email.

Example 3: the courier notice with a disguised attachment

From:    Brightlane Couriers <notifications@brightlane-delivery.test>
To:      reception@acme-fintech.test
Subject: Parcel held - customs fee unpaid (Ref BL-55021)
Attachment: Delivery_Invoice_BL-55021.pdf.html  (4 KB)

Your parcel could not be delivered due to an unpaid customs fee.
Open the attached invoice to arrange redelivery.

What the analyst notices

• A double extension. Delivery_Invoice_BL-55021.pdf.html is an HTML file, not a PDF. Windows hides known file extensions by default, so a user may only see Delivery_Invoice_BL-55021.pdf.
• The size doesn’t fit the story. A 4 KB “invoice” is tiny. HTML attachments like this often contain a script that builds a fake login page or assembles and downloads a malicious file inside the browser, a technique sometimes called HTML smuggling.
• A believable pretext. Parcel and customs notices work because most people are expecting something.
• A new, unfamiliar sending domain. Acme has no relationship with “Brightlane Couriers”. Checking the domain’s registration date (WHOIS) often shows a domain created days before the campaign.

On an isolated analysis VM, the analyst confirms the file type and records its hash:

$ file Delivery_Invoice_BL-55021.pdf.html
Delivery_Invoice_BL-55021.pdf.html: HTML document, ASCII text, with very long lines

$ sha256sum Delivery_Invoice_BL-55021.pdf.html
3f9c1e0b7a64d2c58e1f0a9b6d47c2e83a51f6d09b2c7e4a18d5f3b6c9e0a721  Delivery_Invoice_BL-55021.pdf.html

(Illustrative output; the hash is made up.) The hash goes into the ticket, gets searched across the email gateway and endpoint telemetry to find other copies, and can be checked against threat intelligence. Opening the file itself happens only inside a sandbox, never on the analyst’s workstation.

Response

Purge all copies, block the sender domain and the attachment hash, and check endpoint logs for anyone who opened it. If a browser on any machine wrote an unexpected file to the Downloads folder or launched a script right after the email arrived, that machine is escalated to incident response.

The analyst’s quick-reference checklist

The UK’s NCSC phishing guidance for organisations recommends a layered defence, with technical controls, user reporting and a plan for when someone does click, rather than relying on users never making a mistake. Your job isn’t to blame the person who clicked; it’s to make reporting easy and response fast.

Personal safety tips (for you and the people you’ll protect)

• Hover over or long-press links to preview the real destination before you tap.
• If an email asks for payment changes, credentials or codes, verify through a channel you already trust, such as a known phone number or the official app.
• Turn on file extension visibility in Windows Explorer so .pdf.html tricks are obvious.
• Use multi-factor authentication, ideally phishing-resistant methods such as passkeys, so a stolen password alone isn’t enough.
• Report suspicious emails rather than just deleting them.

How to practise phishing analysis as a beginner

• Read your own headers. In Gmail, open a message and choose “Show original”; in Outlook, view the message source. Find the SPF, DKIM and DMARC results on legitimate emails first, so you know what normal looks like.
• Look up real records safely. Run dig +short TXT and dig +short TXT _dmarc. against domains you use every day and read their SPF and DMARC policies. Looking up public DNS records is passive and harmless.
• Write mock tickets. Take the three examples above and write a full ticket for each: summary, evidence, ATT&CK ID, actions, recommendations. That’s portfolio material.
• Build it into a lab. Set up a mail server in your home lab and send yourself test emails with mismatched headers. Only send test mail within systems you own or have written permission to test.

Phishing analysis is one of the most common tasks for an entry-level analyst, so it fits naturally into the SOC analyst roadmap as an early skill to master.