Microsoft 365 E3’s new email baseline still leaves tuning gaps

At a glance

What this is: Microsoft’s E3 email security uplift raises the default baseline, but the article’s core finding is that many tenants will still need tuning to turn licensing into real protection.

Why it matters: IAM and security teams should treat bundled controls as a starting point, because detection coverage, user reporting, and quarantine handling still determine whether attacks are actually blocked.

Context

Microsoft 365 E3 is now shipping a stronger email security baseline, but the operational gap remains between owning a control and using it effectively. In practice, email security fails when defaults stay permissive, reporting is weak, or users cannot tell what the platform is actually doing.

The identity angle is real because phishing and impersonation attacks increasingly target executives, finance staff, and help desk workflows to steal trust, not just credentials. For IAM, PAM, and human-risk programmes, the question is whether inbox controls, reporting paths, and account takeover defences are aligned with the way attackers abuse identity in Microsoft 365.

This is a governance problem as much as a technical one: a licensed feature can still leave the organisation exposed if ownership, tuning, and measurement are unclear.

Key questions

Q: What breaks when email security defaults stay permissive after a Microsoft 365 E3 upgrade?

A: The main failure is that licensing creates a false sense of coverage while the actual enforcement remains weak. If impersonation checks, quarantine handling, and reporting paths are not tuned, attackers still get through with familiar phishing and BEC patterns, and the organisation discovers too late that the new baseline was never the same as an effective control state.

Q: Why do phishing and impersonation attacks still succeed when Safe Links and Safe Attachments are enabled?

A: Because those controls inspect specific attack surfaces, not the full social-engineering chain. Safe Links checks URLs at click time, Safe Attachments detonates files, but impersonation, trust abuse, QR-code lures, and user behaviour can still bypass that layer. The result is residual risk that only shows up when the controls are configured, monitored, and paired with identity-aware policy.

Q: What are the signs that phishing controls are failing in the browser rather than in the email gateway?

A: A common sign is when suspicious messages are blocked but users still reach realistic-looking login pages and enter credentials. Another signal is when campaigns keep working after a site is already known, because deny-lists update too slowly. If attackers are using CAPTCHA, fake overlays, or cloned interfaces to bypass user judgment, browser-layer controls are not keeping pace.

Q: Should security teams rely on native Microsoft controls or add a separate phishing layer?

A: That decision depends on whether the native stack covers the organisation’s real attack patterns and operational needs. If the team needs deeper impersonation analysis, stronger post-delivery inspection, role-based simulation, or faster response workflows, a separate layer may be justified. The key is to compare actual control depth, not licence convenience.

Technical breakdown

Why bundled email security still needs tuning

Bundled security features often arrive with permissive defaults so they do not overwhelm tenants with false positives. That design choice reduces noise, but it also means impersonation detection, attachment detonation, and URL analysis may not meaningfully change risk until the tenant configures policy, reporting, and review workflows. The mechanism matters: detection is only useful if the alerting and enforcement layer is aligned to the organisation’s threat profile. In email security, the control plane is often less important than the operating model around it.

Practical implication: Treat bundled security as an enablement baseline, not as a finished control state.

Safe Links, Safe Attachments and anti-phishing are different controls

Safe Links checks a URL at click time, Safe Attachments detonates files in a sandbox, and anti-phishing rules target impersonation and trust abuse. These are complementary but not interchangeable. Safe Links cannot see QR codes, Safe Attachments cannot stop every archive or hosted payload, and anti-phishing logic still depends on policy quality and identity-context tuning. A tenant that conflates these functions will overestimate coverage and miss the attack paths each feature was designed to catch.

Practical implication: Map each control to the attack type it addresses and avoid assuming one email feature covers the whole phishing problem.

Why inbox security now intersects with identity governance

Email attacks increasingly target identity boundaries rather than only malware delivery. Executive impersonation, finance fraud, and account takeover attempts exploit trust relationships, mailbox access, and user behaviour. That makes email security part of human identity governance, not just message filtering. The practical boundary is whether the organisation can detect suspicious sender patterns, protect high-value identities, and route reports into an investigation process quickly enough to matter. In that sense, email security is an access and trust problem as much as a content problem.

Practical implication: Align mail controls with identity risk tiers for executives, finance teams, and high-privilege users.

Threat narrative

Attacker objective: The attacker wants to convert email trust into credential theft, payment fraud, or convincing impersonation at scale.

1. Entry begins with phishing emails that mimic trusted people or services and land in the inbox with enough credibility to earn a click or reply.
2. Credential or account abuse follows when the recipient is tricked into surrendering access, approving a prompt, or trusting a malicious link or attachment.
3. Impact is achieved through impersonation, mailbox takeover, or payment redirection, which turns email trust into business compromise.

