MailItemsAccessed: What It Proves (and What It Doesn't)

TL;DR. MailItemsAccessed is the audit record that answers "what did the attacker read?". Bind records list individual messages by InternetMessageId (aggregated per two minutes, count in OperationCount); Sync records mean an Outlook desktop client downloaded a whole folder, which you must treat as fully exposed. Separate the attacker's access from the user's by IP, ClientInfoString, AppId and SessionId. Check IsThrottled: after too many records the mailbox stops logging. It shows access, not a human reading.

After containment, the question that drives notification duties is always the same: which messages did they see? Microsoft's own guidance is to assume more mail was compromised than the attacker's visible presence suggests, and to use MailItemsAccessed to narrow it down (Microsoft Learn).

Availability

Microsoft documents MailItemsAccessed as part of Audit (Standard) and Exchange mailbox auditing, enabled by default for users with Office 365 or Microsoft 365 E3/E5 licences. It used to be a Premium feature; Microsoft extended it to Standard customers between September 2023 and June 2024, as recorded in CISA's expanded cloud logs playbook. On other plans, check mailbox audit settings before concluding anything from its absence. Retention and gaps covers this.

It covers all mail protocols: POP, IMAP, MAPI, EWS, Exchange ActiveSync and REST.

Sync vs Bind

Microsoft's reasoning for the Sync case is worth quoting in spirit: once a client has synced a folder, the attacker can read it offline and nothing more will be audited, so all items in that folder are assumed compromised.

Deduplication. Exchange drops duplicate bind records for the same message within an hour, and sync records at one-hour intervals, unless one of these differs: ClientIPAddress, ClientInfoString, ParentFolder, Logon_type, MailAccessType, MailboxUPN, User, SessionId. In practice a new IP or session produces new records, which is what you want to separate attacker and user.

Separating the attacker's reads from the user's

The same mailbox is accessed by the legitimate user and the intruder, sometimes within the same minute. Split by context:

The CISA/FBI advisory on the 2023 Exchange Online intrusion notes that unexpected ClientAppID and AppID values in MailItemsAccessed events were how the activity was detected (AA23-193A). The same idea works for BEC: the attacker's access has a context the user never uses.

Throttling

If a mailbox generates more than 1,000 MailItemsAccessed records in less than 24 hours, Exchange stops auditing it for 24 hours. Throttled records carry IsThrottled = True in OperationProperties (see Microsoft's hunting query and the CISA playbook). CISA notes that throttling is rare, so its presence is itself a signal. During the throttled window, absence of records proves nothing.

A practical procedure

1. From the sign-in analysis, list the attacker's IPs and Session IDs (AiTM detection).
2. Extract MailItemsAccessed for the victim mailbox (and any mailbox the account had delegate access to) over the attack window.
3. Split by MailAccessType. For Sync from an attacker context: list the folders, report them as fully exposed.
4. For Bind from an attacker context: collect every InternetMessageId, then find the messages (eDiscovery or content search) to assess their sensitivity.
5. Check IsThrottled and note any throttled window as a gap.
6. Record what cannot be established (missing licence, auditing off, throttling) in the report.

This is also the input to any breach-notification assessment: under the GDPR (Article 33), for example, a personal data breach must generally be notified to the supervisory authority within 72 hours of becoming aware of it, and the list of exposed messages is what decides whether personal data was involved.

What it does not prove

• That a person read the message. Access by a client or API is enough to create a record.
• What happened after an offline sync. Nothing after the sync is visible.
• Content. The record has message IDs (and sizes), not bodies or subjects for Bind. You need the mailbox to know what was in them.
• Access you did not audit. No record because of licence, configuration or throttling is not proof of no access.

How M365 Forensics uses it

The in-browser analyser raises "Unusual volume of mailbox items accessed" (high) when one account's MailItemsAccessed total reaches 300 items within an hour, summing OperationCount rather than counting records, and lists every record in that window as evidence, which can include the user's own Outlook activity next to the attacker's: use the IP and client columns to split them. When records carry an attacker IP or session, they also appear under the critical attacker-session finding. If no MailItemsAccessed record exists at all in the UAL export, the coverage panel says so. The current version does not weight Sync versus Bind differently.

Frequently asked questions

Does MailItemsAccessed prove that an e-mail was read?

It proves the message was accessed by a client or protocol, not that a human read it. For Bind records, treat the listed messages as exposed. For Sync records, treat the whole folder as exposed.

What is the difference between Sync and Bind?

Sync means a desktop Outlook client downloaded a folder; one record is written per folder, not per message. Bind means an individual message was accessed; its InternetMessageId is recorded, and binds within two minutes are aggregated into one record.

Which licence do I need for MailItemsAccessed?

Microsoft documents it as part of Audit (Standard), enabled by default for users with Office 365 or Microsoft 365 E3/E5 licences. Other plans may need mailbox auditing configuration.

Further reading

• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• MITRE ATT&CK: Remote Email Collection (T1114.002)
• Unified Audit Log investigation