Email security benchmarks expose the hidden cost of partial visibility

At a glance

What this is: This analysis argues that email security benchmarks can mislead when they measure only post-delivery residue instead of the full inbound threat stream.

Why it matters: For IAM and security teams, the issue matters because email remains a primary route to credential theft, inbox compromise, and user-targeted attack delivery across human and non-human workflows.

By the numbers:

• The 2026 Verizon DBIR showed that the presence of the human element increased to 62% of breaches this year.
• Across 696 production customer assessments, the median customer running Proofpoint in front of Microsoft Defender catches an additional 27.1% of threats.
• Behind Microsoft, customers see a median of 408 advanced threats delivered per 1,000 users.
• Proofpoint says its real-world detection rate is 99.999%, with fewer than one false positive in every 30 million messages.

👉 Read Proofpoint's analysis of email security efficacy and measurement gaps

Context

Email security benchmarks are only useful if they measure the same threat population at the same point in the mail flow. When an inline gateway sits in front of Microsoft 365 or Google Workspace, messages it blocks never reach the provider stack, which means post-delivery-only measurement can understate exposure. This is a visibility problem, not just a product comparison problem, and it shapes how security teams judge control effectiveness.

The identity angle is direct: phishing, credential theft, and business email compromise remain common ways attackers reach human users and trusted systems. For IAM, PAM, and NHI programmes, email is often the first hop in a chain that ends in account takeover, token abuse, or delegated access misuse. The typical measurement blind spot is structural, which means many organisations are comparing residue, not protection.

Key questions

Q: What fails when email security benchmarks only measure post-delivery cleanup?

A: They measure residue rather than prevention, which can undercount threats stopped upstream by an inline gateway. That makes mailbox-native controls look stronger or weaker than they really are, depending on the deployment path. For procurement, the failure is not the technology alone, but the comparison model that ignores where in the mail flow the threat was actually stopped.

Q: Why do phishing and BEC remain identity risks even when email controls are in place?

A: Because email is often the first trust channel attackers use to reach users, service desks, and cloud identities. A malicious message can trigger credential theft, MFA fatigue, payment fraud, or delegated access abuse before downstream IAM controls ever see an alert. Email security is therefore part of identity defence, not just message filtering.

Q: How do security teams know whether an email control is actually blocking threats?

A: They should compare blocked, delivered, and remediated messages using the same threat IDs and the same time window across all layers. If the report cannot show what was prevented before delivery, what arrived in the inbox, and what was cleaned up later, the measurement is incomplete and should not drive a buying decision.

Q: Who is accountable when a mailbox-based benchmark hides upstream email filtering?

A: The buying team is accountable for insisting on a measurement model that reflects the real architecture, and the vendor is accountable for disclosing exactly what is being counted. Frameworks such as NIST CSF and NIST SP 800-53 expect traceable, auditable controls, so unverifiable comparisons should never be treated as evidence of protection.

Technical breakdown

Inline gateway versus post-delivery detection in email security

An inline secure email gateway inspects inbound mail before delivery, usually by sitting in SMTP flow ahead of Microsoft 365 or Google Workspace. A post-delivery integration only sees messages already accepted into the mailbox provider, so it measures remediation rather than prevention. That distinction matters because any benchmark limited to delivered mail omits threats blocked upstream and can overstate how much a native mailbox control was responsible for catching. The technical question is not simply which engine detected more, but where in the mail lifecycle the engine had a chance to act.

Practical implication: compare tools on the same mail path and insist on a full inbound threat population, not mailbox residue.

Why direct send and tenant-to-tenant delivery create blind spots

Direct Send and tenant-to-tenant delivery can bypass normal email security inspection paths in Microsoft 365 environments. Direct Send allows unauthenticated internal-looking messages, while tenant-to-tenant delivery can move mail directly between tenants without traversing the recipient’s security stack. In both cases, the message may never pass through the inline or API controls that benchmark reports usually count. That creates a blind spot where some threats are not just undetected, but effectively unmeasured because they never enter the comparison set.

Practical implication: validate that all inbound paths, including exceptions, are routed through the same inspection and logging controls.

How credit should be assigned in layered email defence

Layered email defence often includes an upstream gateway, native mailbox controls, and post-delivery remediation. If a message is blocked before delivery, the prevention credit belongs to the upstream layer, even if a downstream system later confirms the threat. If a message is cleaned up after delivery, that is remediation credit, not prevention. Mixing those categories turns architecture into accounting bias. The right way to evaluate efficacy is by unique threat ID, shared time window, and full exportable message data so the same event is not counted twice or claimed by the wrong layer.

Practical implication: demand exportable threat records and separate prevention from cleanup in every vendor comparison.

Threat narrative

Attacker objective: The attacker aims to get trusted email content in front of users, then convert that trust into account access, payment fraud, or broader identity compromise.

1. Entry occurs when attackers use phishing, Direct Send abuse, or tenant-to-tenant delivery to place malicious mail in front of users or bypass inspection entirely.
2. Escalation follows when a user clicks a credential theft link, opens a payload, or approves a fraudulent request, giving the attacker access to accounts or delegated trust.
3. Impact lands in inbox compromise, credential harvesting, business email compromise, or downstream access to cloud and identity systems.

NHI Mgmt Group analysis

Visibility debt is now a control problem, not a reporting problem: when teams benchmark only what survives upstream filtering, they create a false sense of efficacy that hides the real attack surface. The article shows that measurement point changes the result, which means procurement teams can mistake architectural placement for security performance. For email, identity compromise often begins before a mailbox control ever sees the message, so practitioners should treat visibility gaps as a governance defect.

