Blog · Deliverability

Microsoft 365 Mailbox and Calendar Audit Logs: Compliance Investigator Guide

A compliance investigation that needs Microsoft 365 mailbox or calendar evidence usually starts the same way. Someone asks who read a message, who deleted a calendar event, or whether a particular sign-in reached the mailbox. The data does exist, but it lives in three different pipelines - mailbox audit logs, the unified audit log, and message trace - and the mailbox and calendar evidence you need comes from different parts of those pipelines depending on the question. Picking the wrong pipeline wastes hours. This guide gives a working map of which one to use when, with the actual PowerShell and portal steps to pull each one.

The single most important thing to get straight first: Microsoft 365 does not have a separate "calendar audit log." Calendar events are stored in user mailboxes, so calendar activity shows up in mailbox audit logs under the same mailbox actions as mail items - Create, Update, SoftDelete, HardDelete, MoveToDeletedItems. If you are looking for "who deleted that meeting," the mailbox audit log is where you start, not a separate calendar tool.

Which Microsoft 365 log answers which compliance question?

Three pipelines matter for mailbox and calendar evidence:

  • Mailbox audit logs record what mailbox owners, delegates, and admins did inside a mailbox - read, moved, deleted, sent on behalf of, hard-deleted, created, updated.
  • The unified audit log records a broader set of admin and user activity across Microsoft 365 - sign-ins, role assignments, inbox rule changes, eDiscovery searches, plus the same mailbox actions surfaced in a search-friendly form.
  • Message trace records what happened to a message on the transport side - accepted, rejected, deferred, delivered - but it does not record mailbox-side activity.

If the question is "who read or moved a message in this mailbox," start with the mailbox audit log via Search-UnifiedAuditLog. If the question is "what admin actions did someone perform against this tenant," use the unified audit log directly. If the question is "was this message even delivered, and where," use message trace.

What does the mailbox audit log actually record?

Mailbox auditing is on by default in all organizations. Microsoft manages a predefined set of mailbox actions for three sign-in types - Admin, Delegate, and Owner - and automatically includes new actions Microsoft releases.

To verify the default is on, run in Exchange Online PowerShell:

powershell
Get-OrganizationConfig | Format-List AuditDisabled

The value should be False. If it is True, mailbox auditing is off at the organization level and overrides mailbox-level settings.

For each individual mailbox, the relevant actions include SendAs, SendOnBehalf, HardDelete, SoftDelete, MoveToDeletedItems, Update, and Create. Create covers calendar item creation, which is why calendar evidence ends up here.

To check which audit actions are currently logged for a specific mailbox:

powershell
Get-Mailbox -Identity  | Select-Object -ExpandProperty AuditOwner
Get-Mailbox -Identity  | Select-Object -ExpandProperty AuditDelegate
Get-Mailbox -Identity  | Select-Object -ExpandProperty AuditAdmin

A non-empty value means those mailbox actions are being logged.

Where do calendar events show up?

Calendar items are stored in mailbox items, so they appear in mailbox audit logs under the same Create, Update, SoftDelete, HardDelete, MoveToDeletedItems actions. A meeting create, a meeting update (time change, attendee change), a cancellation, and a move to Deleted Items all produce mailbox audit records. The action label tells you it is a calendar item rather than a mail message.

Practical caveat: by default, simply opening or reading a meeting does not generate a mailbox audit record for Owner sign-ins unless the MailboxLogin action has been added. If your investigation hinges on "who viewed this calendar item," you need to confirm whether MailboxLogin is in the AuditOwner set, because the default Owner set does not include it. To add it:

powershell
Set-Mailbox -Identity  -AuditOwner @{Add="MailboxLogin"}

Remember that adding it stops that sign-in type from being auto-managed by Microsoft - future new actions need to be added manually too.

How long are these logs kept, and what changes that?

Mailbox audit log retention is now configured and managed in Microsoft Purview, not via the mailbox AuditLogAgeLimit property. That property is no longer the lever.

The defaults most organizations operate under:

  • Mailbox audit log entries are retained for 90 days by default.
  • Unified audit log entries are retained for 180 days by default for most Microsoft 365 E5 and G5 tenants, and for 90 days for other license tiers.
  • Audit Premium (E5/G5 add-on or included in some suites) can extend unified audit log retention up to 10 years with a default retention policy of one year.

If your investigation requires evidence older than the default retention, you must have had an applicable Purview audit retention policy in place before the events occurred. There is no retroactive way to recover mailbox audit log records that aged out. Practical example: an investigation opened in October needs mailbox evidence from August. Without a 180-day or longer Purview audit retention policy active during that August window, the relevant mailbox audit records no longer exist. Setting a policy now recovers nothing.

How do you actually pull the data out?

For mailbox and calendar events, the practical cmdlet is Search-UnifiedAuditLog. The mailbox audit log search and the unified audit log are exposed through this cmdlet, which makes it the single best starting point for most investigators.

To pull mailbox events for a specific user over a date range:

