Mailbox Audit Logging Guide: What Exchange Online and Gmail Record, and the Gaps

Most mailbox investigations fail on one question, "which messages did the attacker actually read?", because the mailbox audit trail was trimmed, bypassed, licensed differently or never covered that client. Exchange Online and Gmail both record mailbox activity, but they record different things, with different defaults and different blind spots. This guide covers the per-mailbox layer: which actions Exchange Online audits by default for each logon type, how customisation and bypass quietly remove coverage, what MailItemsAccessed can and cannot prove, and what the Gmail log events in Google Workspace show. It is written for detection engineers, incident responders and messaging administrators who need to know, before an incident, what evidence will exist. Platforms are listed alphabetically, and the order is not a ranking.

This is an independent guide from NHI Mgmt Group, based on Microsoft's and Google's public documentation as of November 2026. It is not sponsored or reviewed by either vendor. Product features change, so confirm settings against each vendor's current documentation.

Key takeaways

• On by default is not the same as complete. Exchange Online audits user, shared and Microsoft 365 Group mailboxes by default, but only a managed set of actions per logon type, and searches (SearchQueryInitiated) and mailbox sign-ins (MailboxLogin) are off unless you add them.
• One customisation freezes a mailbox in time. Changing the audited actions for a logon type removes it from DefaultAuditSet, and Microsoft then stops adding new default actions to that mailbox.
• Bypass follows the account, everywhere. A mailbox audit bypass association stops logging of everything that account does, in its own mailbox and every mailbox it can open as a delegate or admin.
• MailItemsAccessed answers "what was read", within limits. Sync records mean a whole folder; Bind records give message IDs; reading offline after a sync leaves no record.
• Gmail logs user mail actions, but for six months only. Gmail log events record actions such as Send, View, Link click and Attachment download with client, IP and delegate details; retention is fixed, so export is the only way to keep more.

Where mailbox auditing sits

Mailbox auditing is the layer that records what happens inside a mailbox: items read, sent, moved, deleted, rules and folder permissions changed. It is distinct from message trace (delivery), sign-in logs (authentication) and admin audit (configuration). The Microsoft 365 Unified Audit Log Guide covers how Exchange records reach the unified log, retention by licence and SIEM collection; the Google Workspace Audit Log Detection Guide covers the Reports API, login, admin and token logs. This page stays on the mailbox layer and what it can prove.

Delivery evidence belongs to a different toolset: see the Email Gateway and Message Trace Detection Guide.

Exchange Online: logon types and default actions

Microsoft's documentation states that mailbox audit logging is on by default in all organisations and that new mailboxes are audited automatically. Each record is tagged with a logon type, and the audited actions differ per type.

• Owner: the account associated with the mailbox.
• Delegate: a user holding SendAs, SendOnBehalf or FullAccess on another mailbox. An administrator granted FullAccess to a user's mailbox is recorded as a delegate, not an admin.
• Admin: mailbox searched with eDiscovery in Microsoft Purview, opened with the MAPI Editor, or accessed by an account using the ApplicationImpersonation role.

Microsoft 365 Group mailboxes have a fixed set (Create for calendar items, HardDelete, MoveToDeletedItems, SendAs, SendOnBehalf, SoftDelete, Update) that you cannot change. Public folder and resource mailboxes are not in the supported list, and cross-geo access in a multi-geo tenant is not recorded in the target shared mailbox's audit log. Microsoft also notes that new default actions are added subject to the user having the appropriate licence.

How coverage is lost: customisation, bypass and the org switch

DefaultAuditSet drift

DefaultAuditSet shows which logon types still follow Microsoft's managed defaults. A value of Admin, Delegate, Owner means untouched; a blank value means all three have been customised. Microsoft's guidance is explicit: after you customise a logon type, new default actions are not audited automatically and must be added by hand. This is how tenants that scripted their own audit lists years ago ended up without MailItemsAccessed when Microsoft added it. Read the current state with Get-Mailbox and the DefaultAuditSet, AuditOwner, AuditDelegate and AuditAdmin properties, and restore with Set-Mailbox -DefaultAuditSet Admin,Delegate,Owner. Restoring replaces the custom list, so record what was customised and why before you do it.

