A procurement diagnostic, not a vendor comparison.
This matrix maps five email security detection technologies against their architectural strengths and structural limitations. Use it to understand what your current vendor is built around versus what it uses as a component, and to test vendor claims during procurement against written evidence of actual architecture.
Vendors will claim their platform uses all five technologies, then frame the combination as complete coverage. Using a technology is not the same as being designed around it. A platform can use behavioral ML and still be blind on first-contact threats because behavioral ML is a supporting layer, not the design center. The work below is to distinguish between what a platform is built around and what it bolts on.
Fast and cost-effective on commodity malware variants and previously catalogued campaigns. Generates few false positives because signatures target specific observed attack behaviors with minimal abstraction.
Cannot catch attacks that do not match previous examples. Effectiveness drops below statistical significance when attack similarity falls under roughly 0.30 Jaccard distance, meaning novel phishing templates, polymorphic payloads, and first-contact spearphishing defeat pattern libraries by design.
If your vendor says they are designed around pattern matching, the test is whether daily quarantine review was your IT team's primary workflow before you deployed their platform. If the answer is no, the rules layer is a supporting component, not the core.
Ask for production detection rules that fired on first-contact threats from senders with no prior communication in your internal email graph in the last 90 days. If they cannot cite the rule in writing with the exact sender domain and recipient, the claim that rules catch novel attacks is positioning.
Near-zero compute cost and high confidence on previously observed infrastructure and campaigns. Essential baseline for blocking known malware distribution infrastructure.
Reactive by definition and increasingly evaded by attacks routing through legitimate cloud infrastructure with clean reputation at delivery time. Phishing originating from SendGrid, Microsoft 365 tenants, or Google Workspace accounts carries reputation that reputation services often do not flag as malicious because the platforms themselves are not malicious.
If your vendor says they are designed around threat intelligence, the test is whether a change in your threat intel feeds alone changes the vendor's detection rate. If the answer requires model retrain or rule updates, threat intel is not the design center.
Ask for production detections that fired on first-contact threats originating from domains without prior malware history, arriving from SendGrid or consumer cloud providers, in the last 90 days. If they cannot cite them in writing, the architecture misses attacks now routed through reputation-clean infrastructure.
Catches impersonation and compromised-account attacks that deviate from known-good behavior even when the message content looks legitimate. Effective on BEC where a trusted sender starts sending unusual instructions to unusual recipients.
Requires a learning period and blind on first-contact threats with no behavioral baseline. An attack on a new employee or a targeted recipient outside your organization's normal communication graph generates no deviation because no baseline exists. Channel-pivot attacks where the malicious action happens in Teams or Slack, not email, bypass email-based behavioral signals entirely.
If your vendor says they are designed around behavioral ML, the test is whether their detection on first-contact spearphishing to a new hire requires manual content review or behavioral feedback loop. If human review is required, behavioral models are a supporting layer.
Ask for production detections that fired on sophisticated first-contact spearphishing to recipients with fewer than five emails in the system without manual analyst intervention in the last 90 days. If they cannot cite them in writing, the architecture requires behavioral baseline.
Better semantic detection than regex on language-only BEC where the attack has no file attachment or link. Catches tone shifts that rule-based systems miss because the text itself carries the fraudulent intent.
Cannot verify claims, cannot reason across conflicting signals, and degrades when attacker vocabulary mirrors legitimate business language. If an email requests an urgent wire transfer using language indistinguishable from a real CFO in your industry, a single-pass LLM cannot arbitrate because it has no access to sender identity verification or communication history.
If your vendor says they are designed around NLU, the test is whether an email claiming to be from your CEO requesting an urgent wire transfer gets flagged based on language patterns alone, without access to any signal outside the message body. If the platform requires identity verification or behavioral baseline, NLU is a supporting layer.
Ask for production detections that fired on BEC emails requesting wire transfers to new bank accounts, where the detection fired based on language patterns alone and did not require verification against sender identity, communication history, or organizational payment rules. If they cannot cite them in writing, the architecture is not designed around NLU.
If the agents are designed correctly, this approach matches computational cost to attack difficulty and avoids the learning period required by purely behavioral systems. Trivial threats cost near-zero processing, novel threats get full reasoning capacity. The failure mode section below is where the actual risk lives.
Entirely dependent on agent design quality and the reasoning capability of the underlying foundation models. A naive implementation that collects evidence without feedback loops, caching, or verdict-to-evidence mapping becomes computationally expensive and difficult to audit. If agents collect signals but a separate classifier makes the final verdict, the architecture is agents-as-component, not reasoning-as-design-center.
If your vendor says they are designed around adaptive reasoning, the test is whether uncertainty in the system automatically triggers deeper signal collection by agents acting on their own confidence threshold, or whether an external classifier decides when agents activate. If a rules engine or ML model gates when agents run, reasoning is not the design center.
Ask your TAM for a production case where the system flagged sophisticated first-contact phishing, and have them walk through in writing which signals the agents collected, in what order, and what confidence threshold triggered each signal collection step. If they cannot show the agent reasoning trace in production logs, the claim is marketing.
Three steps. Push for production data, not narrative.
- Map. Ask each vendor to map themselves to the five technologies and classify whether each is designed-around or used as a component. Make them write it down.
- Probe. Ask the red-flag question specific to their claimed design center. Treat the answer like a deposition: vague answers count as a no.
- Verify. Request written production evidence from the past 90 days, and ask whether your organization's specific attack profile would activate that technology. Do not accept narrative. Push for production data.
Do you have an AI gap? Find out what’s getting through.
See which generations of defense you’re running and what it takes to close the gap. Two minutes. No signup. Nothing changes in your environment.