The email had our CFO’s name on it. The headers said something else.

Wanted to write up a case that's a good, boring, real-world example of why "does the display name match" isn't a security check.

Finance forwards an email to the SOC inbox with a note: "this looks off." It's got the CFO's name, the usual sign-off, and a request to expedite a wire transfer because a vendor's bank details had "just been updated." Nobody in the finance thread had questioned it yet. The name matched. That was enough for them.

It's not enough once it lands with someone who actually has to clear it, because the display name is the single easiest field in an email to fake. It costs a sender nothing to type "Jane Smith, CFO" into a throwaway account's From field. It's simultaneously the least trustworthy piece of evidence in the whole message and the one everyone trusts on instinct, which is exactly why it keeps working.

The actual answer is in the raw headers. Usually comes down to four or five fields:

From vs Reply-To. A real reply from the CFO goes back to the CFO's real address. A spoofed message often shows the right name in From but quietly routes replies to a completely different domain, so the reply, and the wire confirmation, goes straight to the attacker.

The Received chain. Every mail server that handles the message stamps its own line on top of the previous one, so reading top to bottom is actually reading the hops backward. The line closest to the bottom is closest to the true origin. Does that IP or hostname match the company's actual mail infrastructure, or does it resolve to a VPS with zero prior history with anyone at the company?

Authentication-Results. This is where the SPF, DKIM and DMARC verdicts already live, computed by the receiving mail server before the message even reaches an inbox. A flat-out spoofed domain usually fails one or both. A lookalike domain, one character off from the real one, can pass all three, because as far as authentication is concerned, it genuinely is the legitimate sender for that fake domain.

Return-Path vs From. Where bounces actually go versus what the visible message claims. One more data point for or against the story.

None of that is a hunch. It's five fields that either back up the sender's story or contradict it, and knowing the order to check them in is the difference between clearing an email in two minutes and a wire transfer that isn't coming back.

This is the actual core of DFIR work, tracing an artifact back to what really happened instead of what it claims happened. It's also most of what's in Codelivly's Digital Forensics Playbook, a 259-page hands-on manual covering this plus memory, disk and network forensics. If the moment before you clear an incident should be spent reading headers instead of trusting a name, that's the part of the job it walks through in full.