The safer pattern for adding SearchQueryInitiated or MailboxLogin is the add form (AuditOwner with an Add hashtable). That still counts as a customisation of the Owner type, so plan to re-check Owner defaults whenever Microsoft announces a new default action.

Bypass associations

Setting AuditEnabled to False on a mailbox is ignored while on-by-default auditing is active. The only per-account off switch is Set-MailboxAuditBypassAssociation, and its scope is wide: all owner actions by that account, its delegate actions in other mailboxes including shared mailboxes, and its admin actions. Bypass was historically used to silence noisy service accounts such as archiving or backup tools, which makes it a non-human identity problem: an account with FullAccess to many mailboxes and no audit trail is the ideal place for an attacker to hide. See the How to Review M365 Apps with Mail Permissions guide for the application side of mailbox access.

The organisation switch

Get-OrganizationConfig should show AuditDisabled as False. If it is set to True, no mailbox actions are audited, new mailboxes are not audited, and bypass associations are ignored; existing records are kept until their retention ends. Treat any change to it, or to a bypass association, as a security event. ATT&CK v20 models this as T1685.002 Disable or Modify Cloud Log.

Retention is no longer per mailbox

Microsoft states that AuditLogAgeLimit no longer applies to mailbox audit retention; retention is controlled by Microsoft Purview audit retention policies. Audit (Standard) keeps records for 180 days. Audit (Premium) keeps Exchange records for one year by default and supports policies up to ten years with an add-on licence, which is not retroactive. Retention follows the licence of the user who generated the record.

MailItemsAccessed: what it proves and what it cannot

Microsoft documents MailItemsAccessed as part of Audit (Standard) and Exchange mailbox auditing, enabled by default for users with Office 365 or Microsoft 365 E3 or E5 licences. It covers POP, IMAP, MAPI, EWS, Exchange ActiveSync and REST access. Audit (Premium) adds the SensitivityLabel property, so you can see the label on accessed items.

Scoping rule: start with Sync records for the attacker's IPs and SessionId values; any match means the folder, and in practice often the mailbox, is exposed. Then use Bind records to list individual InternetMessageId values for notification and legal review. The Data Exposure Scoping Playbook covers turning these lists into a notification decision.

Gmail: what the Gmail log events record

Google Workspace records mailbox activity as Gmail log events, searchable in the audit and investigation tool (Audit and Investigation privilege required) and through the Reports API and BigQuery export. Google lists the Event attribute with examples such as Attachment download, Link click, Send and View, and the Client Type attribute with examples such as Web, Android, iOS and POP3.

Retention and lag: Google states Gmail log events arrive in near real time (a couple of minutes) and are kept for six months, and that administrators cannot change that period. Email Log Search, the delivery view, keeps 30 days. Searches cannot return data for messages already deleted from Trash.

Gaps to test, not assume: Google's documentation gives client types as examples rather than a full list. Before you rely on Gmail log events for IMAP or API access, generate a test read from each client and API path your tenant permits, and confirm what appears. Configuration events that change mailbox reach, such as external forwarding, delegation and admin email monitors, sit in the login and admin logs rather than Gmail log events; see the Gmail Security Settings Guide for Workspace Admins.

Choosing what to turn on

The trade-off is noise and cost against proof. SearchQueryInitiated and MailboxLogin add volume, so target them at mailboxes where knowing what an intruder searched for (passwords, invoices, bank details) would change the response. In both platforms, collecting into your own store is the only way to outlast native retention.

Rolling it out

