Most people read an email the way they read a letter: sender, subject, message, done. But every email that reaches an inbox has already traveled through a chain of servers, each one stamping its own record of the journey — timestamps, IP addresses, authentication verdicts, routing paths. None of it is visible in a normal inbox view. All of it is sitting in the raw source, waiting to be read.

That trail is what email forensics actually studies, and it's the reason Email Decoded opens with a simple premise: every email leaves evidence. Learning to read that evidence turns out to be one of the most practical, transferable skills in security — useful whether you're investigating a phishing report, triaging abuse complaints, or just trying to figure out if that "delivery failure" notice is real.

Start with the headers, not the body

The body of an email is the least reliable part of it — trivially easy to fake, format, and spoof. The headers are where the real story lives, because they're written by infrastructure, not by the sender. Each mail server that touches a message adds its own Received header, stamped with a timestamp and the IP address it received the message from. Read from the bottom up, that chain reconstructs the message's actual path — which is often completely different from what the visible From: address implies.

Authentication results tell you who's responsible

Three protocols do most of the heavy lifting in modern email authentication, and each answers a slightly different question:

  • SPF asks: was this server authorized to send mail for this domain?
  • DKIM asks: was the message cryptographically signed by the domain, and has it been altered since?
  • DMARC asks: do SPF and DKIM actually align with the visible From: domain, and what should happen if they don't?

A receiving server evaluates all three and writes the verdict directly into an Authentication-Results header before the message even reaches an inbox. Reading that one header — often just a single line — tells you more about a message's legitimacy than the entire visible email put together.

The Message-ID is harder to fake than people think

Attackers can spoof a display name in seconds. Spoofing a consistent, well-formed Message-ID that matches the claimed sending infrastructure is a different problem entirely — most spoofing tools don't bother, which leaves behind a small but telling inconsistency for anyone who checks.

Why this matters beyond incident response

You don't need to be a security analyst for this to be useful. Anyone who has ever second-guessed a "your package couldn't be delivered" email, an unexpected invoice, or a password reset they didn't request benefits from knowing how to pull up the raw source and read what's actually there — instead of relying on how convincing the message looks at a glance.

Where to go from here

Reading headers is a skill that compounds: once you know what a normal Received chain looks like, an abnormal one jumps out immediately. Email Decoded builds this skill from the ground up — starting with a single header and working up to full-scale forensic investigations, DKIM key rotation, and the exact DNS records that make authentication possible in the first place.