powershell
Search-UnifiedAuditLog 
  -UserIds  
  -Operations "HardDelete","SoftDelete","MoveToDeletedItems","SendAs","SendOnBehalf","Update","Create" 
  -StartDate "" 
  -EndDate "" `
  -ResultSize 5000

Calendar items appear under the same Operations values. The RecordType tells you the workload; calendar events are surfaced under the Exchange workload record types.

For wider tenant-wide searches (admin actions, inbox rule changes, sign-ins), use the same cmdlet without the UserIds filter, or use the audit log search in the Microsoft Purview compliance portal, which presents the same data in a UI.

For transport questions, use Get-MessageTrace or Get-MessageTraceDetail in Exchange Online PowerShell. Remember that message trace has its own default retention (up to 90 days for basic, up to 10 days for enhanced reporting).

A worked example

Question: who read or deleted a particular message in user@contoso.com between September 1 and September 15?

1. Confirm auditing is on for the tenant: Get-OrganizationConfig - check AuditDisabled is False.
2. Confirm the per-mailbox audit actions are not customized in a way that hides what you need: Get-Mailbox -Identity user@contoso.com - review AuditOwner, AuditDelegate, AuditAdmin.
3. Search the unified audit log for the user with the relevant operations: Search-UnifiedAuditLog -UserIds user@contoso.com -Operations "HardDelete","SoftDelete","MoveToDeletedItems","MailboxLogin" -StartDate ... -EndDate ...
4. If you need to know whether the message even reached the mailbox, layer in a message trace: Get-MessageTrace -SenderAddress ... -RecipientAddress user@contoso.com -StartDate ... -EndDate ...
5. Cross-reference results before handing anything to the investigator: do the mailbox action times line up with the message trace delivery times? Mismatches mean either the wrong mailbox is being audited or the log view is incomplete.

For investigators who prefer a UI, the same Search-UnifiedAuditLog data is available under Audit in the Microsoft Purview compliance portal, with the same date and operation filters and the ability to export to CSV. PowerShell is faster for repeat investigations and scripted evidence pulls; the portal is friendlier for one-off reviews with stakeholders.

For active investigations where evidence must not be aged out, place the relevant mailboxes under an eDiscovery hold (Purview eDiscovery Standard or Premium). Hold preserves mailbox content and audit records for the held scope until the hold is released, independent of normal retention.

What commonly goes wrong during an investigation?

Five patterns come up over and over:

  • AuditDisabled was set to True at some point. If the tenant has AuditDisabled set to True, no mailbox actions are logged, regardless of the per-mailbox setting.
  • Customized mailbox actions are blocking default Microsoft actions. If someone used Set-Mailbox -AuditAdmin ... -AuditDelegate ... -AuditOwner ... at any point, the DefaultAuditSet stops covering those sign-in types and new Microsoft default actions are no longer applied. If new actions show up in a Microsoft release, you have to add them to the customized list yourself.
  • Bypass associations silently skip logging. Set-MailboxAuditBypassAssociation -AuditByPassEnabled $true against an admin account means every action that admin performed is missing from the audit trail. Always verify bypass associations before trusting the timeline.
  • Retention aged out before the investigation started. If the events happened more than 90 days ago and no Purview audit retention policy was active, the mailbox audit records no longer exist. The investigation cannot recover them.
  • Calendar reads are missing from the log. As noted earlier, Owner reads of calendar items do not log MailboxLogin by default. If the question is "who viewed this meeting," check the AuditOwner set first.

Where DMARC reporting fits in (briefly)

If your investigation touches on whether a specific message actually left your domain - did our subdomain send this, was this IP an authorized sender, did the message pass DKIM alignment - the right tool is DMARC aggregate and forensic (RUA and RUF) reports, not the Microsoft 365 audit logs. A RUA report shows daily volume from each sending source and whether those sources were aligned under your SPF or DKIM policy. A RUF report carries the failing-message samples with header hashes for forensic review. DMARCFlow parses both report types and surfaces who was sending on your behalf and whether those senders stayed aligned. For mailbox-side questions, Microsoft Purview is the right tool. For sender-identity questions, DMARC reporting is the right tool. Knowing the boundary saves time during an investigation that touches both.

FAQ

Is mailbox auditing turned on by default in Microsoft 365?
Yes. Mailbox auditing on by default has been the default since 2019, and Microsoft manages the default action set.

Are calendar events logged separately from mailbox messages?
No. Calendar items are stored in the mailbox, so they appear in mailbox audit logs under the same Create, Update, SoftDelete, HardDelete, MoveToDeletedItems actions.

How long does Microsoft keep mailbox audit logs?
By default, 90 days. Longer retention requires a Microsoft Purview audit retention policy applied while the events were still within retention.

Why are some mailbox actions missing from the unified audit log search?
Most likely causes: the mailbox actions were customized on that mailbox and Microsoft default actions no longer apply; the user is on the bypass association list; or AuditDisabled was set at the organization level.

Can a user disable auditing on their own mailbox?
No. AuditEnabled on the mailbox is ignored when mailbox auditing on by default is active at the organization level.

Does Audit Premium change the retention rules?
Yes. Audit Premium can extend unified audit log retention up to 10 years, but mailbox audit log entries still age out of their pipeline unless a Purview retention policy is configured to keep them.

Closing note

For mailbox and calendar evidence, the working mental model is: mailbox audit logs are the source of truth for mailbox activity, the unified audit log is the search-friendly front door over the same data plus admin and sign-in events, and message trace answers the separate question of transport delivery. Confirm organization-level auditing is on, confirm the per-mailbox action set has not been customized in a way that hides what you need, verify the bypass association list, and check retention against the date range the investigator actually needs. With those four checks done before the search, you usually avoid the common surprises that derail compliance investigations in Microsoft 365.