Volume phishing campaigns are a numbers game. An attacker sends 500,000 emails pretending to be Netflix, counts on 0.2% of recipients clicking before the blocklists catch up, collects credentials, and moves on. The email body is identical across every recipient. The sending domain is burned and replaced. The whole operation is industrialized.
Spear phishing is structurally different. The attacker sends one email, maybe ten. The target is a specific person — your CFO, your AP coordinator, the IT admin who holds domain registrar credentials. The email references the target's real name, their manager's name, an ongoing project, a recent invoice number. It arrives from a lookalike domain registered 48 hours ago, with valid DKIM signatures, SPF alignment, and DMARC passing.
Your volume-detection filters were not designed for this scenario. Understanding why is the first step toward closing the gap.
How MITRE ATT&CK Classifies the Distinction
MITRE ATT&CK maps phishing under Initial Access (TA0001), with three sub-techniques under T1566:
- T1566.001 — Spearphishing Attachment: malicious file delivered directly to a named target
- T1566.002 — Spearphishing Link: URL pointing to credential harvester or malware delivery page, personalized per recipient
- T1566.003 — Spearphishing via Service: abuse of legitimate platforms (SharePoint, DocuSign, LinkedIn messages) to deliver the lure
Volume campaigns primarily generate T1566.001 and T1566.002 traffic at scale with low personalization. Spear phishing operates across all three sub-techniques, but with targeted reconnaissance baked in. The attacker has read the target's LinkedIn profile, cross-referenced their company org chart, and possibly reviewed public SEC filings or press releases to identify specific names and relationships before composing a single word.
That reconnaissance investment changes the economics of detection. A volume campaign only needs to survive long enough for the first wave of clicks. A spear phishing email needs to survive long enough for one specific person to act — which means the attacker will iterate, test sending infrastructure, and craft body language that mirrors the target's actual working context.
What Signature-Based Filters See — and Miss
Signature-based email security tools operate on hashes, reputation scores, known-bad domains, and pattern-matched rules. For volume campaigns, this works well enough. The same payload hash appears 50,000 times in 30 minutes; reputation networks catch it fast. The sending IP hits blocklists. The malicious domain gets flagged by VirusTotal.
Spear phishing breaks this model at almost every layer:
- Novel domains: A lookalike domain registered two days ago has zero reputation history. SPF, DKIM, and DMARC are all correctly configured — the attacker set them up deliberately. The MX record, WHOIS data, and sending IP are all fresh. No blocklist has seen them.
- No malicious payload at time of scan: Many spear phishing emails contain only a plain-text message and a link. The linked page may be a legitimate-looking Microsoft 365 login clone that's clean at the time of delivery and only activates its harvesting function after the first click. Safe Links and ATP URL scanning that check at delivery time can be bypassed by time-of-click page swaps.
- Social engineering in plain text: The malicious content is the language itself — the urgency, the authority claim, the business context. No attachment to hash. No URL to detonate. A rules engine that matches on "re: invoice" or "wire transfer" will generate massive false positives across legitimate finance operations without catching the one well-crafted BEC attempt.
Consider a plausible scenario: a 650-employee manufacturing company in the Midwest. Their IT team runs Microsoft 365 E3 with Defender for Office 365 Plan 1. An attacker registers [company-name]-invoicing.com 72 hours before the attack, sets up valid SPF/DKIM/DMARC records, and sends a single email to the AP coordinator referencing a real vendor name found on LinkedIn. The email passes all authentication checks. Defender's reputation lookup on the sending domain returns nothing (too new). The email body contains a DocuSign-lookalike link — no attachment, no known-bad URL — redirecting through a legitimate URL shortener before landing on a credential page. It reaches the inbox.
The Reconnaissance Phase You're Probably Underestimating
Before a well-resourced spear phishing attacker sends anything, they typically spend hours to days in open-source intelligence (OSINT) collection. LinkedIn reveals the org chart, reporting relationships, and tenure. Company press releases identify recent hires, promotions, and M&A activity. SEC filings for public companies expose specific vendor names, contract values, and upcoming payment cycles. Job postings reveal what technology the company uses — "experience with SAP S/4HANA preferred" tells an attacker which ERP platform to impersonate.
This is why effective spear phishing emails don't sound like phishing emails. They sound like internal communication. They reference the right names, the right projects, the right cadence. The Verizon Data Breach Investigations Report consistently identifies pretexting — the creation of a fabricated scenario to manipulate a target — as the dominant social engineering technique in financially motivated BEC attacks, with email as the primary delivery channel.
It's worth being precise about what we're not saying here: we're not saying that all targeted attacks are nation-state operations requiring sophisticated tooling. Many spear phishing campaigns targeting mid-market companies are run by financially motivated criminal groups who simply put more effort into each email than volume spammers do. The barrier to targeted reconnaissance is low; the barrier to catching it with traditional filters is high.
Email Authentication Is Necessary but Not Sufficient
SPF (RFC 7208), DKIM (RFC 6376), and DMARC (RFC 7489) are foundational controls and you should have them fully deployed. A DMARC policy of p=reject prevents direct domain spoofing — an attacker cannot send email from your actual domain and have it authenticate. BIMI (Brand Indicators for Message Identification) adds visual logo verification for receivers that support it.
But spear phishing rarely involves direct domain spoofing. The attack surface is lookalike domains and display name deception, neither of which DMARC addresses. company-invoices.com can pass DMARC perfectly. An email with display name "John Smith — Accounting" can pass every authentication check while the actual sending address is jsmith@[random-domain].com.
ARC (Authenticated Received Chain) addresses authentication preservation through forwarding chains — useful for mailing lists and email forwarding scenarios — but it doesn't solve the lookalike domain problem either.
Email authentication tells you whether an email came from the domain it claims to come from. It says nothing about whether that domain is one character off from your CFO's actual address, and nothing about whether the content of the email is an attempt to manipulate a specific person into a specific action.
What Effective Spear Phishing Defense Actually Requires
Defending against targeted email attacks requires controls at a different layer than signature matching and authentication verification. The capabilities that close the gap include:
- Semantic analysis of email body language: Detecting urgency manufacturing, authority impersonation, and anomalous request patterns in the text itself — not matching keywords, but understanding the communicative intent of the message. This is where LLM-based email inspection provides coverage that rules engines structurally cannot.
- Lookalike domain detection: Comparing the sending domain against registered domain variants of your own domain and those of your known vendors, flagging visual similarity regardless of authentication status.
- Behavioral baselines per mailbox: Establishing what "normal" looks like for a specific user's incoming mail — who sends to them, at what frequency, from which domains — and surfacing deviations. A first-time sender from a 3-day-old domain referencing an ongoing project by name is anomalous; behavioral baselining catches it.
- URL detonation: Actually rendering the page in an isolated environment rather than checking the URL against a static blocklist. See our URL sandboxing coverage for how detonation-based analysis catches time-delayed payloads.
NIST SP 800-53 control SI-8 (Spam Protection) and the NIST Cybersecurity Framework's Detect function both point toward multi-layer email controls rather than single-technology deployment. The SP 800-181 workforce framework includes spear phishing awareness as a competency for security operations roles precisely because the human element remains in the attack path even when technical controls are strong.
The operational question for mid-market IT teams is not whether volume phishing or spear phishing is more dangerous — both cause real damage. The question is whether your detection stack is calibrated for the attack type that causes the most financial loss per incident. FBI IC3 data consistently shows BEC and targeted phishing driving the largest dollar losses, at average losses per incident that dwarf credential-stuffing-type volume attacks.
A well-tuned technical stack handles volume campaigns adequately. Targeted attacks require a different inspection layer — one that reads the email the way a suspicious security analyst would, not the way a hash-matching engine does. That shift in detection philosophy is what separates organizations that catch spear phishing before the click from those that find out about it during the incident response.