← Back to Phishing & Email Security
PHISHING & EMAIL SECURITY · MEDIUM LAB

Header Forensics & Spoofing

The Basic lab taught you to check SPF/DKIM/DMARC as pass-or-fail. That's not the whole story. This lab covers the five real ways a sender gets spoofed, why a raw "pass" can still mean nothing without alignment, and then puts three realistic cases in front of you — including one that looks wrong but is completely legitimate.

01 · Foundations

Five Ways a Sender Gets Spoofed

"Spoofed" isn't one technique — it's a family of them, and each leaves different evidence. Knowing which one you're looking at tells you where to check.

Diagram listing five spoofing techniques: display name spoofing, domain lookalike, homograph/unicode domains, reply-to hijack, and compromised real accounts

The first four are visible in headers and DNS records — a lookalike domain, a mismatched Reply-To, a homograph character. The fifth, a genuinely compromised mailbox, passes every technical check because it really is that account. That's the case this lab spends the most time on, because it's the one a header checklist alone can't catch.

02 · Foundations

Why "SPF Pass" Isn't the Same as "Safe"

SPF and DKIM can each independently pass without proving anything about the address a human actually reads in their inbox. DMARC closes that gap with alignment — but only if you know to check it.

Diagram of four SPF/DKIM/DMARC alignment scenarios, showing that a raw SPF or DKIM pass only counts toward DMARC if the passing domain is aligned with the visible From address

An unaligned SPF pass (Scenario B) is normal for legitimate marketing platforms and invoicing tools sending on a company's behalf — it is not automatically a red flag. The real danger is the opposite mistake: treating any SPF/DKIM pass as proof of safety without checking whether it's actually tied to the domain in front of you.

Hands-On: Three Cases, Three Different Answers

All three emails below are sanitized and fictional — safe to study, no live senders or working links. For each one: read the headers, form your own call, then reveal the analyst verdict to check yourself.

Case 1 of 3

The Vendor Payment Update

Phishing, compromised account, or legitimate?
From"Argosy Freight — Accounts" <ap@argosyfreight-billing.com>
Toprocurement@example.com
SubjectUpdated Remittance Details — Please Confirm Receipt
Hi team, please note our banking details have changed as of this month. Kindly update your records and confirm receipt of this notice at your earliest convenience so future invoices are not delayed.
View Updated Bank Details → 
From: "Argosy Freight — Accounts" <ap@argosyfreight-billing.com>
To: procurement@example.com
Subject: Updated Remittance Details — Please Confirm Receipt
Date: Mon, 10 Aug 2026 09:02:11 +0000
Message-ID: <a41ce-remit@argosyfreight-billing.com>
Received: from mail-relay-77.cheaphost.example.net (198.51.100.201)
        by mx.examplecorp.com; Mon, 10 Aug 2026 09:02:34 +0000
Authentication-Results: mx.examplecorp.com;
    spf=fail (198.51.100.201 is not authorized to send for argosyfreight.example) smtp.mailfrom=argosyfreight-billing.com;
    dkim=none (message not signed);
    dmarc=fail (p=REJECT) header.from=argosyfreight-billing.com
Domain
Lookalike domain, not the real one. Argosy Freight's real domain is argosyfreight.example — this message comes from argosyfreight-billing.com, a similar but entirely separate registration.
Auth
Fails outright, no alignment question involved. spf=fail, dkim=none, dmarc=fail — there's no legitimate-third-party-sender explanation here, because the domain itself isn't Argosy's.
Content
Unsolicited bank-detail change, no verification path. A generic "confirm receipt" link with no phone number or secondary channel offered is itself a pattern worth flagging regardless of the header result.
Reveal Analyst Verdict
Verdict: Phishing

This is the straightforward case: a lookalike domain that fails every authentication check. This is the pattern the Basic lab's checklist is built to catch. Case 2 is where it gets harder.

Case 2 of 3

The Reply on an Existing Thread

Phishing, compromised account, or legitimate?
From"Priya Raman — Argosy Freight" <priya.raman@argosyfreight.example>
Toap@example.com
SubjectRe: Invoice #4471 — please use our new bank details
Hi, following our earlier invoice thread — our finance team completed a routine bank audit and moved to a new account this week. Could you please route the pending payment for INV-4471 to the updated details below instead? Sorry for the short notice, trying to close this out before month-end.
New Bank Details (PDF) → 
From: "Priya Raman — Argosy Freight" <priya.raman@argosyfreight.example>
To: ap@example.com
Subject: Re: Invoice #4471 — please use our new bank details
Date: Fri, 14 Aug 2026 22:47:03 +0000
Message-ID: <9c2f-thread@argosyfreight.example>
References: <4471-orig@argosyfreight.example>
Received: from mail.argosyfreight.example (mail.argosyfreight.example [203.0.113.90])
        by mx.examplecorp.com; Fri, 14 Aug 2026 22:47:19 +0000
