Email Security Maturity Model: Five Levels

Most organisations own an email filter and have published an SPF record, yet still cannot say whether their domains can be spoofed, how quickly a reported phish is removed from every mailbox, or whether a fake supplier invoice would be paid. This model uses NHI Mgmt Group's five levels (Ad hoc, Developing, Defined, Managed and Optimised) to score an email security programme across six capability areas: sender authentication, inbound filtering, transport security, user reporting and response, business email compromise (BEC) and payment controls, and the identities behind mailboxes and sending services. Each level has evidence tests, so a score can be defended to an auditor or a board. It is for email and messaging owners, security architects, CISOs and auditors. For how each control works, read the Email Security Guide; this page tells you how far along you are and what to do next.

Key takeaways

Score each area separately: an organisation can be at Level 4 for filtering and Level 1 for payment verification, and the weakest area is where losses happen.
DMARC at p=none is Level 2: monitoring mode tells receivers nothing about how to handle spoofed mail; Defined needs enforcement on the main sending domains and protection for domains that never send.
Reporting speed beats click rate: NCSC guidance puts a simple reporting route with feedback, and no blame, at the centre of phishing defence; higher levels measure how fast a report becomes tenant-wide removal.
BEC is a process problem as much as a filter problem: out-of-band verification of payment and bank detail changes is a Level 3 requirement, whatever the filter does.
Mailbox and sending identities count: phishing-resistant MFA for users, and scoped, rotated keys for every service that can send as your domain, are part of email maturity.

The five levels

Level	Name	What it looks like
1	Ad hoc	Default platform filtering, no owner for email security, SPF possibly present but unmaintained, no DMARC or DMARC with no reports read. Users forward suspicious mail to the service desk. Payment changes are accepted by email.
2	Developing	A named owner, SPF and DKIM for the main domain, DMARC at p=none with aggregate reports collected, a report button deployed, awareness training with phishing simulations. Filtering uses defaults with some custom rules. Response is manual, one mailbox at a time.
3	Defined	Written email security standard. DMARC at quarantine or reject on all sending domains, non-sending domains locked down, every third-party sender inventoried and aligned. Strict filtering for high-risk groups, impersonation protection for executives and finance, enforced TLS where supported. User reports feed a triage queue with feedback to the reporter. Payment and bank detail changes verified by a second, known channel. Phishing-resistant MFA rolled out to administrators and finance.
4	Managed	Metrics reported monthly: DMARC pass rate, spoofing volume, time from first report to tenant-wide removal, user report rate. Post-delivery removal automated for high-confidence verdicts. MTA-STS enforced with TLS-RPT monitored. Mailbox rule, OAuth consent and anomalous sign-in alerts tuned and triaged. Sending service keys inventoried, scoped and rotated.
5	Optimised	User reports and detections feed back into filtering and awareness content within days. Look-alike domain monitoring, supplier email risk and BEC scenarios are exercised with finance. Controls are tested by adversary simulation, and the programme adapts to new lures such as AI-generated text and voice, and to new sending channels such as AI agents with mailbox access.

Capability areas

Use this table to score each area. A level is reached only when every statement for that level is true for all domains and users in scope, not a pilot.

Area	Level 1 Ad hoc	Level 3 Defined	Level 5 Optimised
Sender authentication (SPF, DKIM, DMARC)	SPF only, or records copied from a vendor; DMARC absent	All sending domains at p=quarantine or p=reject with aggregate reports reviewed; non-sending and parked domains protected; every third-party sender aligned	Strict alignment where possible, new senders onboarded through a documented process, look-alike domains monitored and taken down
Inbound filtering and post-delivery removal	Platform defaults, allow lists added on request	Strict policies for executives, finance and administrators; attachment type blocking; link and attachment detonation; allow lists reviewed	Automated tenant-wide removal on high-confidence verdicts; detection rules tuned from incidents and user reports
Transport security	Opportunistic TLS only, unmonitored	Enforced TLS for named partners; MTA-STS published in testing mode with TLS-RPT	MTA-STS enforced, TLS-RPT failures triaged, partner TLS posture reviewed
User reporting and response	Forward to the service desk; no feedback	One-click report button; every report acknowledged; triage queue owned by the SOC; no-blame statement	Reports cluster automatically and drive removal in minutes; reporters told the outcome; report data feeds awareness content
BEC and payment controls	Bank detail changes accepted by email	Out-of-band verification for new payees and changes; dual approval above a threshold; finance-specific training	BEC scenarios exercised with finance and suppliers; supplier account compromise indicators monitored; losses tracked against near misses
Mailbox and sending identities	Passwords with optional MFA; shared mailboxes with no owner; sending keys unknown	Phishing-resistant MFA for administrators and finance; legacy authentication disabled; OAuth consent restricted; every service that sends as the domain inventoried with an owner	Phishing-resistant MFA for all; sending credentials short-lived or scoped and rotated; alerts on new forwarding rules and mail permission grants

