You lose the upstream threats that were already blocked, so the score no longer reflects total protection. That creates a false comparison between inline prevention and post-delivery cleanup, and it can make one architecture look weaker simply because it sees a larger threat population. The right test is to compare identical inbound mail streams, not residues.
What measurement breaks when you count only mailbox-layer threats?
The measurement stops describing protection and starts describing residue. If you only count threats that made it into the mailbox, you ignore the upstream attacks that were intercepted earlier, so the metric undercounts what the control actually handled. That makes post-delivery cleanup look more complete than it is, while inline prevention is penalised for seeing a larger threat set.
Why the comparison becomes misleading
The core problem is denominator mismatch. Two email security architectures can face the same inbound mail stream but observe different points in the journey: an inline filter measures blocked and delivered threats, while a mailbox-only view measures only what survived to delivery. When those views are compared directly, you are no longer comparing total protection, you are comparing different slices of the attack path. That is why measurement should follow the same inbound traffic, not the same visible residue.
Mailbox-only counting also hides the operational value of stopping malicious mail before it reaches users. If prevention is invisible in the score, teams may conclude that a stronger upstream control is weaker simply because it records more detections. In practice, the opposite can be true: more observed threats can mean better interception, broader visibility, and less user exposure.
What a fair test should measure instead
A fair comparison needs identical inbound mail streams and an agreed boundary for success. Measure the full volume arriving at the email perimeter, then account for what was blocked, quarantined, delivered, and remediated after delivery. CISA cyber threat advisories are useful here as a reminder that threat handling should be evaluated across the whole path from initial exposure to response, not only at the final user-visible stage.
That also means separating protection efficacy from cleanup efficiency. A control that prevents more malicious mail may create a larger blocked-threat count, but that is evidence of interception, not weakness. Conversely, a system that reports fewer threats because it only measures mailbox-layer residue may simply have less visibility. For broader control mapping, CIS Controls v8 is a useful companion because it frames account management, logging, and defence as operational safeguards rather than as a single endpoint metric.
Where email threats are part of a broader access-abuse pattern, mailbox-only metrics can also miss the credential and payload stages that follow delivery. The same malicious message may be the first step in token theft, session abuse, or lateral movement, which means outcome measurement should stay tied to the attack chain rather than to one inbox event. MITRE ATT&CK Enterprise is useful as a reference point for thinking about that chain, because it makes credential access and follow-on movement visible as distinct phases.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Email threat measurement depends on complete visibility across blocked and delivered events. |
| Recommendation — Log blocked, quarantined, and delivered mail events so protection is measured across the full inbound stream. | ||
| MITRE ATT&CK | T1566 — Phishing | The question concerns how email attacks are counted and compared across the attack path. |
| Recommendation — Map email detections to phishing techniques and track events through delivery, user interaction, and response. | ||
Practitioner Guidance
What to verify: Confirm that any email-security score includes blocked, quarantined, delivered, and remediated mail from the same inbound stream. If a dashboard can only report what reached the mailbox, treat it as a residue report, not a protection score.
Common mistake: Do not compare an inline prevention stack with a post-delivery remediation stack using mailbox-visible threats only. That shortcut rewards late detection and makes early interception look like extra workload instead of reduced exposure.
What good looks like: A useful measurement model shows how many malicious messages were stopped before delivery, how many were delivered, and how much user exposure remained after controls acted. The control with the better total outcome is the one that reduces end-to-end risk, not the one that reports the smallest visible count.
Practitioner takeaway: If the metric cannot see blocked threats, it cannot tell you how much protection you actually have, only how much residue got through.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org