ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
EmailEvents • Microsoft Defender XDR • KQL Investigation Guide

EmailEvents KQL Guide for Microsoft Defender

This page is built as a practical guide to reading EmailEvents in Microsoft Defender XDR. It is not just about copying a query. It is about understanding what the email data is telling you: who the message claimed to be from, how it was authenticated, whether it was delivered, and where to pivot next.

Use this guide when you need to analyse suspicious email, sender mismatch, spoofing indicators, AuthenticationDetails, DMARC failures and delivery outcomes across your Microsoft 365 environment.

The goal is simple: move from “this email looks suspicious” to evidence you can explain, investigate and act on.

Discuss your environment Back to briefings
EmailEvents KQL Guide for Microsoft Defender by GEMXIT
EmailEvents guide summary

A practical Microsoft Defender guide for analysts and administrators who want to understand EmailEvents, sender fields, AuthenticationDetails, delivery actions and investigation pivots.

Understand key EmailEvents fields
Read AuthenticationDetails correctly
Pivot from delivery to clicks and identity
🚨 Why EmailEvents matters
EmailEvents is where many Microsoft 365 email investigations start. • It shows visible sender details and delivery information • It exposes AuthenticationDetails such as SPF, DKIM and DMARC results • It gives you the NetworkMessageId needed to pivot into URL clicks and deeper investigation 👉 This is the difference between guessing and proving what happened 👉 Or explore how we approach Microsoft security operations
Book an email security review →

What EmailEvents actually tells you

EmailEvents is not just a log of emails. It is a structured investigation table that helps you understand sender identity, authentication, delivery and timing.
1. Who the message claimed to be from Fields such as SenderFromAddress and SenderFromDomain help you understand the visible sender shown to the user.
2. How the message was authenticated AuthenticationDetails can show SPF, DKIM, DMARC and spoofing signals that help explain whether the sender should be trusted.
3. What happened to the message DeliveryAction helps you see whether the message was delivered, blocked, junked, quarantined or allowed by policy.

Baseline query: start with the EmailEvents story

Use this query when you want a clean view of the core EmailEvents fields used during a Microsoft Defender email investigation.
emailevents-baseline-investigation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
EmailEvents
| where Timestamp > ago(30d)
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    ThreatTypes,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Query purposeCreates a readable investigation view that shows sender details, recipient, subject, authentication evidence and delivery outcome.
Why it mattersThis is the first step in turning a suspicious-looking email into evidence you can explain to a user, manager or client.
Best next queryFilter for authentication failures, sender mismatch, repeated subjects or messages that were delivered despite suspicious signals.
How to read this query
Start with SenderFromAddress and Subject, then check AuthenticationDetails and DeliveryAction. The most important question is not only whether something failed. It is whether the message was still trusted or delivered.
Open spoofing guide →

Query: EmailEvents with authentication failures

Use this query to find messages where AuthenticationDetails contains SPF, DKIM, DMARC or spoof-related signals.
emailevents-authentication-failures.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail", "spoof")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Used forFinding messages where authentication signals deserve review, especially when the email still reached the user.
Why it mattersA failed authentication result is useful. A failed result that was delivered is much more important.
Agent Foskett tipDo not stop at dmarc=fail. Ask what the message pretended to be and whether the recipient had a reason to trust it.
How to read this query
Check AuthenticationDetails first, then compare it with DeliveryAction. If the message failed DMARC but was delivered, that is worth reviewing. If the same subject or sender appears across multiple users, it may be a campaign.
Detect DMARC fail emails →

Query: sender alignment in EmailEvents

This query compares the visible From domain with the envelope Mail From domain. Mismatches are not always malicious, but they are a strong investigation starting point.
emailevents-sender-alignment.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction
| order by Timestamp desc
Used forFinding emails where what the user sees and what the mail system processed do not fully align.
Check contextLegitimate services can use different Mail From domains. Check the platform, authentication result, sender reputation and message purpose.
Agent Foskett tipA mismatch is not a verdict. It is a question: should this message have been trusted by the user?
How to read this query
Focus on SenderFromDomain compared with SenderMailFromDomain. Then check whether the message also has authentication failures, a suspicious subject, an unusual sender pattern or successful delivery to multiple users.
Open email spoofing walkthrough →

