Most phishing-awareness content tells readers to hover over links, distrust urgency, and check for typos. That advice is fine for inbox triage, but it collapses the moment you need to answer a harder question: is this specific message, sitting in front of you as raw source, actually spoofed? Answering that means reading the headers the way a mail transfer agent reads them, field by field, not gut-check by gut-check. This guide is built for that job. It's email spoofing detection through header analysis, aimed at security practitioners who need to make a defensible call, not end users deciding whether to click.

Why End-User Tips Aren't Enough: Reading Headers Like a Security Analyst

"Don't click suspicious links" is a behavioral control. It assumes the analyst, or the end user, can't or won't inspect the message itself. But when a message lands in an abuse mailbox, a SOC queue, or an incident ticket, that assumption breaks down. You have the full source. You have every header field, in order, exactly as each hop wrote it. The question stops being "does this look sketchy" and becomes "which field proves forgery, and which field is just noise from a normal, non-malicious mail path."

The gap is method. End-user guidance is heuristic and probabilistic. It flags things that correlate with phishing. Header analysis is closer to deterministic: a mismatched envelope sender, a broken DKIM alignment, or an inserted Received hop are structural facts about how the message was constructed and transported. They don't require guessing about intent. They require knowing where each fact lives in the header block and what a legitimate version of that field looks like. That's the skill this article builds, section by section, with annotated specimens instead of generic warnings.

From Header vs. Envelope-From: The RFC 5321/5322 Discrepancy Every Spoofed Message Shows

Every email message technically has two senders, and almost no mail client shows you both. RFC 5321 governs the SMTP envelope, the machine-to-machine conversation between mail servers, including the MAIL FROM command. RFC 5322 governs the message itself, including the human-readable From header that your mail client actually renders on screen. These are separate protocol layers, written at separate times, and nothing forces them to match.

Where each address lives and how mail clients hide the envelope sender

The MAIL FROM value from the SMTP transaction typically survives in the header block as Return-Path, added by the final receiving server. The From header, by contrast, is set by whoever composed the message and can say almost anything. A legitimate sender's Return-Path and From domain usually match, or are close cousins (a subdomain used for outbound infrastructure, say). A spoofed message frequently shows a real-looking From address while the Return-Path points somewhere the attacker actually controls, because that's the address that has to receive bounces, not the one the victim reads.

Most webmail and desktop clients render only the From header in the inbox view. Finding the envelope sender means opening raw source or "view original," which is exactly why this discrepancy is such a reliable, underused signal: attackers know almost nobody looks.

Annotated specimen: mismatched From and Return-Path

From: "Billing Department" <billing@acme-corp.com>
Return-Path: <x7f2k@mail-relay-9021.ru>
Reply-To: "Billing Department" <billing@acme-corp.com>

Here, the From header presents a plausible internal sender. The Return-Path, the RFC 5321 envelope address that bounces route to, has no relationship to acme-corp.com at all. On its own, a Return-Path mismatch isn't fatal proof of spoofing; legitimate bulk-mail platforms and marketing services often set a Return-Path on a sending domain that differs from the visible From. What makes this specimen worth flagging is the combination: a Return-Path on infrastructure with no discoverable connection to the sending organization, paired with a From address that mimics an internal department. That combination, not the mismatch alone, is the tell.

Display Name Spoofing vs. Forged RFC 5322 Address: Two Different Attacks, Two Different Tells

Attackers exploit two distinct layers of the same header field, and conflating them wastes analyst time. Display name spoofing email attacks leave the underlying address alone and manipulate only the friendly name shown in most clients. A forged RFC 5322 address attack goes further and fabricates the address itself, often using a lookalike domain.

Detecting display name spoofing email in the raw header block

From: "Jane Doe, CEO" <jdoe.finance@gmail.com>

The display name claims to be the company's CEO. The address underneath is a free webmail account with no connection to the organization. This is the cheapest attack to execute and the easiest to catch once an analyst is trained to always read past the display name to the angle brackets. Most business email compromise attempts against finance teams use exactly this pattern, because it requires no infrastructure at all, just a free mailbox and a plausible name.

When the visible name is real but the address underneath isn't

The harder case is a forged From header where both the display name and the address look credible at a glance:

From: "PayPal Support" <support@paypa1-secure.com>

The display name is exactly what a real PayPal message would show. The address, read carefully, uses the digit "1" in place of the letter "l": paypa1-secure.com instead of anything resembling paypal.com. This is the field an analyst should flag first, before checking anything else in the header block, because it's the single field most likely to be trusted on sight and least likely to be read carefully by a rushed reviewer. The fix is procedural: always expand the display name and read the raw address character by character, including the domain's TLD, before trusting anything else in the message.

Tracing the Received Chain for Forged Hops

Received headers are the closest thing email has to a chain of custody. Each mail server that handles a message prepends its own Received line, so the header block builds top-down chronologically as it moves through the mail system. The top entry is the most recent hop; the bottom entry is closest to the origin.

Reading Received headers bottom-up

Because each new hop gets added above the last, the correct forensic reading order is bottom to top: start at the oldest entry and work upward to reconstruct the actual path the message took. A legitimate chain shows a plausible, ordered progression: the originating mail server, then perhaps a relay or gateway, then the recipient's inbound mail servers, with timestamps that move forward and hostnames that resolve to IPs consistent with each hop's claimed identity.

Signs of an inserted or fabricated hop: timestamps, hostnames, IP mismatches

