The Phishing Field Guide: 5 Lures & Their Header Tells

It’s 4:30 PM on a Friday. An email lands with the subject 'Urgent: Invoice INV-2026-8675309 Overdue'. The sender is your key supplier's AP department. For a half-second, your stomach drops. You open it. There's a PDF, a demand for immediate payment, and a plausible backstory. This is the moment of truth, and it has almost nothing to do with the message body.

The most damaging phishing attacks are rarely novel. They are recycled plays that prey on process, habit, and human psychology. Attackers don't need zero-days when a well-crafted email impersonating a trusted brand works just as well. But these emails are not ghosts; they leave fingerprints all over the headers. The job of an analyst isn't just to spot the lure, but to read the forensic trail it leaves behind. This is that guide.

The Imposter Document: DocuSign & Adobe Clones

The Lure

The 'contract' or 'agreement' phish is a perennial favorite. It combines a trusted brand name with a sense of business urgency. 'Your document is ready for signing.' Who wants to be the one holding up a deal? The email is a pixel-perfect replica of a real DocuSign or Adobe Sign notification. The entire payload is loaded into a single, enticing button: 'Review Document'.

The link, of course, doesn't lead to a document. It directs you to a credential harvesting site skinned to look like DocuSign, Microsoft, or Google, asking you to 'log in to securely view the file.' A successful compromise here gives the attacker access to a legitimate inbox they can then use for more convincing internal phishing.

The Header Tells

This is a classic case of authentication misalignment. The `From:` header might say `docusign.net`, but the email was not sent by DocuSign's mail servers. Your first stop is the `Authentication-Results` header. You're looking for the DMARC (RFC 7489) result. It will almost certainly be `dmarc=fail`.

Why? DMARC requires *alignment*. For SPF to be aligned, the domain in the `MAIL FROM` command (often found in the `Return-Path` header) must match the domain in the `From:` header. For DKIM (RFC 6376) to be aligned, the signing domain (the `d=` tag in the `DKIM-Signature` header) must match the `From:` header domain. The phisher, sending from their own bulk email service, can't meet these conditions. They might get SPF and DKIM to `pass` for their own garbage domain, but they will fail DMARC alignment against `docusign.net`. This is the dispositive proof of forgery.

The Payroll Panic: Internal HR Lures

The Lure

Few things get a user to click faster than a message about their paycheck. 'Action Required: Update Your Payroll Information' or 'Problem with Your Direct Deposit' are brutally effective lures. They bypass corporate cynicism and hit a personal nerve. The goal is to route the user to a fake HR portal to steal credentials, or worse, have them directly submit new banking details for their next paycheck.

The Header Tells

This case is tricky. Often, the attack originates from a compromised account within your own organization. A user clicked a previous phish, and now their M365 account is an attacker-controlled beachhead. The email they send to your colleague will pass SPF, DKIM, and DMARC with flying colors because it *is* an internal email, sent from your own mail infrastructure.

Here, standard authentication checks are useless. You need to dig deeper into the metadata. Check the `X-Originating-IP` header. Does it point to a Tor exit node, a known VPN service, or a hosting provider's IP range instead of a typical residential or corporate ISP? Correlate the timestamp with the user's known location and working hours. Look at the `Received` headers. Is there an unusual client specified, like 'Microsoft Outlook for Android' when the user famously never uses their phone for email? This is where context, not just protocols, reveals the threat.

The Quarantine Mirage: Weaponizing Security

The Lure

This is a brilliantly cynical attack that uses your own security posture as the vector. The email mimics a quarantine notification from Microsoft 365, Proofpoint, or Mimecast. 'You have 3 messages pending release,' it claims, with a button to 'Review & Release'. Users have been trained to expect these, and they fear missing a legitimate message. The link leads to a perfect replica of the Microsoft login page.

The Header Tells

The primary tell is a lookalike or cousin domain. The attacker can't use `microsoft.com`, so they register something visually similar: `microsft.com`, `mìcrosoft.com` (a homograph attack using Punycode), or a subdomain like `microsoft.security-alerts.com`. The human eye scans past it. The email server does not.

