{"id":173,"date":"2026-06-11T18:03:58","date_gmt":"2026-06-11T22:03:58","guid":{"rendered":"https:\/\/securebydefault.io\/blog\/?p=173"},"modified":"2026-06-11T18:05:49","modified_gmt":"2026-06-11T22:05:49","slug":"how-to-read-a-phishing-email-like-a-security-analyst","status":"publish","type":"post","link":"https:\/\/securebydefault.io\/blog\/how-to-read-a-phishing-email-like-a-security-analyst\/","title":{"rendered":"How to Read a Phishing Email Like a Security Analyst"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Most phishing advice stops at “look for typos and bad grammar.” That advice is dead. AI has made phishing emails grammatically flawless, professionally formatted, and visually identical to the real thing.<\/p>\n\n\n\n

So how do analysts catch them? Not by reading the body of the email. By reading what’s underneath it.<\/p>\n\n\n\n

Every email carries a paper trail.<\/strong> Headers, authentication results, routing information, and link destinations all tell a story the visible email never shows. Once you know where to look, a phishing email becomes obvious in seconds, regardless of how convincing the writing is.<\/p>\n\n\n\n

This post walks through the exact fields I check, in the order I check them, using the same approach I used while investigating the SOC146 phishing case.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The Full Analysis Checklist<\/strong><\/p>\n\n\n\n

Before diving into each field, here’s the complete picture of what to check and why:
<\/p>\n\n\n\n

Header \/ Field<\/strong><\/th>Category<\/strong><\/th>What It Tells You<\/strong><\/th><\/tr><\/thead>
From \/ Display Name<\/td>Sender Identity<\/td>Check who the email actually came from, not who it claims to be<\/td><\/tr>
Reply-To<\/td>Redirect Trap<\/td>Reveals where responses actually go<\/td><\/tr>
Return-Path<\/td>Bounce Address<\/td>Shows the true envelope sender, often different from From<\/td><\/tr>
Received Headers<\/td>IP Trail<\/td>Traces the email’s path server by server<\/td><\/tr>
SPF \/ DKIM \/ DMARC<\/td>Authentication<\/td>Confirms whether the sending server was authorized<\/td><\/tr>
URLs<\/td>Link Analysis<\/td>Where a link actually goes versus what it displays<\/td><\/tr>
Attachments<\/td>Payload Check<\/td>What the file really is and whether it’s been seen before<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

None of this requires special tools. Every header is visible in Gmail, Outlook, or any mail client through “View Source” or “Show Original.” Let’s go through each one.
<\/p>\n\n\n\n

\n\n\n\n

1. From and Display Name: Two Different Things<\/strong><\/p>\n\n\n\n

The display name is whatever the sender wants it to say. “Microsoft Support,” “IT Helpdesk,” “Your Bank.” None of that is verified. The actual sending address is the part that matters, and it’s often hidden behind the display name in most email clients.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

2. Reply-To: Where Your Response Actually Goes<\/strong><\/p>\n\n\n\n

If a reply address is present and different from the From address, that’s worth investigating immediately. Legitimate transactional emails rarely set a different Reply-To, and when they do, it’s usually a documented support address, not a personal Gmail account.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\n\n\n\n

3. Return-Path: The Envelope Sender<\/strong><\/p>\n\n\n\n

The From header is what’s displayed. The Return-Path (also called the envelope sender or bounce address) is what the receiving mail server actually used to accept the message. These two frequently don’t match, and when they don’t, the Return-Path is usually closer to the truth.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\n\n\n\n

4. Received Headers: The IP Trail<\/strong><\/p>\n\n\n\n

Every server that handles an email adds a Received header, stacked in reverse chronological order, with the most recent hop at the top. This creates a traceable path from the sender’s mail server to your inbox.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\n\n\n\n

5. SPF, DKIM, and DMARC: The Authentication Trio<\/strong><\/p>\n\n\n\n

These three records work together to answer one question: was this email actually authorized to be sent from this domain? Most mail providers run these checks automatically and stamp the result directly into the headers as Authentication-Results.<\/p>\n\n\n\n

SPF (Sender Policy Framework)<\/strong> checks whether the sending server’s IP is listed as an authorized sender for that domain.<\/p>\n\n\n\n

DKIM (DomainKeys Identified Mail)<\/strong> verifies a cryptographic signature proving the email wasn’t altered in transit and came from a server holding the domain’s private key.<\/p>\n\n\n\n

DMARC (Domain-based Message Authentication)<\/strong> tells receiving servers what to do when SPF or DKIM fail: quarantine, reject, or do nothing.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\n\n\n\n

6. URLs: What’s Displayed vs. Where It Goes<\/strong><\/p>\n\n\n\n

A link’s visible text and its actual destination are two completely independent things in HTML email. “Click here to verify your account” can point anywhere the sender wants.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\n\n\n\n

7. Attachments: What the File Really Is<\/strong><\/p>\n\n\n\n

File extensions are cosmetic. A file named invoice.pdf.exe, or an Excel file containing a macro, doesn’t announce itself as dangerous in the file name. The actual file type and its hash are what matter.
<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\n\n\n\n

Putting It All Together<\/strong><\/p>\n\n\n\n

Here’s the order I actually follow when triaging a reported email:<\/p>\n\n\n\n