Reading a Phishing Email Like an Analyst: Headers, Domains and Payloads

The email said "Account Department" and the display name read like the hospital's finance lead. The body asked the records officer to confirm a supplier payment before close of business. It looked right. It read right. But the moment you open the raw headers, the story changes: the message that claimed to come from the finance team had actually left a mail server in another country, failed every authentication check the hospital publishes, and carried a link that bounced through two redirectors before landing on a fake login page. None of that is visible in the inbox. All of it is sitting in the headers, in plain text, waiting to be read.

Most phishing advice tells you to watch for bad grammar, a sense of urgency, an offer too good to be true. That holds until the attacker hires a copywriter, and good phishing now reads better than the real finance memo. The signal that does not wear off is mechanical. A message either authenticates against the sender's domain or it does not. A domain is either the real one or a look-alike. A link either resolves to where it claims or somewhere else. Our senior penetration testers read the artefact the way you would on triage: the envelope, the domain, the authentication results, then the link and payload layers underneath.

// 01 The envelope sender is not the From line

An email has two senders, and almost nobody knows it. The one you see in your inbox is the header From, the display name plus an address that the sender writes by hand. It is decoration. The mail client will happily show "Dr Adaeze, Medical Director" even when the underlying address is a Gmail account or a stranger's compromised mailbox. The one the mail servers actually used to route and bounce the message is the envelope sender, recorded in the Return-Path header. These two do not have to match, and on a forged message they usually do not.

This is the first thing to read on triage. Open the message source (in most clients, "show original" or "view headers") and put the Return-Path next to the From. When a memo claiming to come from finance@yourhospital.org carries a Return-Path of bounce@mailer-7823.sendgrid-relay.net, you are not reading a finance memo. You are reading a message someone built to look like one. The display name costs nothing to fake. The routing path does not lie.

// 02 The domain that is almost right

Once you have the real sending address, read the domain character by character. Attackers register look-alikes that survive a glance and fail a stare. Three families do most of the work. A typosquat swaps or drops a character: clarensecc.com for clarensec.com, or the classic hello@0pay.com standing in for hello@opay.com, where the letter o has become a zero. A homoglyph substitutes a character that renders almost identically, often a Cyrillic letter that looks like a Latin one, so that the domain in the address bar is a different string from the one your eye reports. And a subdomain trick puts the trusted name where it is not the registered domain at all: yourhospital.org.secure-login-portal.net belongs to secure-login-portal.net, not to you.

The reliable read is right to left. The registered domain is the last two labels before the path, so in yourhospital.org.secure-login-portal.net the owner is secure-login-portal.net. Everything to the left of that is something the attacker controls and can name whatever they like. For a hospital, the practical defence is to know your own real domains cold, including the ones your billing portal and your EMR vendor send from, so that anything outside that short list earns a phone call before a click.

// 03 SPF, DKIM and DMARC: the three authentication checks

Here is the part the attacker cannot talk their way around. Three records, published in DNS by the real domain owner, decide whether a message is allowed to wear that domain's name, and the receiving server writes the verdict into an Authentication-Results header you can read for yourself. SPF (Sender Policy Framework) lists which mail servers are permitted to send for the domain, so a message from an unlisted server gets an SPF fail. DKIM (DomainKeys Identified Mail) attaches a cryptographic signature tied to the domain, so tampering or a wrong key produces a DKIM fail. DMARC sits on top: it checks that the domain the human sees in the From line aligns with the domain that passed SPF or DKIM, and it tells receivers what to do when alignment fails (none, quarantine, or reject).

On the forged finance memo, the Authentication-Results line read spf=fail dkim=none dmarc=fail. That single line settles the question more cleanly than any amount of staring at grammar. The message claimed your domain in the From, and your domain's own published policy said the message had no business doing so.

This is also where a hospital crosses from reading attacks to preventing them. If your domain publishes a DMARC record set to reject, a receiving mail server worldwide will refuse messages that forge your name, which protects your patients, suppliers and partners from emails that impersonate you. Many Nigerian healthcare domains publish either no DMARC record or a permissive one set to none, which monitors but blocks nothing. OWASP treats sender authentication as a baseline email control, and the move worth making is staged: publish SPF and DKIM, turn on DMARC at none to watch the reports, then tighten to quarantine and finally reject once your legitimate senders are accounted for.

// 04 The link and the payload underneath

If the headers pass and the domain is genuine, the attack still has two places left to hide: the link and the attachment. Hover over any link before trusting it (on a phone, press and hold to reveal the destination) and read the true target, not the friendly text. The text can say portal.yourhospital.org while the href points somewhere else entirely. Watch for redirectors, where a link runs through a legitimate shortener or a marketing-tracking domain that then forwards to the real, hostile destination, so the visible URL looks harmless and the landing page is anything but.

Then the payload layer. Two patterns recur. The first is the macro document, a Word or Excel file that asks you to "enable content" or "enable editing" to view it, where enabling runs embedded code that pulls down the actual malware. A legitimate invoice never needs you to enable macros to be read. The second is HTML smuggling, where the malicious file is assembled inside an HTML attachment by script running in your browser, so the dangerous bytes never travel across the network as a recognisable file and the email gateway sees only a harmless-looking page. The honest rule for clinical staff is narrow and teachable: an unexpected attachment that asks you to enable anything is a stop-and-report event, not a "let me just see what it is" event.