How to Search the Mailbox Audit Log in Microsoft 365

If someone deleted a message from a shared mailbox, or you suspect an account was compromised and want to know exactly what happened inside it, the mailbox audit log in Microsoft 365 is where that history lives. Mailbox audit logging has been turned on by default for every Exchange Online mailbox since January 2019, so in almost every tenant the records already exist — you just need to search them.

The search itself runs through the Microsoft Purview compliance portal, or through PowerShell if you'd rather script it, and it covers far more than deletions: who opened a folder, who sent a message using another user's identity, who changed a folder permission. What actually trips people up isn't the search mechanics — it's two things that changed recently. The cmdlet a lot of old internal runbooks still reference has been retired, and retention is shorter than most admins assume unless the tenant carries an E5 license. Here's the current, verified procedure, including the parts that quietly stopped working.

Before you start#

Confirm two things before you open a search: that auditing is actually active for the organization (it should be, by default), and which sign-in type you're really investigating — owner, delegate, or admin — because Microsoft audits a different set of actions for each one out of the box.

• Confirm the org-wide setting. Run Get-OrganizationConfig | Format-List AuditDisabled in Exchange Online PowerShell. A value of False means auditing on by default is active for the whole tenant, and it overrides any mailbox-level setting that says otherwise.
• Get the right role. Searching requires the Audit Logs or View-Only Audit Logs role in the Microsoft Purview portal. The same role in the Exchange admin center is what lets you run the PowerShell cmdlet instead. A mailbox owner can't self-serve their own audit history without one of these.
• Check the mailbox type. User mailboxes, shared mailboxes, and Microsoft 365 Group mailboxes support auditing on by default. Resource mailboxes and public folder mailboxes don't — there's nothing to search there.
• Retention rides on the actor's license, not the mailbox's. A shared mailbox typically has no license of its own. How long its records stick around depends on the license of whoever performed the logged action — the delegate or admin who signed in — not the shared mailbox itself.

Steps: running the search#

The Purview portal is the fastest path for a one-off investigation. Everything here also works from PowerShell if you'd rather automate it or run it against a wider admin scope — see the equivalent command below.

1. 1

   Open Audit in the Purview portal

   Sign in to the Microsoft Purview portal, select the Audit solution card — under View all solutions → Core if it isn't pinned to your view — and open the Search page.

2. 2

   Set the date range

   Pick a start and end date and time, shown in UTC. A single search job can't span more than 180 days; if the incident is older than that, you'll need to know whether the record is even still retained before you bother running the search.

3. 3

   Choose the activities

   Use Activities - friendly names to pick common ones by plain description, or Activities - operations names to type exact operation names. For a deletion or access investigation, SoftDelete, HardDelete, MoveToDeletedItems, SendAs, SendOnBehalf, Update, and MailItemsAccessed cover most of what you're actually looking for.

4. 4

   Scope it to the mailbox

   Add the specific user or shared mailbox in the Users field. Leaving it blank searches every mailbox in the tenant — it works, but it takes far longer to run and buries the record you want in noise from everyone else.

5. 5

   Run it and wait for the job

   Select Search. Jobs run in the background — you can close the browser tab — and move through Queued, In Progress, and Completed on the search job dashboard. Core services including Exchange are usually visible in results within 60 to 90 minutes of the activity itself, though Microsoft doesn't commit to a fixed delay.

6. 6

   Read or export the results

   Open the completed job to see the date, user, IP address, and activity for each matching record, with a details flyout for anything you select. Export to CSV for anything you need to hand off — up to 50,000 rows on Audit (Standard), up to 1,000,000 on Audit (Premium).

Once a search job finishes, the result reads like a timeline: who, what action, and exactly when — the same shape whether you pulled it from the portal or ran the cmdlet by hand.

Audit (Standard) vs. Audit (Premium) retention#

How far back you can search depends on licensing, and it's the single most common reason a legitimate investigation comes up empty — the record existed, it just aged out before anyone went looking for it.

The license that counts is the one attached to whoever generated the record, not the mailbox that was acted on. A shared mailbox with no subscription of its own still gets a retention window — it just inherits the window of the delegate or admin who did the deleting, sending, or moving. Two delegates on the same shared mailbox, one licensed E5 and one on a base plan, can end up with different retention for actions they each took in the exact same mailbox on the exact same day.

Custom retention policies, where you have the license for them, take priority over the default policy. If your organization needs Exchange mailbox activity kept longer than the default without paying for a blanket 10-year policy, you can scope a custom policy to just that record type and just the users who need it.

What to do when the search doesn't work#

• No results at all. Check Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled in Exchange Online PowerShell. If it's False, audit log search itself is off for the entire tenant, independent of the per-mailbox auditing setting you might have already confirmed.
• The activity you need isn't in the default set. FolderBind, and MessageBind on non-E5 mailboxes, have to be added manually to AuditDelegate or AuditAdmin — see the callout above. Add it, then wait; you can't retroactively search for events from before the setting was turned on.
• "The selected date range is greater than 180 days." A single Purview search job is capped at 180 days. If you're using the maximum range, set the start time to the current time of day, or you'll get an error saying the start date is later than the end date.
• You're looking in the wrong geography. In a multigeo tenant, cross-geo mailbox access by a delegate isn't logged in that mailbox's own audit trail. Exchange admin actions still show up tenant-wide through Search-UnifiedAuditLog; ordinary cross-geo delegate access currently doesn't.
• The record isn't there yet. Exchange and the other core services typically surface within 60 to 90 minutes of the activity, but Microsoft doesn't guarantee a fixed delay. For a live incident, re-run the search in a few minutes rather than assuming the action wasn't logged.

A faster way — for what your AI agent did, not what a colleague did#

None of this replaces Purview audit search. A compliance-grade investigation into who touched a mailbox needs the tenant-wide log above, and that isn't a job an individual email client should try to take over.

We build AI Emaily, an AI email client. Every action our agent takes on your behalf — filing a message, drafting a reply, archiving a thread — is either held for your approval in Copilot mode or logged with one-click undo in Autopilot, and kept in your own account's action log. That's a much narrower thing than the Microsoft 365 mailbox audit log: it only sees the agent's own actions, not what a colleague or an admin did in a shared mailbox. For the day-to-day "wait, did my agent just do that?" question, though, it's instant — no Purview role, no PowerShell session, no 180-day window to worry about.