Finance forwarded it to the SOC inbox with one line: "this looks off." The email had the CFO's name, the CFO's usual sign-off, and a request to expedite a wire to a vendor whose bank details had "just been updated." Nobody in the finance thread had questioned it yet. The display name matched. That was enough for them.
It is never enough for the analyst who has to actually clear it. The display name is the one field in an email a sender fully controls with zero friction, which makes it the least trustworthy piece of evidence in the whole message and, not coincidentally, the one most people trust the most.
The real answer lives in the raw headers, and it usually takes four or five fields to settle it:
From vs Reply-To. A legitimate reply from the CFO goes back to the CFO's real address. A classic BEC email displays the CFO's name in From but sets Reply-To to a different domain entirely, so the victim's response, and the wire confirmation, goes straight to the attacker instead of anyone at the company.
The Received chain. Each mail server that handles a message stamps its own Received line on top, so reading top to bottom actually reads the hops in reverse chronological order. The line closest to the bottom, closest to the original send, is the one that matters: does the originating IP or hostname match the company's actual mail infrastructure, or does it resolve to a VPS in a country nobody in finance has ever emailed from.
Authentication-Results. This one header carries the SPF, DKIM and DMARC verdicts the receiving server already computed. SPF fail means the sending server wasn't authorized for that domain. DKIM fail means the signature doesn't match. A spoofed domain fails one or both; a lookalike domain (the CFO's name @ a domain one character off from the real one) can pass all three, because as far as authentication is concerned, it is a legitimate sender, just not the one the victim thinks it is.
Return-Path vs From. Where bounces actually go versus where the message claims to be from. A mismatch here is one more vote against the story the display name is telling.
None of this is a hunch. It is five fields that either corroborate the sender's story or contradict it, and reading them in the right order is the difference between clearing an email in two minutes and a wire transfer that isn't coming back.
That skill, tracing an artifact back to what actually happened instead of what it claims happened, is the core of DFIR work, and it's what Codelivly's Digital Forensics Playbook, a 259-page hands-on manual, is built to teach across email, memory, disk and network evidence. If the moment before you clear an incident is the moment you should be reading headers instead of a display name, this is the part of the job it walks through in full.