Query: delivered messages with suspicious authentication

This query narrows the focus to messages that had authentication concerns but still appear to have been delivered or allowed.
emailevents-suspicious-delivered-mail.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail", "spoof")
| where DeliveryAction has_any ("Delivered", "Allowed", "Junked")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    ThreatTypes,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Used forPrioritising messages that reached users despite authentication or spoofing signals.
Why it mattersBlocked mail is useful for reporting. Delivered suspicious mail is useful for response.
Best next queryUse NetworkMessageId to check whether the recipient clicked links or reported the message.
How to read this query
This is a priority view. A message with suspicious authentication and a successful delivery outcome should be reviewed faster than a blocked message. Look for repeated subjects, multiple recipients and any click activity after delivery.
See real spoofing case →

Query: EmailEvents campaign summary

One message may be noise. Repeated subjects, senders and recipients may show a campaign.
emailevents-campaign-summary.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
EmailEvents
| where Timestamp > ago(30d)
| summarize
    MessageCount = count(),
    RecipientCount = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| where MessageCount >= 3
| order by MessageCount desc
Used forGrouping repeated email activity so you can quickly identify possible campaign patterns.
Why it mattersRepeated subjects and senders across recipients can reveal activity that may not appear serious when viewed one email at a time.
Next stepReview the top campaign candidates, then pivot into authentication results and click activity.
How to read this query
Look at MessageCount, RecipientCount, FirstSeen and LastSeen. If the same subject appears across several users in a short window, you may be looking at a phishing or spoofing campaign.
Open complete KQL guide →

Query: pivot from EmailEvents to UrlClickEvents

EmailEvents tells you what was delivered. UrlClickEvents helps you understand whether a user interacted with the message.
emailevents-to-urlclickevents.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let DeliveredMessages =
EmailEvents
| where Timestamp > ago(30d)
| where DeliveryAction has_any ("Delivered", "Allowed", "Junked")
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject;
DeliveredMessages
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(30d)
    | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc
Used forConfirming whether delivered email activity turned into user interaction.
What to reviewReview ClickTime, AccountUpn, URL, ActionType and whether the click happened shortly after delivery.
Best next queryMove from the clicked user into sign-in behaviour, device events and mailbox activity around the same time.
How to read this query
The key pivot is NetworkMessageId. Once you connect a delivered message to a click, the investigation changes. You are no longer only reviewing email risk. You are reviewing user behaviour after exposure.
Review click investigation →

Continue your investigation

This EmailEvents guide is part of the wider Agent Foskett Microsoft Defender and KQL investigation path. Use the links below to move from email evidence into authentication, spoofing, clicks and identity activity.
Email spoofing with KQLInvestigate spoofing indicators, sender mismatch, AuthenticationDetails and suspicious delivery outcomes.

Open spoofing guide →
DMARC failure analysisGo deeper on dmarc=fail, SPF, DKIM, authentication alignment and why failed checks still need context.

Review DMARC failures →
Full KQL threat hunting guideConnect email, identity, endpoint, cloud activity and user behaviour into one investigation workflow.

Open the KQL hub →
Need help investigating Microsoft Defender EmailEvents?
Running a KQL query is one thing. Knowing what matters is another. GEMXIT helps organisations review Microsoft Defender signals, EmailEvents, AuthenticationDetails, suspicious clicks, Sentinel visibility and practical investigation workflows.
Book a Security Review →
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

EmailEvents KQL Guide for Microsoft Defender

Practical Microsoft Defender XDR EmailEvents guide covering sender fields, AuthenticationDetails, DeliveryAction, NetworkMessageId, spoofing indicators, DMARC failures and suspicious email investigation workflows.

EmailEvents AuthenticationDetails DMARC KQL Examples

This page targets practical searches for EmailEvents KQL, AuthenticationDetails, dmarc=fail, SenderFromDomain, SenderMailFromDomain mismatch, email spoofing analysis, URL click pivots and Microsoft Defender email investigation workflows.

GEMXIT Microsoft Security Operations

GEMXIT uses Microsoft Defender, Microsoft Sentinel and Entra ID to support practical security operations, KQL threat hunting, incident response planning and Microsoft 365 security reviews.