Received: from mail.acme-corp.com (mail.acme-corp.com [203.0.113.44])
    by mx.recipient-domain.com; Mon, 20 Jul 2026 14:02:11 -0400
Received: from smtp-relay-host.net (unknown [198.51.100.9])
    by mail.acme-corp.com; Mon, 20 Jul 2026 14:01:58 -0400
Received: from localhost (localhost [127.0.0.1])
    by smtp-relay-host.net; Mon, 20 Jul 2026 09:58:03 -0400

Read bottom-up, the message supposedly originates on localhost, jumps to smtp-relay-host.net, and then to mail.acme-corp.com. But the timestamp gap between the first and second hop is over four hours, an unusually long delay for a same-day relay hop, and the hostname resolves as "unknown" rather than a verifiable reverse DNS entry. That combination, an inconsistent timestamp gap plus an unresolvable hostname, is a classic tell of a manually inserted or fabricated hop, the kind attackers add by hand to make a message look like it traversed legitimate internal infrastructure when it didn't. For a full walkthrough of tracing every field in a delivery path, the full delivery path and forged-field breakdown covers the forensic tracing method in more depth than a single specimen can. If your starting point is simpler delivery problems rather than forgery, reading email headers to diagnose delivery failures is the right foundation before tackling forged chains.

DKIM Absence and Misalignment as a Spoofing Signal

DKIM signs specific header fields and the message body with a private key tied to a domain, verifiable against a public key published in that domain's DNS. When it's present and valid, it's strong evidence the signing domain actually sent the message unaltered. When it's absent, that evidence just isn't there, which is not the same as proof of forgery.

Why a missing DKIM signature isn't automatically proof of spoofing

Plenty of legitimate mail still goes out unsigned, or with a signature that a forwarding step breaks. Mailing lists, some ticketing systems, and misconfigured legacy senders regularly send valid mail with no DKIM signature at all. Treating an absent signature as automatic proof of spoofing produces false positives and trains analysts to distrust a signal that, alone, tells you very little. The absence of DKIM is a reason to look harder at other fields, not a verdict in itself.

Reading d= domain alignment against the From header

The signal that matters is alignment: does the d= domain in the DKIM-Signature header match, or reasonably relate to, the domain in the visible From header? A message signed by d=marketing-platform.com but claiming From: billing@yourbank.com has a real problem. The entity that cryptographically signed the message isn't the entity the message claims to be from. That misalignment is what DMARC's alignment check is built to catch, and it's a far stronger signal than a bare missing signature. To see how these verdicts actually get recorded, how to read the Authentication-Results header walks through where SPF, DKIM, and DMARC results land in the header block. For the protocol relationship behind all three checks, how SPF, DKIM, and DMARC actually work together is worth reading before you rely on alignment as a standalone signal. And when a signature is present but still fails, why DKIM signature verification fails separates routine breakage, like a forwarding step or a body modification, from an actual forgery attempt. If alignment failures keep surfacing on legitimate-looking domains, troubleshooting a DMARC failure from the Authentication-Results header is the next step for tracing the policy problem to its source.

Straightforward domain spoofing has become less common because DMARC enforcement across major providers has made it substantially harder for a fully spoofed domain to land in an inbox at all. That's part of why the overwhelming majority of business email compromise and phishing attempts in 2026 lean on display-name deception or lookalike domains instead of trying to forge a well-protected domain outright. The header fields covered in this guide are exactly where that shift shows up.

Header Injection and Reply-To Tricks: The Overlooked Corners of a Spoofing Investigation

Two remaining techniques get less attention than From-header forgery, but both show up regularly enough in real investigations to earn a place in the playbook.

Spotting header injection in raw source

Header injection happens when an attacker exploits a poorly-sanitized web form or mail-sending script by inserting line breaks and additional header fields into what should be a single input value, such as a name or subject field. In raw source, this shows up as unexpected header lines appearing where they shouldn't, or duplicate instances of fields like To, Bcc, or Subject:

Subject: Contact form submission
To: support@company.com
Bcc: attacker@external-domain.net
Content-Type: text/html

If that Bcc line wasn't written by the form's mail-sending code but instead arrived embedded inside a user-submitted field, it's an injection. Look for header fields that appear more than once, header fields in odd positions relative to the standard block order, or field values containing raw carriage-return/line-feed sequences. The injection mechanism itself depends on smuggling those characters through unvalidated input.

From header vs Reply-To: why attackers redirect replies instead of forging sender

From header vs Reply-To is a distinction worth isolating on its own, because attackers sometimes skip forging the From address entirely and instead just set a Reply-To that routes responses to an address they control:

From: "Accounts Payable" <ap@realvendor.com>
Reply-To: <ap-invoices@quickresponse-billing.net>

The From address here may be entirely legitimate, or spoofed with less effort than a full domain forgery. Either way, it doesn't matter to the attacker's goal. Once the victim hits "reply," the response goes to the Reply-To address instead, which is where the actual conversation, and the fraud, happens. This is attractive to attackers because it sidesteps some authentication checks that only validate the From domain, and because a Reply-To field draws far less scrutiny than the sender address itself.

A compact checklist for the next investigation: check Return-Path against From for domain relationship. Expand every display name and read the raw address. Trace the Received chain bottom-up for timestamp and hostname inconsistencies. Check DKIM d= alignment against From, not just presence or absence. Scan for duplicated or oddly-placed headers indicating injection. Always compare Reply-To against From before treating either as neutral. None of these checks alone is conclusive. Together, read in order, they turn a hunch into a documented finding, which is the actual difference between phishing awareness and header forensics.