1. Baseline: export AuditDisabled, every mailbox's DefaultAuditSet and audit action lists, and all bypass associations. In Google Workspace, confirm the edition and who holds the Audit and Investigation privilege.
2. Fix drift in a pilot ring: restore DefaultAuditSet on a group of 20 to 50 customised mailboxes, record the previous lists so you can roll back with Set-Mailbox, and check record volume for a week.
3. Remove bypass: for each bypassed account, identify the owner and purpose, remove the bypass, and replace any noise problem with SIEM filtering.
4. Add targeted actions: enable SearchQueryInitiated and MailboxLogin for high-value Owner mailboxes.
5. Test end to end: in a pilot mailbox, read in Outlook desktop and on the web, send, create an inbox rule and delete an item; in Gmail, view, send and click a test link. Time arrival in the SIEM.
6. Alert on tampering: AuditDisabled changes, new bypass associations, Set-Mailbox changes to audit parameters, and gaps in mailbox record volume.
7. Rollback: if volume overwhelms collection, filter in the pipeline rather than reducing what the mailbox records, because records not generated cannot be recovered.

Detection and measurement

• MailItemsAccessed from a second session: Sync records from an IP or client never seen for that user; Bind bursts with high OperationCount outside working hours. Maps to T1114.002 Remote Email Collection.
• Rule and permission changes: UpdateInboxRules and UpdateFolderPermissions shortly after a new sign-in (T1137.005 Outlook Rules, T1114.003 Email Forwarding Rule, T1098.002 Additional Email Delegate Permissions). For the full rule sweep, see How to Audit Mailbox Forwarding and Inbox Rules.
• Cleanup: SoftDelete and HardDelete bursts after Send events to external domains (T1070.008 Clear Mailbox Data).
• Gmail: View events from a new Client Type or ASN, Send events by a delegate, Actor application info with an unknown OAuth client ID.

Common failure patterns

• Scripted audit lists from years ago: mailboxes customised before MailItemsAccessed existed never received it, so exposure cannot be scoped.
• Bypass on a broad service account: a backup or archiving account with FullAccess to every mailbox and auditing bypassed becomes invisible if its credential leaks.
• Assuming Sync means "nothing more": once a folder is synced, offline reading leaves no trace; responders under-report exposure when they count only Bind records.
• Licence mismatch: the investigation needs month eight, but the compromised users sat on a 180-day licence or in a Gmail tenant with six-month retention and no export.
• Admin with FullAccess read as an admin event: it is logged as Delegate, so filters on logon type Admin miss it.
• Purged before preserved: in Gmail, messages emptied from Trash return nothing; in Exchange, retention keeps rolling. Preserve first, then remediate. The Business Email Compromise Response Playbook sets the order.

Framework mapping

For how mailbox evidence feeds wider log management, see the CIS Control 8 Audit Log Management Guide.

Practitioner checklist

• Confirm AuditDisabled is False and alert on any change to it.
• Report every mailbox whose DefaultAuditSet is not Admin, Delegate, Owner and restore or document each one.
• Inventory bypass associations, remove them, and give any remaining exception a named owner and review date.
• Add SearchQueryInitiated and MailboxLogin for executive, finance, legal and HR mailboxes.
• Map each high-value user's licence to its audit retention and close gaps with licences or export.
• Stream Gmail log events and Exchange mailbox records to storage that outlasts native retention.
• Test Gmail and Exchange coverage per client and API path your tenant permits, and record what is not captured.
• Build scoping runbooks that use Sync for folders and Bind or Message ID for individual messages.
• Restrict who holds Audit Logs and Audit and Investigation roles, because they can read and shape the evidence.

Standards and references

• Microsoft Learn: Manage mailbox auditing
• Microsoft Learn: Use MailItemsAccessed to investigate compromised accounts
• Microsoft Learn: Learn about auditing solutions in Microsoft Purview
• Microsoft Learn: Microsoft Purview Audit (Premium)
• Google Workspace Admin Help: Gmail log events
• Google Workspace Admin Help: Data retention and lag times
• MITRE ATT&CK: Remote Email Collection

Related NHI Mgmt Group resources: Microsoft 365 Unified Audit Log Guide · Google Workspace Audit Log Detection Guide · Exchange Online Security Guide · Email Forensics and Header Analysis Guide