Purview Audit (Standard) now logs MailItemsAccessed for mailbox forensics

Over the last several months it has become obvious that detailed audit trails in Microsoft 365 are no longer optional. In many of the tenants I work with, mailbox investigation moved up the agenda after the Storm-0558 incident in summer 2023, when attackers used stolen signing keys to get into Exchange Online mailboxes. Customers kept asking me whether they could actually see who had opened which emails, and when. That is exactly what the Purview Audit MailItemsAccessed event answers. Since autumn 2023 it has been available in Audit (Standard), and that has made a real difference to security investigations.

Microsoft opened up Purview Audit after Storm-0558

In July 2023, Microsoft announced that several important security-related audit events, MailItemsAccessed among them, would no longer be reserved for Audit (Premium) customers. The rollout started in September, and by now every tenant with active Audit (Standard) should see these events. In practice you can track which mailbox items were accessed, including access through OAuth apps or other automated means, without paying for a Premium license. That helps a lot when you investigate compromised mailboxes, threat actors or suspicious consented apps, like the ones I described in my Midnight Blizzard lessons post. Microsoft also doubled the default retention for Audit (Standard) from 90 to 180 days, so you have more room when you need to look back at older incidents.

MailItemsAccessed records every read and needs mailbox auditing turned on

The MailItemsAccessed event is written whenever a user or app reads an email object in an Exchange Online mailbox, no matter if that happens through Outlook, OWA, EWS, Microsoft Graph or an OAuth app. It separates soft-deleted, hard-deleted and standard read operations. Both interactive user access and automated access by apps or service principals are covered. There is one prerequisite you should check: mailbox auditing has to be enabled. New tenants have it on by default, but in older environments I would verify it. Microsoft's official docs cover the details.

Practical tip: I regularly check mailbox audit status with this PowerShell command:

Get-Mailbox -ResultSize Unlimited | Where-Object { $_.AuditEnabled -ne $true }

Most new tenants already have AuditEnabled set to true, but legacy accounts sometimes slip through.

The audit log can be searched in the portal, with PowerShell or from a SIEM

The quickest way to find MailItemsAccessed events is the Purview portal under "Audit." When I need more detail, for example access by specific service principals or OAuth apps, I switch to Search-UnifiedAuditLog in PowerShell. This query returns all MailItemsAccessed events for one user in February:

Search-UnifiedAuditLog -StartDate "2024-02-01" -EndDate "2024-02-29" -Operations MailItemsAccessed -UserIds [email protected]

Microsoft's documentation has the full guidance. You can export the results to CSV or stream them into a SIEM such as Microsoft Sentinel, which you'll want for continuous monitoring or automated alerting. Sentinel connects through a dedicated data connector, and other SIEMs can pull the logs through the Office 365 API.

Longer retention still requires Audit (Premium)

Audit (Standard) now gives you 180 days of lookback, which is a lot more than before. If you need longer retention (up to 10 years) or granular retention policies, you still need Audit (Premium). With it you can decide which events to keep for specific accounts or groups, and organizations with compliance mandates often depend on that. The docs explain how to configure these policies.

Before you start a forensic review, check whether the audit log actually covers the timeframe you need. I've seen cases where the important access events were simply too old to retrieve. With the 180-day window, though, most organizations are better off than they were a year ago.

The audit events flow from the mailbox to the analyst

To show how the pieces fit together, I put together a simple diagram of the path from mailbox to audit log, SIEM and analyst:

flowchart TD
  User["User or App"] --> Mailbox["Exchange Online Mailbox"]
  Mailbox --> Event["MailItemsAccessed Event"]
  Event --> AuditLog["Purview Audit Log"]
  AuditLog --> Portal["Purview Portal / PowerShell"]
  AuditLog --> SIEM["SIEM (e.g. Sentinel)"]
  SIEM --> Analyst["Security Analyst"]

Figure: How MailItemsAccessed events travel from the mailbox to analysis in the SIEM.

I now treat MailItemsAccessed as a baseline for cloud defense

Since Storm-0558 and the extension of MailItemsAccessed auditing to all Microsoft 365 customers, the basis for proper mailbox forensics in Exchange Online is much better than it used to be. The 180-day standard retention covers most investigations, even if it won't always satisfy strict regulatory requirements. What matters most is that auditing is really enabled everywhere and that you review it regularly, ideally together with other controls like Conditional Access (see my Conditional Access getting started post). For me, MailItemsAccessed has become a core data source that anyone who takes Microsoft cloud security seriously should have in place.