KRIs for email security

The KRIs in this domain measure whether your email security controls are producing the outcomes they're designed for: blocking malicious content before it reaches users, preventing domain spoofing, and creating a reporting culture where users who receive suspicious email surface it rather than click it.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. Email authentication enforcement rate

What to measure. Percentage of all email-sending domains, including primary brand domains, marketing domains, transactional email domains, and subsidiary domains, with SPF, DKIM, and DMARC configured at enforcement policy (DMARC policy=reject or quarantine).

Why it matters. Email authentication is the technical mechanism that prevents domain spoofing, the foundation of business email compromise. A domain with DMARC at policy=none means anyone on the internet can send email that appears to come from that domain. "We have DMARC" means nothing if the policy is monitoring-only. Enforcement is the control.

• Domain registrar: complete list of owned domains (primary, subsidiary, campaign, parked)
• DNS lookup: automated SPF/DKIM/DMARC policy check per domain (dig TXT _dmarc.example.com)
• DMARC monitoring platform (Dmarcian, Valimail, Proofpoint Email Fraud Defense): policy status and enforcement rate across domain portfolio
• Email service providers: each ESP (Mailchimp, Marketo, SendGrid) using your domain requires DKIM alignment, check per ESP

How to calculate. (Domains with DMARC at policy=reject or quarantine + SPF configured + DKIM aligned) ÷ (total email-sending domains) × 100

Status	Criteria
Green	100% of sending domains at DMARC enforcement; DMARC aggregate reporting active; parked domains with null MX + reject policy
Amber	All domains configured but one or more at policy=none; or subsidiary domains not yet configured
Red	Any sending domain with no DMARC; or primary brand domain at policy=none; or ESP sending domains not aligned

2. Email gateway threat effectiveness rate

What to measure. Percentage of malicious emails detected and blocked by the email security gateway before reaching user inboxes, segmented by threat category (phishing, malware, BEC/impersonation, spam), and the bypass rate (malicious emails that reach inboxes).

Why it matters. Gateway effectiveness rate is the signal that tells you whether your first-line defense is working. A gateway that blocks 99% of spam but misses 40% of targeted phishing is configured for the wrong threat. Bypass rate is the metric that drives gateway tuning, sandboxing investment, and the urgency of user training as a backup control.

• Email security gateway (Microsoft Defender for Office 365, Proofpoint, Mimecast, Abnormal Security): threat detection reports, blocked by category, delivered, quarantined, user-reported
• Post-delivery remediation: emails removed after delivery (campaigns that bypassed the gateway), count and threat category
• Threat intelligence correlation: known malicious sender IPs/domains in gateway logs, detection rate against known bad indicators

How to calculate.

• Block rate: (Malicious emails blocked at gateway) ÷ (total malicious emails detected including post-delivery) × 100
• Bypass rate: (Malicious emails reaching inbox) ÷ (total malicious emails detected) × 100

Status	Criteria
Green	Block rate >99% for known threats; bypass rate <0.5%; post-delivery remediation capability active for missed threats
Amber	Block rate 95–98%; bypass rate 0.5–2%; or sandboxing enabled for attachments but not for links
Red	Block rate <95%; or bypass rate >2%; or no visibility into gateway effectiveness (no reporting)

3. BEC impersonation protection coverage

What to measure. Percentage of email communications involving high-risk impersonation scenarios, executive impersonation, finance team impersonation, wire transfer requests, invoice payment instructions, covered by specific BEC detection controls beyond standard phishing detection.

Why it matters. BEC bypasses technical email security because it frequently doesn't contain malware, malicious links, or known-bad indicators. It's a well-written email from a plausible-looking sender asking for a plausible-looking action. Standard gateway controls miss it. BEC-specific controls, display name spoofing detection, lookalike domain detection, behavioral analysis, payment instruction change detection, are a separate control layer.

• Email security platform BEC module (Abnormal Security, Proofpoint Advanced BEC Defense, Microsoft Defender Identity Protection): BEC detection rule coverage and detection events
• Domain spoofing detection: lookalike domain detections, domains similar to yours registered recently and sending email
• Finance team: payment instruction change requests received, how many went through the verification procedure vs. not
• HR records: executive roster for display name impersonation protection configuration

KRI values.

