Anatomy of a phishing email header

Start at the top: the verdict your provider already recorded

The single most valuable header is the one your own receiving server wrote: Authentication-Results. It is not part of the sender's story — it is the receiving system's lab report, stamped at delivery, recording what its checks found. In our sample it reads, in part: spf=fail for the envelope domain, dkim=fail for the signing domain, dmarc=fail against a published policy of reject. Three failures, and the DMARC one is decisive on its own: the bank's real domain publishes a policy saying mail that aligns with neither SPF nor DKIM should be rejected, and this message aligned with neither. Two lessons live here. The first is where to look: whatever mail client you use, the "show original" view puts this header near the top, and it outranks every other clue on this page because the sender could not write it. The second is subtler — the message was delivered anyway, to a junk folder or an inbox with a warning, depending on the provider. A recorded dmarc=fail with a reject policy that still reaches a user is a reminder that policy is advice receivers weigh, not physics; the header tells you what the verdict was, not what was done about it. The sending-side mirror of this header — the records that produce these verdicts — is what the email deliverability check reads, and why your email lands in spam covers what happens when legitimate mail collects the same failures.

The Received chain: a journey, read in the order it was stamped

Every server that handles a message prepends a Received header, so the block reads newest-first and the story reads bottom-up. Our sample claims two hops: a laptop with a hostname like a asset tag, handing the message to a server named mail.secure-login.example.net, which handed it to the victim's real provider ninety seconds later. Read as a journey it is oddly short for a global bank — no sending platform, no outbound gateway farm, none of the three-to-six hops a real bank alert accumulates — and it starts at a laptop, which is where phishing kits live and bank infrastructure does not. The timestamps sharpen the suspicion: each hop records when it stamped the message, so the gaps between hops are computable. Ninety seconds here is plausible; the values that betray forged or hand-assembled chains are the implausible ones — a hop stamped before the hop that supposedly fed it (a negative delay, meaning a clock was wrong or a line was written by hand), or a message that waits exactly a round number of hours in a queue that exists only in the header. One discipline matters more than any single hop: trust decays down the chain. The top hops were written by your provider and the server it received from — evidence. The bottom hops were written by, or on behalf of, the sender — testimony. Chains are strongest read as "where did my provider get it, and does the claimed origin below that line make sense", never as a complete true history.

Three domains that should agree, and a fourth that rats quietly

A message carries its identity in several places, and phishing lives in the gaps between them. The From domain is the identity the reader sees — here, on inspection, not the bank's domain at all but secure-login.example.net dressed with the display name "Bank Security"; the From address itself, alerts@ that lookalike domain, is the cheapest tell in the message and the one the visible client hides best by showing the display name large. Reply-To decides where your answer goes — in the sample it stays on the lookalike domain, but the variant to burn into memory is the message that displays a real bank From address while Reply-To points at a freemail account: any reply, with any details you helpfully include, leaves the bank's world entirely. Return-Path is the envelope sender, where bounces go; ours belongs to a third domain, a relay the sender rents, which legitimate bulk platforms also do — a mismatch to weigh, not a verdict. And the Message-ID, generated by whatever composed the message, carries a domain too; when it disagrees with the From domain, the message was assembled somewhere the From domain does not run. None of these alone convicts. The pattern that convicts is accumulation: a lookalike From, a borrowed Return-Path, a recorded DMARC failure — each individually explainable, jointly a costume with the seams showing. That accumulation, with a weight on each seam, is exactly what the analyser's findings list computes.

The body confesses: a link and an attachment

Headers end; the body is where the payload waits, and two artefacts close the case. The sign-in link displays the bank's real domain as its text and points at a raw IP address — defanged, hxxp://203[.]0[.]113[.]66/login — a server with no name, no certificate story, nothing a bank would ever send a customer to. Link text naming one destination while the href goes to another is the most reliable single tell in any message body, and it is invisible unless you hover, long-press, or extract the links mechanically, which is why the analyser lists them defanged: readable, unclickable, honest. The attachment finishes it: "statement.pdf.exe" — a name engineered to be read as a PDF by a hurried eye and executed as a program by Windows, which hides the final extension by default. Documents arrive as documents; an executable wearing a document's name is not a grey area. Put the whole specimen together — a DMARC failure recorded by your own provider, a two-hop chain starting at a laptop, a lookalike From, an IP-address link, an executable "statement" — and the message did not need a clever analyst. It needed the headers read at all, which is the one step the sender is counting on nobody taking. For the domain owner's side of the same fight — making sure your real mail passes the checks this phish failed, and reading the reports that show others trying — see reading your DMARC reports.

Frequently asked questions