After a phishing wave, someone eventually wants proof of who approved the clean-up. To audit email remediation in Microsoft Defender for Office 365, you shouldn't have to dig through several consoles. In October 2026 Microsoft added the ApproverUpn field to Advanced Hunting, which closes a gap I have hit more than once. This is how I use it.
In short: The EmailPostDeliveryEvents table in Microsoft Defender XDR Advanced Hunting now includes ApproverUpn. The field identifies the user or administrator who approved a remediation action, for example moving a delivered message to quarantine after an automated investigation. You can now show approvals directly in a hunting query.
Remediation approvals need a paper trail
In a lot of small and mid-sized tenants, more than one person looks after email security. One admin purges a campaign in Threat Explorer while another approves a pending action from automated investigation and response (AIR). Then an incident review or audit comes along, and someone asks who decided what, and when.
Until now the data showed me that an administrator triggered an action, but not always which administrator approved it. I had to reconstruct that from other sources. The new field takes the guesswork out, and you'll find it in the October 2026 entries on the Defender for Office 365 what's new page.
EmailPostDeliveryEvents records what happens after delivery
This table logs actions taken on a message once it has been delivered, including manual remediation and zero-hour auto purge (ZAP) for phishing and malware. The table schema reference documents columns such as ActionType, ActionTrigger, ActionResult and DeliveryLocation.
ApproverUpn shows up in the Advanced Hunting schema pane
Open Advanced Hunting in the Microsoft Defender portal (security.microsoft.com) and look at the schema pane. At the time of writing, the what's new page mentioned the field but the schema reference didn't list it yet. So before I build anything on it, I check in my own tenant that it has actually rolled out.
Every approval passes through detection, sign-off and a log entry
A remediation begins with a detection, from Threat Explorer or an automated investigation, for instance. The system then proposes an action or carries it out. Where an action needs sign-off, an administrator confirms it in the Action center. The outcome is written to EmailPostDeliveryEvents, and the approver is now part of that record.
flowchart LR
A["Detection"] --> B["Investigation (AIR)"]
B --> C["Admin approval"]
C --> D["Action on message"]
D --> E["Log entry with ApproverUpn"]
The path from detection to an auditable entry in Advanced Hunting.
Pay attention to the ActionType value. "Manual remediation" covers actions taken in Threat Explorer as well as approved AIR actions. ZAP entries are generated automatically, so nobody approved them. When you look at ApproverUpn, filter for manual actions deliberately.
You need Defender for Office 365 and hunting access
The requirement is Microsoft Defender for Office 365 Plan 1 or Plan 2 plus access to Advanced Hunting. A security reader role is enough for read-only queries, provided hunting is available to that role. Taking actions in Threat Explorer needs further permissions, which are covered in the AIR documentation.
One query lists the approvals of the last 30 days
I run the query below in the Microsoft Defender portal under Investigation & response → Hunting → Advanced hunting, where KQL is fully supported. It returns manual remediation actions grouped by approver.
EmailPostDeliveryEvents
| where Timestamp > ago(30d)
| where ActionType == "Manual remediation"
| summarize Actions = count(),
Mailboxes = dcount(RecipientEmailAddress),
LastAction = max(Timestamp)
by ApproverUpn, Action, ActionResult
| order by Actions desc
An error about ApproverUpn means the field hasn't reached your tenant yet. When that happens, I remove the column and try again a few days later. If you're new to the query language, start with the Advanced Hunting overview.
An empty ApproverUpn usually means nobody approved
In most cases the action ran without a human approval, as with automatic actions. Manual entries created before the field existed are also empty.
ApproverUpn alone does not make a complete chain of evidence
I treat it as one piece of the picture. For a full chain of evidence I add message details such as NetworkMessageId and DeliveryLocation, along with the history in the Action center.
Tip: When the query runs without errors, save it in the Defender portal via Advanced hunting → Save → Create detection rule. This requires permission to manage custom detections. Unusual approval patterns, like a lot of approvals outside business hours, then show up as alerts in your incident queue.
The review belongs in your regular security operations
A query that nobody opens is useless. I schedule the review at a fixed interval, monthly for example, as part of the security review. If you want ideas on routing incident notifications in a small team, have a look at my post on Defender XDR incident notifications for small teams.
The basic protection settings count as well. With impersonation protection set up properly, you'll have less manual remediation to do later. I go through the settings in my article on impersonation protection in Defender against CEO fraud.
Only a small group of admins should approve actions
Not every admin needs that right. I decide which roles are allowed to approve and keep the group small. With fewer approvers, ApproverUpn tells you more in your reports.
I am rolling this out over the coming weeks
My approach has three steps. I start by checking the Advanced Hunting schema for ApproverUpn. Next I run the 30-day query and match the results against the incidents I already know about. After that I decide whether a detection rule is worth it.
Customers with audit obligations benefit quickly, since they can show approvals without additional tooling. Smaller environments usually get by with a monthly check. Once the column appears in the official schema reference, I'll update my saved queries.
