Key takeaways
- Identity drives detection: M365 mailbox compromise usually starts with valid credentials, making identity and behavior the primary detection focus.
- Watch key compromise signals: Atypical sign-ins, OAuth abuse, mailbox rules, eDiscovery role grants, and mailbox exports can indicate account takeover.
- Reduce false positives: Correlate signals, baseline user behavior, and validate context before escalating alerts.
- Standardize multi-tenant monitoring: Centralized alerts, per-tenant baselines, and automated triage help MSPs scale detection efficiently.
A compromised Microsoft 365 mailbox is rarely just a mailbox problem. An attacker who gets into a single Microsoft 365 (M365) account can read a client’s email, study how the business communicates, and send invoice fraud from a trusted internal address. The same credentials often give access to shared files, other users, and connected apps.
That access is exactly what attackers are buying and phishing their way toward. Identity-based attacks rose 32% in the first half of 2025, according to the Microsoft Digital Defense Report 2025, and a mailbox is where that access turns into money, because it holds the invoices, conversations, and relationships that make a fraudulent request look routine.
For the MSP managing that client, the challenge is to detect the takeover before it becomes a business-impacting incident. That challenge becomes more difficult if the MSP has to do this across a portfolio.
Spotting a compromised mailbox within a single tenant is manageable. Watching for the same patterns across 50 or more client tenants, each with its own users and its own definition of normal, is a different operational problem.
This article covers two things: the signals that reveal a compromised M365 mailbox, and how to detect them at scale without generating an unmanageable volume of alerts.
Why M365 Mailbox Compromise Is an Identity Problem
Mailbox compromise usually starts with a valid login. An attacker who has phished a password, stolen a session token, or bought credentials from a criminal marketplace signs in the same way the real user does. There’s no malicious file for an endpoint agent to catch and no exploit to patch. The account works exactly as designed, which is what makes this class of attack hard to notice.
The same Microsoft data shows how ordinary most of these attacks look from the inside. More than 97% of identity attacks are password spray or brute force attempts, which means the typical M365 compromise starts with a password that works rather than with a technique an endpoint stack would recognize.
That’s why detection has to center on identity and behavior rather than on files or perimeters. In a way, identity serves as the new perimeter for M365 clients, and the key question is whether a given session aligns with how a specific user actually behaves.
A login from a new country, a consent grant to an unfamiliar app, or a new rule that forwards mail to an external address means little in isolation. Read together against a known baseline, those same events may indicate an account takeover (ATO) in progress.
For an MSP, this focus changes what you monitor. Endpoint and email filtering are still important, but neither reliably catches an attacker who logged in with a real password and did nothing a normal user couldn’t do. The evidence lives in sign-in logs, audit logs, and mailbox configuration, so those are the areas where cross-tenant detection should focus.
Each tenant sets its own baseline. A sales team that travels weekly produces sign-in patterns that would look alarming for a back-office client that logs in from one city. Detection that has to work across a portfolio has to account for that variation instead of applying one fixed rule to every client.
The Signals That Reveal a Compromised Mailbox
Most M365 mailbox compromises manifest as a small set of recognizable signals. None of them confirms an incident on its own, but each one gives you a place to look. The key is knowing which activity to pull from M365’s audit and sign-in logs and how to interpret it. The table below outlines the key signals worth inspecting.
| Signal | What It Looks Like in M365 | Why It Signals Compromise |
|---|---|---|
| Impossible travel and atypical sign-ins | Sign-ins from two distant locations within a span too short to physically travel, or logins from countries and IP ranges a user has never used | Suggests a second party is using valid credentials from their own location, often alongside the legitimate user |
| OAuth app consent abuse | A user grants permissions to an unfamiliar third-party app, sometimes with broad mailbox or file access | Attackers use consent grants to keep access to mail and data even after a password reset |
| Malicious inbox and forwarding rules | New rules that auto-forward mail externally, move messages to obscure folders, or delete specific incoming replies | Hides attacker activity from the user and quietly exfiltrates email, a common step in business email compromise (BEC) |
| eDiscovery role grants and content searches | An account is added to the eDiscovery Manager or Compliance role group, then runs content searches across the tenant | The role grant is the rare event, since legitimate users already hold it. A new assignment followed by a search points to an attacker hunting for finance records or credential material |
| Mass mailbox export or high-volume sending | A sudden spike in messages sent, or bulk export of mailbox contents | Points to data exfiltration, or the mailbox being used to launch internal phishing |
These signals often appear in sequence. A takeover might begin with an atypical sign-in, followed by a forwarding rule that hides replies, then a quiet eDiscovery role grant and a search for finance records, and finally outbound invoice fraud from the compromised address. Catching any single step is useful. Catching the chain early, before the outbound stage, can limit damage to the client and prevent a single compromised account from becoming a tenant-wide incident.
Separating Real Detections From Noise
Each of those signals can produce false positives. A traveling executive trips impossible-travel logic. A finance manager may legitimately approve Microsoft 365 access for a new reporting or accounting app. Left untuned, these detections hide the real incidents within routine activity, and alert fatigue sets in fast when you multiply that noise across dozens of tenants.
The priority at the signal level is to improve detection fidelity before a signal reaches a human. That means tuning each signal so it fires on genuine deviation, not on ordinary business activity. A few practices help:
- Correlate before you escalate. A single weak signal rarely justifies an alert. Two or more in the same session, such as an atypical sign-in followed by a new forwarding rule, deserve immediate attention.
- Baseline each user’s normal. Track the locations, devices, and sign-in times a user actually uses, so deviations stand out.
- Validate impossible travel against context. Check flagged logins against known VPN egress points and corporate travel before treating them as malicious.
- Compare OAuth grants to an app allowlist. Consent to a sanctioned app is expected. Consent to an unfamiliar app requesting mailbox access should trigger review.
- Treat mail-rule changes as high fidelity. External forwarding and delete-on-receipt rules have few valid explanations and warrant a quick review.
- Alert on eDiscovery role grants, not just searches. Searches are routine for a compliance team. The rare event is an account being newly added to the eDiscovery Manager or Compliance role group, so treat that grant as the trigger and the search that follows as confirmation.
Scaling Detection Across 50+ Tenants Without 50× the Alerts
If each client generates even a handful of daily identity alerts, a portfolio of 50 produces a queue no small team can review manually. Moreover, headcount rarely scales in step with a growing client list. One solution is to change how signals are collected, ranked, and triaged rather than to add reviewers. The table below outlines approaches that hold up across a large tenant base.
| Approach | How It Works Across Tenants | What It Solves |
|---|---|---|
| Centralized signal aggregation | Identity and mailbox signals from every tenant feed into one console instead of separate admin portals | Removes the need to log into each tenant to check for activity |
| Per-tenant baselining | Behavioral benchmarks are built and stored for each client’s users | Keeps one client’s normal from being judged by another client’s patterns |
| Risk-based alert prioritization | Signals are scored by severity and confidence, and the queue surfaces the highest-risk items first | Directs limited analyst time to the incidents most likely to be real |
| Automated triage and noise reduction | Correlation and enrichment run before a human sees an alert, filtering benign activity out | Cuts the raw alert volume that comes with managing many tenants |
| Cross-tenant correlation | Repeated patterns, such as the same malicious app or IP address across clients, are linked together | Reveals coordinated campaigns targeting several of your clients at once |
At scale, mailbox detection becomes an economic problem. An analyst who can comfortably review 30 alerts a day hits a bottleneck at 300, and hiring your way out erodes the margin that makes managed security worth offering.
Each approach above works by lowering the number of alerts a person has to investigate, either by filtering them earlier or by ordering them so the important ones come first. Together, they let one team cover a growing client base without a matching rise in headcount.
A Repeatable Multi-Tenant Detection Workflow
Consistency turns those approaches into daily practice. When every client is onboarded and monitored the same way, tuning stays predictable, and you don’t have to reset your baseline for each new client. It also makes the work transferable. Any technician on your team can pick up an incident without relearning a client’s quirks. Scalable workflows tend to have the following traits:
- Baseline at onboarding. Capture each tenant’s identity and sign-in patterns when you bring the client on, so detection has a reference point from day one.
- Standardize severity tiers. Define what critical, high, and low mean once, and apply the same tiers to every client so triage decisions stay consistent.
- Suppress known benign patterns per tenant. Record the legitimate exceptions for each client, such as a regular overseas office, so they stop generating alerts.
- Route validated signals to one queue. Send confirmed, high-severity detections from all tenants into a single review workflow rather than scattered portals.
- Keep exception lists tenant-specific. Make sure a suppression set for one client doesn’t silence the same signal for another, which would create blind spots.
- Document escalation and notification paths. Decide in advance who acts, and how each client is informed, so response doesn’t stall during a live incident.
None of this requires a large team. It requires the same steps applied the same way to every client, so that adding a tenant extends an existing system instead of starting a new one.
Where Guardz Fits
The approaches above describe what multi-tenant M365 detection requires. Guardz builds them into a single platform, layered so prevention, identity detection, and expert response draw on the same signals.
Prevent. Email security sits upstream. Powered by Check Point Harmony and embedded in the platform, it blocks much of the phishing, BEC, and impersonation that leads to ATO, and surfaces email-side compromise signals such as suspicious mailbox rules.
Detect. Guardz ITDR (Identity Threat Detection and Response) covers the identity layer. It monitors user behavior across M365 tenants, benchmarks each user against their own baseline, and correlates the signals this article covers, including impossible travel, MFA status, credential and token abuse, and mailbox rule changes, connecting related findings into one incident mapped to the affected user. Agentic AI handles triage, enriching and benchmarking activity before an alert reaches a person, which keeps a 50-tenant queue reviewable. Because these controls are native to one platform, a signal that starts in email and moves to identity is linked automatically, and signals from every tenant land in the same console.
Respond. When a takeover is confirmed, containment has to match the way attackers hold on. From the same console, an admin can revoke the account’s active sessions and refresh tokens, revoke OAuth consent granted to suspicious third-party apps, remove attacker-created mailbox rules, and suspend the account. The order of operations is the point: suspending or resetting the password alone leaves token and consent-based access intact, and that is the persistence path most mailbox takeovers depend on.
Guardz MDR (Managed Detection and Response) carries that response layer for the MSPs that want it: a 24/7 team of SOC analysts and threat hunters who investigate validated incidents, guide response through playbooks for ATO and BEC, and stay in contact with the MSP throughout. The MSP keeps control while extending its capacity to watch every client tenant at once.
