Signature-based email security has a clear value proposition: it is fast, deterministic, and cheap per-message. A hash lookup takes microseconds. A blocklist check against a reputation database adds a few milliseconds at most. For the bulk of email threat volume — mass credential phishing campaigns, commodity malware attached as Office documents, known-bad sending IPs — these controls work and work well. There's no reason to replace them.
The problem is not what signature detection does. The problem is what it structurally cannot do. Understanding that boundary clearly is what allows you to build a layered detection stack where each component covers the gaps the others leave open.
How Signature Detection Actually Works
Signature-based detection in modern email security systems operates across several distinct mechanisms, often conflated under the generic label "filters":
- Hash matching: A known-malicious file attachment produces a consistent hash (MD5, SHA-256). Once that hash is in a threat intelligence database, any future message with that exact attachment is caught instantly. Fast, zero false positives on true hash matches.
- IP and domain reputation: Sending IP addresses and domains are scored against databases like Spamhaus, SURBL, and commercial threat feeds. New sending infrastructure has no history, which is why freshly registered domains evade this check.
- Rule-based pattern matching: Rules matching on specific URL patterns, attachment types, or textual patterns (e.g., messages containing specific banking keywords + wire instructions). These require regular maintenance and generate false positives as legitimate business language overlaps with phishing language.
- ML classifiers trained on labeled datasets: Most commercial SEGs (Secure Email Gateways) use gradient-boosted classifiers or similar models trained on labeled phishing versus legitimate mail corpora. These generalize better than pure signature matching but still operate on extracted features (URL entropy, attachment metadata, sending patterns) rather than semantic understanding of message content.
Microsoft Defender for Office 365, Proofpoint TAP, and Mimecast all incorporate combinations of these mechanisms. They are effective at their intended scope: high-volume, known-pattern threats. Microsoft's own published benchmarks show Defender catching upward of 99% of known-signature-matching malware in Exchange Online — a real number for a real threat category.
Where Signature Detection Hits a Structural Ceiling
Signature detection requires prior knowledge of the attack. A hash has to have been seen before. A domain needs to be old enough to have reputation data. A pattern rule needs to match the specific phrasing the attacker used this time.
Spear phishing and BEC attacks are specifically designed to avoid all three preconditions. Consider what a well-prepared BEC attempt looks like from an inspection standpoint:
- Sending domain registered within 72 hours — zero reputation data
- Valid SPF, DKIM, DMARC — passes all authentication checks
- No malicious attachment — nothing to hash
- No malicious URL at time of delivery — the lure is purely in the text
- Email body in plain text or minimal HTML — no obfuscated encoding to detect
Against this profile, every signature check returns clean. The email reaches the inbox. The only detectable signal is in the language itself — the social engineering mechanics embedded in how the request is phrased.
For a concrete illustration: a 2,400-employee healthcare network in the Pacific Northwest received a six-message email thread in early 2024 (scenario plausible given documented attack patterns). The thread appeared to come from a known IT vendor's domain — actually a one-character lookalike registered three days prior. The messages discussed an upcoming server maintenance window that matched the real vendor's scheduled visit. In the fifth message, a request to "update payment ACH details before the contract renewal" was embedded. Every signature check on every message in the thread returned clean. The request was processed. The attack succeeded because no component of the signature-based stack was designed to evaluate whether the semantic trajectory of a conversation across multiple messages was consistent with the apparent business relationship.
What LLM-Based Analysis Does Differently
Large Language Models applied to email inspection operate on a fundamentally different principle. Instead of matching observed features against known-bad patterns, an LLM reads the email the way a trained analyst would: evaluating intent, detecting social engineering mechanics, assessing whether the message's request is contextually appropriate for the claimed sender-recipient relationship.
The specific capabilities this unlocks:
- Urgency and authority detection: Identifying manufactured urgency ("this needs to be done in the next 20 minutes or the deal falls through") and false authority claims ("the CEO has asked me to handle this personally") as semantic patterns, regardless of the specific words used to express them.
- Contextual anomaly detection: Flagging requests that are inappropriate for the claimed context — a vendor asking for banking details in a thread about a service issue, an "internal IT" message from an external domain, a first-time sender referencing specific internal project names.
- Linguistic consistency checking: Comparing the writing style, vocabulary level, and communication patterns in an email against historical baselines for the claimed sender — detecting when an attacker's language doesn't match the persona they're impersonating.
- Cross-message thread analysis: Evaluating semantic coherence across a multi-message thread, detecting the kind of mid-conversation injection that marks multi-stage ATO or VEC attacks.
None of these capabilities require prior knowledge of the specific attack. The LLM doesn't need to have seen this particular BEC template before. It evaluates the message's intent and contextual appropriateness from first principles, which means zero-day phishing and novel attack framings receive the same level of inspection as known campaigns.
The Real Tradeoff: Latency, Cost, and False Positive Rate
LLM-based inspection is not a free upgrade. It is computationally heavier than signature checks — inference on even a lightweight deployed model adds latency measured in hundreds of milliseconds to seconds per message, not microseconds. For high-volume environments, this requires careful architectural decisions about which messages route to LLM inspection versus which are handled by fast-path signature checks.
The practical approach is tiered analysis. Signature checks and authentication validation run first, fast, on everything. Messages that pass these checks but show contextual risk signals — first-time senders, new domains, lookalike addresses, anomalous send times — are routed to deeper LLM inspection. This keeps the latency hit contained to the messages where it matters.
False positive rate deserves direct treatment. A criticism of LLM-based content analysis is that it could flag legitimate emails with high-urgency language as suspicious — a real CFO asking about a time-sensitive payment, a genuine IT alert about an expiring certificate. This is a real concern that requires careful calibration. The goal is not to flag all urgency, but to detect urgency in combination with other social engineering signals: urgency + first-time sender + domain registration recency + request for action that bypasses normal approval processes. The intersection of multiple signals reduces false positives substantially compared to single-signal rules.
We're not saying signature detection is obsolete or that every organization needs LLM inspection tomorrow. We're saying there's a class of targeted threat — specifically spear phishing, BEC, and vendor email compromise — for which signature detection has a structural ceiling, and LLM-based semantic analysis addresses the gap. For organizations where these threat types are the primary risk vector (and FBI IC3 data suggests they are for mid-market finance and healthcare), the cost-benefit case for adding semantic inspection is clear.
Integration Architecture: How the Two Layers Work Together
In an M365 environment, the layered approach looks like this: Defender for Office 365 handles the known-threat, high-volume layer through its native stack — EOP (Exchange Online Protection) for spam and malware, Safe Links for URL rewriting, Safe Attachments for sandboxed file detonation, anti-spoofing policies, and DMARC enforcement. These are the right tools for their scope and should be fully configured before adding supplemental layers.
A supplemental LLM-based inspection layer connects via the Microsoft Graph API (specifically the Mail.Read scope with appropriate delegated or application permissions) to provide the semantic analysis layer on messages that pass the Defender stack. This is a technical integration via OAuth 2.0 and the Microsoft Graph API, not a replacement for Defender's capabilities.
For Google Workspace environments, the equivalent flow uses the Gmail API (gmail.readonly scope) with Pub/Sub push notifications for near-real-time inspection, with the same tiered triage logic: fast-path signature and authentication checks first, semantic inspection on elevated-risk messages.
NIST SP 800-53 SI-3 (Malicious Code Protection) and SI-8 (Spam Protection) both explicitly call for layered controls rather than reliance on a single detection mechanism. The two-layer architecture described here — signature detection for known threats, semantic analysis for targeted social engineering — directly implements that layered approach. The question for your environment is whether the threat model justifies the additional inspection layer; for organizations handling sensitive financial data or operating in sectors targeted by BEC campaigns, the answer is straightforwardly yes.