Learn · Telemetry

Email Telemetry in Microsoft 365

Read the records Microsoft 365 keeps about mail and mailboxes: where each message landed, who clicked, what was removed later, and what changed in a mailbox after a suspicious sign-in.

Not yet read in this browserSign in to see where you have applied this.

Why it matters

Most organizations no longer run their own mail server. Their mail, and the evidence of what happened to it, lives in Microsoft 365, and an analyst who only knows server logs will not know where to look.

The message is rarely the whole incident. A click, a sign-in from somewhere new and a quiet change to the mailbox are what turn a phish into a compromise, and Microsoft 365 records each of those in a different place.

What analysts see

Microsoft 365 keeps two families of records that matter for an email incident:

Email events from Defender for Office 365: one record per message per recipient, with the delivery action, where it landed, any threat detected and the authentication results.
Related detail: the links and attachments in each message, and every click on a link the protection service rewrote.
Post-delivery events: messages moved or removed after delivery, automatically or by an administrator.
The unified audit log: account and mailbox activity, including sign-ins, new inbox rules and changes to forwarding.

In Elastic, these arrive through the Microsoft 365 and Microsoft Defender integrations, mapped where possible to the standard email.*, url.* and event.* fields.

Core concept

Email events say what happened to a message: delivered or stopped, and whether it reached the inbox, junk or quarantine. They are Microsoft 365's message trace, tied together by a network message ID that is the same on every recipient's copy.

Click events say who acted on it. When links are rewritten for protection, every click passes through the service and is recorded with the user, the time and whether the click was allowed. A click is evidence that a person engaged; delivery alone is not.

Audit records say what changed afterward. Someone who takes over a mailbox often hides their tracks with an inbox rule that moves or deletes replies, or sets up forwarding to an outside address. Those changes are audit operations on the mailbox, often minutes after a sign-in from somewhere that user has not signed in from before.

Investigate in the order things happened: the message, the click, the sign-in, the mailbox change. Each record leads to the next by user and time.

Annotated examples

One message, every recipient

The email events for a message reported as suspicious:

NetworkMessageId:: "7d3e5a10-2c4b-4f8e-9a61-0b5c3e7f1d22" (note 1)
SenderFromAddress:: "enrollment@hr-portal.example"
RecipientEmailAddress:: "d.reyes@corp.example" Delivered Inbox/folder (note 2)
RecipientEmailAddress:: "k.osei@corp.example" Delivered Junk folder
AuthenticationDetails:: SPF=pass DKIM=none DMARC=fail (note 3)

Note 1: The same ID on every recipient's copy. Search on it to list them all.
Note 2: Delivered to the inbox. The second copy went to junk, where it can still be opened.
Note 3: The domain the reader sees did not pass DMARC.

One row per recipient. Every row with this ID is a mailbox the message reached, including the one where it landed in junk.

Who clicked

The click events for links in that message:

Url:: "https://hr-portal.example/benefits/review"
ActionType:: "ClickAllowed" (note 1)
AccountUpn:: "d.reyes@corp.example"
NetworkMessageId:: "7d3e5a10-2c4b-4f8e-9a61-0b5c3e7f1d22" (note 2)
Timestamp:: "2026-03-11T09:02:44Z"

Note 1: The click was let through. A click that was stopped is recorded too, with a different action type.
Note 2: The same ID as the email event: this click came from that message.

Delivery says the message arrived; this says a person engaged with it. That user's sign-ins are the next place to look.

A sign-in, then a rule

The audit log for the same user, later that morning:

event.action:: "UserLoggedIn"
source.ip:: "203.0.113.88" (note 1)
event.action:: "New-InboxRule" (note 2)
rule condition:: subject or body contains "enrollment"
rule action:: move to folder "Archive 2019" (note 3)

Note 1: An address this user has not signed in from before.
Note 2: Minutes later, a new inbox rule on the same mailbox.
Note 3: Matching mail goes to a folder nobody reads, so replies about the scheme never reach the user.

A sign-in from somewhere new, then a rule that hides mail: the shape of a mailbox takeover. The rule is evidence first; removing it comes after it is recorded.

Removed after the click

The post-delivery events for the message:

ActionType:: "Phish ZAP" (note 1)
Action:: "Moved to quarantine"
ActionResult:: "Success"
Timestamp:: "2026-03-11T09:31:05Z" (note 2)

Note 1: Zero-hour auto purge removed the message after its verdict changed.
Note 2: About 28 minutes after the click above. The click happened while the message was still in the inbox.

Removal stops anyone else acting on the message. It does nothing about a click that already happened.

How to investigate

1.
Find the message.
Search the email events by sender, subject or link, and take its network message ID.
```
email.from.address: "enrollment@hr-portal.example"
```
2.
List every recipient and where it landed.
Every email event with that ID: the delivery action and location for each recipient, junk included.
3.
Find the clicks.
Click events with the same message ID, or the same link across all messages. Note who clicked and whether the click was allowed.
```
url.domain: "hr-portal.example"
```
4.
Check those users' sign-ins.
For each user who clicked, look for a sign-in from an address, location or device that user has not used before, soon after the click.
5.
Check their mailboxes.
Audit operations on those mailboxes after that sign-in: new or changed inbox rules, forwarding changes, mail read from the new session.
```
event.action: ("New-InboxRule" or "Set-InboxRule" or "Set-Mailbox")
```

Common mistakes

Mistake: Stopping at delivery.
InsteadDelivery says the message arrived. Check clicks and sign-ins for every recipient.
Mistake: Treating a purged message as resolved.
InsteadCheck what recipients did between delivery and removal.
Mistake: Ignoring copies that went to junk.
InsteadJunk is still a mailbox folder. Those copies can be opened, and their links clicked.
Mistake: Looking for mailbox changes in the email events.
InsteadInbox rules and forwarding are audit operations on the mailbox. Search the audit log.
Mistake: Deleting a malicious inbox rule straight away.
InsteadRecord its conditions, actions, creator and time first. It shows what the intruder wanted hidden.

Field references

Field	What it tells you	Seen in
NetworkMessageId	Microsoft 365's ID for one message, the same on every recipient's copy.	Defender email and click events
DeliveryAction, DeliveryLocation	Whether the message was delivered, sent to junk or stopped, and the folder it landed in.	Defender email events
ActionType (click events)	Whether a click on a protected link was allowed or stopped.	Defender click events
email.from.address, email.to.address	Sender and recipients, in the standard fields.	Microsoft 365 and Defender integrations
event.action	The audited operation, such as a sign-in or a new inbox rule.	Microsoft 365 audit log
source.ip	The address a sign-in or audited action came from.	Microsoft 365 audit log

Apply it in a Case

Our ranges run their own mail server rather than Microsoft 365, so the records look different, but the order of questions does not. Pick a case with mail telemetry and follow it: the message, every recipient, who acted on it, and what changed afterward.