Three Lines Worth Reading

You revealed the headers in Lesson 3.1. Now we find the three lines that matter out of the dozens on the page: From, Return-Path, and Authentication-Results. Everything else is background for the forensic analyst. These three are for you.

From: What the Sender Wants You to See

The From: line is the one you already know. It’s the display name and email address that shows up at the top of the message in your inbox (“Chase Bank <[email protected]>”). It’s also trivially spoofable — attackers set it to whatever they want, because mail clients honor what the sender claims with no verification at all.

That doesn’t make it useless. It tells you what persona the attacker is trying to adopt: your bank, your boss, a vendor you trust, a brand you recognize. The From line is the story the attacker wants you to believe. Your job is to check whether the rest of the headers agree with that story — and they usually don’t.

Return-Path: Where the Real Sender Lives

The Return-Path: line is the “bounce address” — the address that receives any delivery failures or errors for this message. It’s set by the sending mail server, not by the person composing the message, and it’s harder to fake because the server sending the mail has to actually accept bounces at that address for the whole system to work.

When From and Return-Path use different domains, that’s one of the clearest signals in email forensics. A legitimate company sends mail that bounces back to their own infrastructure. An attacker sends mail that bounces back to a throwaway domain they registered last week.

Authentication-Results: The Receipt

The Authentication-Results: line is written by the receiving mail server (your Gmail, your Outlook, your company’s mail gateway) after it checks the message. It’s a receipt recording the outcome of three verification attempts — SPF, DKIM, and DMARC — which we’ll break down in Lesson 3.3.

The line looks something like:

spf=pass ... dkim=pass ... dmarc=pass

Three words. Three verdicts. The receiving server already did the hard work for you — your job is just to read the receipt.

We Don’t Read This by Hand.

Here’s the truth: even when you know which three lines to look at, picking them out of forty-plus lines of text is tedious, and comparing domains across From and Return-Path is exactly the sort of thing humans make mistakes on. So we don’t do it by hand. We use a tool.

The Show Original Decoder below accepts a pasted header block, extracts the three lines, parses the authentication results, and highlights mismatches and failures in plain English. Try it now — three sample messages are pre-loaded so you can see what good, spoofed, and compromised headers look like without having to find your own.

Walk Through the Samples

Click “Legit Chase email” first. You’ll see the three lines cleanly laid out: the From is [email protected], the Return-Path is [email protected], both domains roll up to chase.com. Scroll to the authentication block — SPF pass, DKIM pass, DMARC pass. No red flags. This is what a clean receipt looks like.

Now click “Spoofed Chase phish”. The display name is still “Chase Bank,” and the From address still claims chase.com, but look at the Return-Path — it’s bulk-sender.tk. The authentication block lights up with failures: SPF fail (the sending server isn’t authorized to send for Chase), DKIM missing (the message wasn’t signed), DMARC fail (Chase’s published policy says reject messages that fail this way). The tool flags the domain mismatch and each auth failure in plain English.

Finally click “Compromised account (BEC)”. Here’s the trick: SPF, DKIM, and DMARC all pass. The From and Return-Path domains match. Everything looks clean. But the subject is “Need you to handle a wire transfer today” — and we’ll see in Lesson 3.4 why every single check can pass on a message that is still phishing.

Your Turn

Before you move on, do this once with a real message from your own inbox. Pick something low-stakes — a shipping confirmation from a retailer you know, a bank statement notification, a receipt from a service you use. Use the “View Original” trick from Lesson 3.1 to open the raw message, copy the whole header block, and paste it into the tool above.

You’ll see what all-pass authentication looks like on a legitimate message you actually received. The From and Return-Path will match (or roll up to the same parent domain), SPF/DKIM/DMARC will all be green, and there will be no red flags. Doing this once with a known-good message makes the failure patterns in a real phish instantly recognizable later.

Key Takeaways

1. Out of dozens of header lines, three matter: From (what the sender claims), Return-Path (where the real sender’s server lives), and Authentication-Results (the receiving server’s verdict).
2. A From/Return-Path domain mismatch is one of the clearest spoofing signals — legitimate senders bounce back to their own infrastructure.
3. You don’t parse headers by hand. A decoder extracts the three lines, compares domains, and translates the auth results into plain English.
4. Practice with a legitimate message from your own inbox — seeing a clean receipt once makes the dirty ones obvious.