Authentication-Results: mx.examplecorp.com;
    spf=pass smtp.mailfrom=argosyfreight.example;
    dkim=pass header.d=argosyfreight.example;
    dmarc=pass (p=REJECT) header.from=argosyfreight.example
Domain
Genuine domain — no spoofing here. This really is argosyfreight.example, the vendor's actual, previously-trusted domain.
Auth
SPF, DKIM, and DMARC all pass and align. Every technical signal this lab has taught you to check says this message is authentic — because it genuinely was sent from Priya's real, authenticated mailbox.
Timing
Sent 22:47 UTC — outside Argosy's normal business hours for a finance-approval message, on a thread that otherwise sent during working hours.
Ask
Unverified bank-detail change requested entirely over email, with manufactured urgency ("before month-end") — the exact pattern a compromised mailbox is used for once an attacker has read enough of the real thread to sound convincing.
Reveal Analyst Verdict
Verdict: Likely Compromised Account (BEC)

Passing every header check is exactly what you'd expect from a hijacked real mailbox — technical authentication was never designed to catch this. The tell here is entirely behavioral: an unscheduled bank-detail change, requested only over email, with urgency attached. This is the scenario the Hard lab investigates end-to-end, including how the account was likely compromised in the first place.

Case 3 of 3

The Automated Invoice Notice

Phishing, compromised account, or legitimate?
From"Quickledger Invoicing" <notifications@mail.quickledger-app.example>
Toap@example.com
SubjectNew invoice available from Argosy Freight — INV-4471
A new invoice from Argosy Freight & Logistics is ready for your review on Quickledger. No payment details are included in this email for your security — sign in to your Quickledger account to view and approve.
View Invoice on Quickledger → 
From: "Quickledger Invoicing" <notifications@mail.quickledger-app.example>
To: ap@example.com
Subject: New invoice available from Argosy Freight — INV-4471
Date: Tue, 11 Aug 2026 14:20:55 +0000
Message-ID: <inv-4471-notice@mail.quickledger-app.example>
Received: from mta7.quickledger-app.example (mta7.quickledger-app.example [192.0.2.140])
        by mx.examplecorp.com; Tue, 11 Aug 2026 14:21:03 +0000
Authentication-Results: mx.examplecorp.com;
    spf=fail (192.0.2.140 is not authorized to send for argosyfreight.example) smtp.mailfrom=mail.quickledger-app.example;
    dkim=pass header.d=quickledger-app.example;
    dmarc=pass (p=QUARANTINE) header.from=quickledger-app.example
SPF
SPF "fail" looks alarming but is a red herring here. The message never claims to be from argosyfreight.example — the visible From: domain is quickledger-app.example, an invoicing platform, and that's the domain that matters.
DKIM
DKIM passes and aligns to the domain actually shown to the reader. header.d=quickledger-app.example matches header.from=quickledger-app.example exactly — this is Scenario C from the alignment diagram above.
DMARC
DMARC passes because DKIM alignment alone is sufficient — SPF failing doesn't matter once one of the two checks aligns.
Content
No payment details or urgent action requested — it's a routine "sign in to view" notification, consistent with how invoicing SaaS platforms normally behave.
Reveal Analyst Verdict
Verdict: Legitimate

If you flagged this one as suspicious because of the SPF failure alone, that's exactly the false-positive trap this lab is designed to surface — an unaligned SPF result on a third-party platform's own domain is expected, not evidence of spoofing. Always check what domain the message is actually claiming to represent before judging the auth result.

Why This Matters

Why this matters: A SOC that treats every SPF failure as malicious and every auth pass as safe will both drown in false positives and miss real Business Email Compromise cases — because BEC's whole premise is using a real, authenticated mailbox. Reading alignment correctly, and knowing when to stop trusting headers and start asking "does this request make sense coming from this person, right now," is what separates a header checklist from real analysis.

How to Detect & Protect

  • Check alignment, not just pass/fail — confirm the domain that passed SPF or DKIM is actually the same domain shown in the From: header before trusting the result.
  • An SPF fail from a known third-party platform isn't automatically malicious — check whether DKIM aligns to the sender's own domain before flagging.
  • Never trust a bank-detail or payment change sent only by email, even from a real, previously-trusted, fully-authenticated address — verify by phone using a number you already had on file, not one in the message.
  • Watch for timing and tone shifts on an existing thread — an unusual send time, uncharacteristic urgency, or a request that breaks from normal process are stronger signals than headers once an account is genuinely compromised.
  • Treat "the domain is real" as the start of the analysis, not the end — a compromised legitimate account is the one case authentication alone cannot catch.