• BEC protection enabled: specific BEC controls active beyond standard filtering (yes/no)
• Executives protected: percentage of C-suite with display name impersonation protection configured
• Finance verification procedure coverage: percentage of vendor payment instruction changes processed through out-of-band verification

Status	Criteria
Green	BEC-specific controls active; all executives in protection scope; finance team has mandatory out-of-band verification for payment instruction changes
Amber	Standard gateway with some BEC features but no dedicated BEC module; or verification procedure inconsistently applied
Red	No BEC-specific controls; or no verification procedure for payment instructions; or executives not specifically protected

4. User reporting rate and threat submission pipeline

What to measure. Rate at which users report suspicious emails using the report phishing button, and what percentage of user-reported emails are analyzed, dispositioned, and closed within a defined SLA; plus how many user reports have led to identification of actual threats that bypassed the gateway.

Why it matters. User reporting is a detection mechanism, users are eyes that see email the gateway has already delivered and missed. A report phishing button that sends emails into a black hole is not a detection control. The reporting-to-analysis pipeline, and the rate at which user reports surface genuine threats, measures whether the reporting ecosystem is operational or performative.

• Email security platform: report phishing button activation count per month; submissions to Microsoft, Google, or gateway vendor
• SOC/email security team: time from user submission to analysis completion; phishing campaign identification from user reports
• Incident management: incidents traced back to user reports as the detection source

How to calculate.

• Report rate: (Users submitting suspicious emails per month) ÷ (total employee population) × 100
• Analysis SLA: (User reports analyzed within defined SLA) ÷ (total user reports) × 100
• True positive rate: (User reports confirmed as genuine threats) ÷ (total user reports) × 100, signals report quality

Status	Criteria
Green	Report rate >5% of population monthly; analysis SLA <1 hour for reports; >10% true positive rate; feedback sent to reporters
Amber	Report rate 1–4%; or analysis SLA 1–8 hours; or no feedback to reporters (reduces future reporting motivation)
Red	Report rate <1%; or no analysis pipeline; or reports going to an unmonitored inbox

5. Email link and attachment sandboxing coverage

What to measure. Percentage of inbound email links and attachments processed through URL rewriting/sandbox detonation analysis before delivery or at click time, and the sandbox detection rate (percentage of sandboxed items identified as malicious vs. passed).

Why it matters. Static analysis catches known malware. Sandboxing catches novel malware and delayed-action links (URLs that are benign at delivery but weaponized at click time). Organizations without sandboxing are accepting the risk that polymorphic malware and staged attack infrastructure bypass their gateway.

• Email gateway configuration: URL rewriting and sandbox detonation settings, enabled for all inbound email vs. selective
• Sandbox platform (Proofpoint TAP, Microsoft Safe Attachments/Safe Links, Mimecast): detonation reports with detection rates
• Link click events: clicks on rewritten URLs, detection at click time vs. at delivery

How to calculate.

• Coverage: (Inbound emails with attachments/links processed through sandbox) ÷ (total inbound emails with attachments/links) × 100
• Detection rate: (Sandboxed items identified as malicious) ÷ (total items sandboxed) × 100, track as monthly trend

Status	Criteria
Green	>99% of inbound attachment/link emails sandboxed; click-time protection active (URL rewriting); sandbox detection contributing to gateway tuning
Amber	Sandboxing active but not on all email volume; or click-time protection only (no delivery-time sandbox)
Red	No sandboxing; or sandbox disabled due to performance concerns without compensating control

6. Outbound email DLP coverage rate

What to measure. Percentage of sensitive data categories (PII, financial data, confidential IP, HIPAA-regulated data) covered by outbound email DLP policies in enforcement mode, blocking outbound transmission of classified content without approved exception.

Why it matters. Inbound email security prevents attacks arriving. Outbound email DLP prevents data leaving. Insider threats, accidental data disclosure to personal email, and social engineering that gets an employee to forward sensitive information are all outbound email risks. Coverage rate measures whether your DLP policy addresses the sensitive data categories most relevant to your regulatory exposure.

• Email DLP platform (Microsoft Purview DLP, Proofpoint Email DLP, Symantec DLP): policy inventory by data category and enforcement mode
• DLP event logs: blocked outbound emails by category; user override requests; policy exemptions
• Data classification: sensitive data categories defined in classification policy vs. data categories covered by outbound DLP