Evidence for each level

Level	Acceptable evidence	Not sufficient on its own
2 Developing	Published SPF, DKIM and DMARC records; aggregate reports arriving; report button deployment figures	A licence for an email security product
3 Defined	DMARC policy of quarantine or reject on each sending domain; inventory of third-party senders with alignment status; finance procedure for verifying payment changes; filtering policy assignment by group	A DMARC record at p=none, however long it has been in place
4 Managed	Monthly metrics pack; logs showing automated removal; MTA-STS policy in enforce mode; alert triage records for inbox rules and OAuth consents	Vendor dashboard screenshots without trend data
5 Optimised	Examples of reports that triggered containment; exercise reports with finance; changes to filtering made in response to new lures	Industry awards or benchmark positions

Why DMARC enforcement marks the Level 3 line

DMARC is now a Standards Track protocol: RFC 9989 (May 2026) obsoletes RFC 7489, removes the old pct tag and adds np for non-existent subdomains and t for test mode. A policy of p=none is monitoring mode and expresses no handling preference to receivers, so spoofed mail is treated as if no policy existed. The UK NCSC advises starting at p=none with reporting, fixing legitimate senders and then moving to quarantine and reject, and protecting every domain, including those that never send email, with v=spf1 -all, a reject DMARC policy and a null MX record. Since February 2024, Google and Yahoo have required bulk senders to publish at least p=none with SPF and DKIM, and Microsoft applied similar rules to Outlook.com high-volume senders from 5 May 2025. Those rules raise the floor to Level 2; they do not make a domain unspoofable. See the DMARC, SPF and DKIM Guide and the DMARCbis Changes Guide.

The NCSC layers as a maturity lens

NCSC phishing guidance sets out four layers: make it hard for attackers to reach users (anti-spoofing, filtering, limiting what staff reveal), help users identify and report (training focused on higher-risk roles, verifying sensitive requests by a second channel, a blame-free reporting culture), limit the impact of a successful phish (patched devices, no admin accounts for email, web blocking, MFA, reviewed privileged access) and respond quickly (logging, monitoring and a practised response plan). An organisation investing only in layer one tends to stall at Level 2 in every area except filtering. The model above spreads maturity across all four layers on purpose.

Self-assessment questions

Answer for the whole estate. Any "no" at a level means the area scores at the level below.

Domains: can you list every domain you own, which ones send email, and the DMARC policy of each? Are parked domains protected with a reject policy and null MX?
Senders: do you know every third party that sends as your domain (marketing, ticketing, HR, billing), and does each pass DKIM aligned with your From: domain?
Reports: who reads DMARC aggregate reports, how often, and when did they last result in a change?
Filtering: do executives, finance and administrators get stricter policies than everyone else? Platform presets help here: in Microsoft Defender for Office 365, for example, the Strict preset quarantines spam, spoofed and impersonation mail that the Standard preset moves to junk, and Strict takes precedence when a user is in both.
Allow lists: how many allow entries and filter bypass rules exist, who approved each, and when were they last reviewed?
Removal: when one user reports a phish, how long until the same message is removed from every mailbox, and is that time measured?
Culture: would a user who clicked a link report it straight away, and do reporters hear the outcome?
Payments: would a request to change a supplier's bank details, arriving from that supplier's genuine but compromised mailbox, be verified by a phone call to a number already on file?
Accounts: is legacy authentication disabled, is phishing-resistant MFA in place for administrators and finance, and can users grant mail permissions to third-party apps without review?
Sending credentials: do you know every API key or service account that can send email as your domain, who owns it and when it was last rotated? In the TruffleNet campaign, stolen AWS keys were checked for email sending quota, and in a compromised AWS account that Fortinet could not tie directly to TruffleNet, a user with Amazon SES permissions was used to send a fake supplier invoice.