Breaches seen in the wild

• Solana web3.js npm compromise 2024: A phished maintainer's npm access let attackers publish two @solana/web3.js versions that stole private keys from bots and apps.
• EmeraldWhale Git config credential theft: Tokens in exposed .git/config files let EMERALDWHALE clone private repositories and steal more than 15,000 cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Email security baselines are only meaningful when they are operationalised. Licensing changes can improve the floor, but they do not close the gap between feature availability and real-world enforcement. In Microsoft 365, that gap is where permissive defaults, inconsistent reporting, and weak quarantine processes leave organisations exposed. Practitioners should treat bundled controls as a governance problem, not a procurement event.

Phishing defence is now an identity governance issue, not just a mail gateway issue. The article is right to focus on impersonation, executive targeting, and mailbox trust because those are identity abuse patterns in disguise. The boundary between email filtering and IAM has collapsed in practice, especially where finance, help desk, and privileged users are targeted. Security teams should align mail controls with identity-critical roles and escalation paths.

Attackers exploit the difference between detection and response. A platform can flag links, sandbox files, and still leave analysts with too much manual triage or users with too much freedom to mishandle suspicious mail. That creates a detection-response latency problem, where the right alert arrives after the business decision has already been made. Practitioners should assume the first failure is often process, not technology.

Repeated scanning and human-in-the-loop analysis matter because email threats mutate after delivery. The article’s emphasis on time-of-click checks and post-delivery rescanning reflects a broader truth about modern phishing and BEC. A message that looks benign at delivery can become malicious later, and a static verdict can age badly. Teams should build for re-evaluation, not one-time inspection.

What this signals

Email-security uplift should be treated as a governance reset, not a clean win. The change improves the minimum baseline, but the reader’s programme still needs ownership for policy tuning, quarantine handling, and identity-targeted protection. The practical question is whether mail controls are monitored as part of security operations or left as inherited settings after the licence change.

Identity-critical users need differentiated mail policy. Executives, finance staff, and help desk personnel are not just higher-value mail users, they are higher-value trust targets. That means phishing policy, reporting paths, and investigation prioritisation should be role-aware rather than uniform across the tenant.

For practitioners

• Turn on impersonation and domain protection Enable user impersonation protection for high-value people such as executives and finance staff, and add domain impersonation coverage where trust abuse is most likely.
• Validate quarantine and reporting workflows Make quarantine visible, decide who can preview or release mail, and enable one-click phishing reporting so suspicious messages get routed into review quickly.
• Tune Safe Links and Safe Attachments separately Configure Safe Links for click-time inspection and Safe Attachments for sandbox detonation, then test how each behaves against archives, hosted payloads, and QR-code lures.
• Measure what still reaches the inbox Track blocked mail, quarantined categories, and user-reported phishing over a 30-day window, then compare that trend with the volume of suspicious mail still delivered.
• Prioritise identity-critical mailboxes Create stricter policy for executives, finance users, and help desk accounts because those identities are disproportionately targeted for impersonation and social engineering.

Key takeaways

• Microsoft’s bundled email controls raise the floor, but tenants still have to configure them before they materially reduce phishing risk.
• The biggest remaining exposure is not feature absence but feature underuse, especially around impersonation, quarantine, and reporting.
• Identity-aware email policy is becoming a prerequisite for defending executives, finance teams, and other high-trust users.

Key terms

• Impersonation Protect: A mail security control designed to identify display-name and domain impersonation by evaluating multiple conditions in a message before taking action. Its effectiveness depends on tuning, thresholding, and active enforcement. If it only tags mail as external, it may not stop fraud-oriented messages from reaching users.
• Safe Links: Safe Links is a Microsoft email protection mechanism that rewrites or checks URLs before users open them. It helps determine whether a clicked link passed through a protected redirect and can be used in investigations to distinguish a direct malicious URL from a protected email link. Analysts use it as context, not as proof of safety.
• Safe Attachments: Safe Attachments detonates email files in a sandbox before delivery or while preserving user experience through delayed content release. It is designed to catch malicious attachments, but it remains only one layer and does not replace broader phishing and identity controls.
• Email Security Baseline: An email security baseline is the minimum set of controls a tenant receives by default or through licensing. It is only effective when settings are tuned, roles are assigned, and the organisation measures whether attacks still reach the inbox.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, human identity, and secrets management. It helps security teams connect identity control design to the operational realities of modern attack paths.