How to calculate. (Sensitive data categories with outbound email DLP policy in enforcement mode) ÷ (total sensitive data categories in classification policy) × 100

Status	Criteria
Green	>90% of sensitive data categories covered in enforcement mode; override requests reviewed by security team; exemption rate <2%
Amber	70–89%; or high-priority categories (PII, financial) in enforcement but others in detection mode
Red	<70%; or DLP universally in detection mode; or no outbound email DLP program

7. Email infrastructure hygiene score

What to measure. The configuration health of your email sending infrastructure, including IP reputation, TLS enforcement on connections, email routing anomalies, and header spoofing detection, as an indicator of whether your email infrastructure is being abused or is at risk of deliverability and reputation damage.

Why it matters. Your IP reputation affects deliverability of legitimate email. An IP range that has been used to send spam, by a compromised system, a poorly controlled marketing platform, or a misconfigured relay, will affect all email sent from that range. Email infrastructure hygiene is both a security signal (compromised systems sending email) and a business continuity signal (legitimate email being blocked by recipient servers).

• IP reputation monitoring (MXToolbox, Talos IP reputation, Barracuda Central): IP reputation status for all sending IP ranges
• Postmaster tools (Google Postmaster Tools, Microsoft SNDS): spam complaint rates and domain reputation from major mailbox providers
• Email routing analysis: DMARC aggregate reports showing unexpected sending sources, mail servers you didn't know were sending on your behalf
• TLS enforcement: percentage of inbound and outbound SMTP connections using TLS (STARTTLS or enforced TLS)

KRI values.

• IP reputation: any sending IP ranges on major blocklists (should be zero)
• Spam complaint rate: Google Postmaster or Microsoft SNDS spam complaint rate (should be <0.1%)
• Unexpected sending sources: unauthorized mail servers identified in DMARC aggregate reports, should trigger immediate investigation

Status	Criteria
Green	No sending IPs on major blocklists; spam complaint rate <0.1%; DMARC aggregate reports reviewed monthly; TLS enforced on outbound
Amber	Known blocklist listing under remediation; complaint rate 0.1–0.3%; or unexpected sending sources in DMARC reports under investigation
Red	Active blocklist listing without remediation; complaint rate >0.3%; or no monitoring of IP reputation or DMARC aggregate data

Deriving these KRIs by source type

From Microsoft Defender for Office 365 (M365)

• Threat protection report: GET /security/secureScores for email-specific factors; M365 Security Center → Email & Collaboration → Reports → Threat Protection Status report, detection by category, delivery actions
• User submissions: Submissions portal → User-reported messages; GET /security/reports/getUserReportedMessages via Graph API
• DMARC/DKIM/SPF status: M365 admin center → Security → Policies → Anti-phishing → Spoof intelligence; shows DMARC enforcement status per domain
• Safe Links/Safe Attachments: Defender for Office 365 → Policies → Safe Links (URL rewriting coverage) and Safe Attachments (sandbox coverage), verify enabled for all transport rules

From Proofpoint / Mimecast

• Proofpoint TAP (Targeted Attack Protection): API: GET /v2/siem/clicks/permitted and GET /v2/siem/clicks/blocked, click-time threat detection metrics
• Mimecast API: POST /api/audit/get-audit-events filtered by auditType: email_rejection or email_delivery, gateway decision log for effectiveness calculation
• DMARC monitoring (Proofpoint Email Fraud Defense): Domain policy status, spoofing attempt volume, unauthorized sender sources

From DMARC Monitoring Platforms (Dmarcian, Valimail)

• Policy enforcement status API: Per-domain DMARC policy and enforcement status; percentage of email volume in compliance
• Aggregate (RUA) reports: Unauthorized sending sources for your domains, each unauthorized source warrants investigation
• Forensic (RUF) reports: Failed authentication details, message header, sending IP, recipient; high-fidelity BEC indicator when from look-alike domains

From Google Postmaster Tools / Microsoft SNDS

• Domain reputation: https://postmaster.google.com, domain reputation (High/Medium/Low/Bad) and spam rate for your sending domain
• Microsoft SNDS: https://sendersupport.olc.protection.outlook.com/snds/, complaint rate and trap hit rate for sending IP ranges
• Trend data: Both tools provide historical data, track complaint rate trend over time; spikes signal compromised sending infrastructure or poor list hygiene