Moving up: roadmap

From Ad hoc to Developing

Name an owner and build the domain inventory, including registrations held by marketing and subsidiaries.
Publish SPF (within the ten DNS lookup limit in RFC 7208), enable DKIM with 2048-bit keys for each sending platform, and publish DMARC at p=none with a rua address.
Deploy a report button and route reports to one monitored queue.
Turn on the platform's recommended baseline policies rather than leaving defaults untouched.

From Developing to Defined

Use aggregate reports to find and align every legitimate sender, then move to quarantine and to reject. See the Email Authentication Checklist.
Lock down non-sending and parked domains.
Apply strict filtering and impersonation protection to executives, finance and administrators; review and prune allow lists.
Write the finance verification procedure for new payees and bank detail changes, with dual approval above a threshold. See the Business Email Compromise Awareness for Finance Teams Guide.
Deploy phishing-resistant MFA for administrators and finance, disable legacy authentication and restrict user consent to apps. See the Phishing-Resistant MFA Guide.
Publish MTA-STS in testing mode with TLS-RPT.

From Defined to Managed

Agree the metric set below and report it monthly.
Automate post-delivery removal for high-confidence verdicts and user-report clusters; keep a human decision for low-confidence cases.
Enforce MTA-STS after a clean monitoring period.
Tune detections for new inbox forwarding rules, mail permission consents and sign-ins after a reported phish, and write the response runbook. See the Phishing Incident Response Playbook.
Inventory sending API keys and service accounts, give each an owner, scope it to the domains it needs and rotate it on a schedule. See the Email Delivery API Keys Security Guide.

From Managed to Optimised

Feed report and incident data back into filtering rules and awareness content each month.
Exercise BEC scenarios with finance and key suppliers, including a compromised supplier mailbox and a voice follow-up.
Monitor look-alike domain registrations and act on them.
Extend controls to new senders and readers of mail, including AI agents with mailbox access. See the AI Agent Email Access Security Guide.

Metrics that show progress

Metric	What it shows	Level where it becomes expected
Share of sending domains at p=quarantine or p=reject	Anti-spoofing coverage	3
DMARC pass rate for legitimate mail, by source	Sender alignment quality	3
Median time from first user report to tenant-wide removal	Response speed	4
User report rate on simulations and real phish	Reporting culture	4
Allow list entries older than 12 months	Filter bypass hygiene	4
Payment change requests verified out of band, and near misses	BEC control in practice	4

Common failure patterns

Parking at p=none: monitoring mode stays in place for years because one unaligned sender was never fixed.
Forgotten domains: marketing and regional domains, and parked domains, remain spoofable while the main domain is at reject.
Allow lists that become bypasses: entries added for a supplier or simulation vendor are never removed and later carry malicious mail.
Training without a reporting route: click rates fall but nobody reports, so real lures go unnoticed until losses appear.
Trusting a genuine mailbox: a compromised supplier account passes every authentication check; only out-of-band verification stops the payment.
Ignoring sending keys: API keys for email delivery services sit in code and configuration with full domain sending rights and no owner.

Framework mapping

Capability area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1	MITRE ATT&CK
Sender authentication	PR.DS-02	SC-8	9.5 Implement DMARC	T1566 Phishing
Inbound filtering	DE.CM-09	SI-8 Spam Protection	9.6 Block Unnecessary File Types, 9.7 Deploy and Maintain Email Server Anti-Malware Protections	T1566.002 Spearphishing Link
User reporting and response	PR.AT-01, RS.MA-02	AT-2	14 Security Awareness and Skills Training	T1534 Internal Spearphishing
Mailbox and sending identities	PR.AA-03, PR.AA-05	IA-5, AC-6	6 Access Control Management	T1114.003 Email Forwarding Rule, T1078 Valid Accounts

Practitioner checklist

Score all six areas separately and keep the evidence behind each score.
Inventory every owned domain and its DMARC policy; protect non-sending domains.
List every third-party sender and service key that can send as your domains, with an owner.
Apply stricter filtering to executives, finance and administrators and review allow lists quarterly.
Measure time from first report to tenant-wide removal, and report it monthly.
Require out-of-band verification for new payees and bank detail changes.
Roll out phishing-resistant MFA, starting with administrators and finance.
Set a target level per area for the next 12 months and reassess annually.

Email Security Maturity Model: Score Authentication, Filtering, Reporting and BEC Controls