SOC / EMAIL TRIAGE
A bank alert that did not add up.
Reconstructed a supplied email’s route, compared sender identities and separated authentication results from evidence of phishing.
Academic lab · September 2026 · Analysis of a supplied email excerpt, not a production incident.
The question
The message claimed a bank account had been suspended and demanded verification within 24 hours. I examined whether its sender identities, mail route and destination supported that claim.
How I approached it
I read Received headers from oldest to newest, compared the visible From, Return-Path, Message-ID and DKIM identity, and parsed the verification URL without opening it. I recorded observables with an explanation of what each could and could not establish.
What the evidence showed
SPF and DKIM were reported as passing, but the signing identity differed from the visible bank identity. No DMARC result was supplied. The verification destination used a separate bank-themed domain; the message combined this with urgency and threatened account closure. A loopback address was a local mail handoff, not a remote attacker IP.
Assessment and response
The supplied evidence was consistent with phishing. My report recommended preserving the original message, correlating matching URLs and identities in mail logs, quarantining related messages and verifying the request through a trusted channel. Credential reset and session revocation were conditional on a user having submitted credentials; these were recommendations, not actions I performed.
Limits of the result
I did not visit the destination or independently validate the header excerpt. A relay IP or a third-party sending domain was not labelled malicious simply because it appeared in the message. The case demonstrates careful email triage and reporting within a controlled exercise.