Authentication-Results: mta.example.com; dkim=none (no signature) header.d=none; spf=pass smtp.mailfrom=attacker.net; dmarc=fail action=reject header.from=microsoft.com

That `Authentication-Results` header tells the whole story. SPF passed, but only for `attacker.net`—the domain in the envelope `MAIL FROM`. DKIM wasn't even present. Crucially, DMARC checked for alignment against the `header.from` domain (`microsoft.com`) and found none, resulting in a `fail`. A properly configured mail gateway should block this outright based on the DMARC `action=reject`.

The Evasive Payload: Voicemail & QR Codes

The Lure

As email gateways get better at scanning URLs and attachments, attackers have shifted to payloads that exist outside the email body's text. Voicemail-themed (vishing) and QR code-based (quishing) attacks are on the rise. The email is sparse: 'You have a new voicemail' or 'Scan to access the shared file'. The payload is an image containing a QR code or simply a phone number to call. This bypasses many traditional scanners looking for malicious links.

The Header Tells

These emails are often low-effort. The sender is usually a throwaway account from a free webmail provider like Gmail or Outlook.com. While a message from `no-reply@voicemail.yourcorp.com` is expected, one from `sharon.smith8412@gmail.com` is an immediate red flag. The authentication headers will likely be valid for `gmail.com`, but the context is what matters. Why is your corporate voicemail system using a consumer email account? It isn't.

Trace the `Received` headers. You can map the journey of the email from the sender's client all the way to your mail server. You'll see servers like `mail-sor-f69.google.com` in the path. This confirms the origin is Google's infrastructure, reinforcing that it's not a legitimate corporate system. The failure here isn't a protocol one; it's a policy and context failure. Block executable content, but also be highly suspicious of consumer ESPs masquerading as business services.

The Supply Chain Gambit: Vendor Invoice Fraud

The Lure

Business Email Compromise (BEC) targeting the supply chain is the big one. It's the source of most major financial losses from email fraud. The scenario is the one from the introduction: an email from a known vendor's finance contact with an invoice. The twist? 'We have updated our banking information. Please direct all future payments to the account listed in the attached document.' The request seems legitimate because it comes from a legitimate source.

The Header Tells

In the most dangerous variant, the email originates from your vendor's actual, compromised mailbox. Here, the headers will be pristine. SPF (RFC 7208) will pass. DKIM will pass and align. DMARC will pass. From a technical perspective, the email is legitimate. The authentication protocols have done their job; they have verified the *sending server*, not the *human sender's intent*. This is the critical limitation of email authentication. The investigation must move beyond headers to social engineering indicators.

A slightly less sophisticated version involves forwarding. Imagine the attacker sends a phish to `contact@vendor.com`, which automatically forwards to your actual contact, Jane. That forwarding step is notorious for breaking email authentication. The intermediate server becomes the new sending server, which is almost never in the original domain's SPF record. This causes an SPF fail. If the forwarding server adds a footer (like '[EXT] This email originated from outside the organization.'), it can break the DKIM signature by modifying the message body. The email arrives at your inbox with failed authentication. This is where the Authenticated Received Chain (ARC), defined in RFC 8617, becomes essential. ARC creates a cryptographic signature over the authentication results at each hop. By inspecting the `ARC-Seal` and `ARC-Authentication-Results` headers, you can see the original `pass` verdict from before the forwarder broke everything.

The takeaway

Threat actors are creatures of habit. They reuse the same five or six basic plays because they work. They exploit predictable human behaviors and gaps in business processes, not just software vulnerabilities. The templates evolve—QR codes replace malicious links, deepfake audio might replace a simple callback number—but the underlying patterns remain.

The headers don't lie. They contain the objective, machine-readable story of an email's journey and authenticity. Learning to read them is not an academic exercise; it's the core skill of modern email threat hunting. Don't just trust the display name. Don't just click the link. Pop the hood, read the `Authentication-Results`, and trace the `Received` chain. Tools like MailSleuth.AI can surface these signals automatically, but an analyst who can interpret them from first principles is indispensable.