Partial inspection is the named failure mode here, and it is more common than many programmes admit: if Direct Send, tenant-to-tenant delivery, or post-delivery cleanup are outside the measurement model, the benchmark does not represent the full control plane. That is a specific governance assumption failure, not a generic tuning issue. Organisations should define which inbound paths count as inspected, then enforce that definition across all vendors and all mail flows.

Email security is increasingly an identity-adjacent control, not a standalone filter stack: the first successful message often becomes the first successful identity attack. Credential phishing, BEC, and AI-assisted lures all exploit trust in human inboxes before they move into IAM, PAM, or NHI control domains. Practitioners should therefore assess email controls by their ability to prevent identity compromise, not just message delivery.

Measurement integrity should be treated as a procurement control: if vendors cannot provide raw, comparable, unique threat data, the comparison is not operationally trustworthy. That principle aligns with broader security governance: what cannot be reconciled cannot be audited. Teams should make exportability, shared time windows, and consistent attribution part of the buying requirement.

Pre-delivery versus post-delivery remains the decisive distinction for user protection: cleanup is valuable, but it is not equivalent to prevention, especially when the target is a user who may act before remediation occurs. The practical conclusion is that layered email defence should be designed and measured to reduce inbox exposure first, then use post-delivery remediation as a backstop.

What this signals

Partial visibility is the recurring governance failure across email, identity, and non-human access programmes. Once teams accept a measurement model that excludes upstream blocking or bypass paths, they lose the ability to explain where risk was removed and where it merely moved. That is why control design, logging scope, and reporting scope need to be aligned before any benchmark is used in procurement or assurance.

Measurement blind spot: when the inspected population is smaller than the actual attack population, the organisation is not comparing efficacy. It is comparing accounting rules. Teams that connect email, IAM, and NHI telemetry into a single trust chain will be better placed to spot where compromise starts and where it is merely remediated later.

For identity programmes, the practical signal is whether phishing and mailbox compromise data are being tied back to credential misuse, delegated access abuse, and service account exposure. If the organisation cannot trace that line, then it cannot prove whether email controls are reducing identity risk or just shifting detection work downstream.

For practitioners

• Standardise measurement at the same mail-flow point Require every proof-of-value exercise to compare controls against the same inbound stream, with identical time windows and the same definition of inspected traffic. If one tool sits inline and another sits post-delivery, normalise the comparison before making any purchase decision.
• Separate prevention credit from remediation credit Track blocked, delivered, and post-delivery cleaned messages as different outcomes. If a system removed a threat after delivery, do not count that result as equivalent to upstream prevention in board reporting or vendor scoring.
• Audit all bypass paths in Microsoft 365 and similar tenants Test Direct Send, tenant-to-tenant delivery, and any partner or SaaS mail path that may avoid the normal inspection stack. Document which flows are routed through security controls and which are not, then close the exceptions.
• Demand exportable raw threat records Insist on sender, recipient, subject, delivery time, detection time, message ID, and unique threat identifiers so you can reconcile claims independently. If a vendor restricts export or hides data behind gates, the evaluation cannot be verified.
• Tie email efficacy to identity-risk reduction Use phishing, BEC, and credential-harvest metrics as the business outcome, not just detection totals. That keeps email security accountable to the IAM and NHI consequences that actually matter when users or service accounts are targeted.

Key takeaways

• Email security benchmarks can mislead when they measure only what survives upstream filtering rather than the full inbound threat population.
• The article’s own data shows that deployment architecture and measurement point materially change efficacy results, which affects how teams should interpret vendor comparisons.
• Practitioners should separate prevention from remediation, audit bypass paths, and tie email security metrics directly to identity-risk outcomes.

Key terms

• Secure Email Gateway: A secure email gateway is a control layer that inspects email before it reaches users and can also inspect outbound mail. It filters malicious content, enforces policy, and reduces exposure to phishing, malware, and data leakage, but it does not replace identity governance or account monitoring.
• Post-delivery remediation: Security action taken after a message has already reached a mailbox or application. It can delete, quarantine, or flag content, but it becomes less effective when the same message has already been copied into downstream systems outside the control boundary.
• Direct Send: Direct Send is a Microsoft email delivery method that can allow messages to be routed in a way that looks internal or trusted to some controls. Security teams need to understand that trusted routing does not automatically mean trusted content, especially when adversaries are abusing the path.
• Tenant-to-tenant Delivery: Tenant-to-tenant delivery is a direct mail path between Microsoft 365 tenants that may avoid the recipient's normal security stack. It can be legitimate for SaaS workflows, but it also creates a bypass route if organisations do not force all mail through their own inspection and logging layers.

What's in the full article

Proofpoint's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact proof-of-value methodology used to correlate unique threat IDs across deployments and explain how the comparisons were normalised.
• The full breakdown of delivery-path differences between secure email gateway, API-based inspection, and post-delivery remediation models.
• Per-vendor missed-threat totals, false-positive and false-negative data, and the underlying assessment structure used to derive them.
• Examples of how the comparison changes when the email stack is measured before delivery instead of after it.

👉 Proofpoint's full post covers the threat counts, evaluation method, and delivery-path assumptions behind the benchmark.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It is designed for practitioners who need a stronger operating model for access, lifecycle, and trust decisions across identity programmes.