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

Microsoft Defender EmailEvents KQL Guide

Looking for EmailEvents KQL queries in Microsoft Defender? This guide gives you copy-ready queries to detect spoofed sender domains, DMARC failures, suspicious delivery behaviour and real-world phishing investigation pivots.

Start with the quick query below, then move through the investigation path: sender identity, AuthenticationDetails, DeliveryAction, NetworkMessageId, URL clicks and user activity.

No theory. Just practical KQL you can use in Microsoft Defender Advanced Hunting.

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 need fast EmailEvents KQL queries for spoofing, DMARC failures, suspicious delivery and click investigation pivots.

Understand key EmailEvents fields
Read AuthenticationDetails correctly
Pivot from delivery to clicks and identity

Quick Answer

EmailEvents is one of the most important Microsoft Defender XDR tables for email investigations. It records sender identity, authentication results, delivery actions, threat indicators and the NetworkMessageId needed to pivot into UrlClickEvents and user activity. If you are investigating phishing, spoofing, DMARC failures or suspicious delivery behaviour, EmailEvents is usually where the investigation begins.

What you'll learn on this page

Use this page as a practical EmailEvents KQL hub for Microsoft Defender XDR email investigations. Start with the quick query, then move through sender identity, authentication, delivery, campaign patterns and click pivots.
1. Quick spoofing queryFind spoof, DMARC, SPF and DKIM signals fast. 2. Understand EmailEventsRead sender, authentication and delivery fields properly. 3. Build the baseline viewProject the core fields used in investigations. 4. Find authentication failuresHunt SPF, DKIM, DMARC and spoof-related evidence. 5. Check sender alignmentCompare visible sender with Mail From path. 6. Pivot to UrlClickEventsUse NetworkMessageId to connect delivery to clicks.

🚀 Quick Query: Detect Spoofed Emails in EmailEvents

If you searched for SpoofedDomain, EmailEvents or DMARC fail, start here. This query gives you a fast view of suspicious authentication and spoofing indicators in Microsoft Defender Advanced Hunting.
quick-detect-spoofed-email-events.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 tostring(AuthenticationDetails) has_any ("spoof", "spoofeddomain", "dmarc=fail", "spf=fail", "dkim=fail")
    or tostring(ThreatTypes) has "spoof"
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    ThreatTypes,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Agent Foskett quick read
Most spoofed emails do not look malicious. They look trusted. This query helps you find where that trust starts to break: authentication results, spoofing language, delivery outcomes and the message ID you need for the next pivot.
Open DMARC fail guide →
🚨 Why EmailEvents matters
EmailEvents is where many Microsoft 365 email investigations start. It shows the visible sender, authentication evidence, delivery outcome and NetworkMessageId needed to pivot into UrlClickEvents. This is how you move from guessing to 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.

EmailEvents Fields You Should Know

These fields appear repeatedly throughout Microsoft Defender email investigations.
FieldWhy it matters
SenderFromAddressThe sender address visible to the user.
SenderMailFromAddressThe SMTP envelope sender used during delivery.
AuthenticationDetailsSPF, DKIM, DMARC and spoofing evidence.
DeliveryActionShows whether the message was delivered, blocked or quarantined.
NetworkMessageIdUsed to pivot into UrlClickEvents and related telemetry.

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 →

EmailEvents investigation workflow

A strong EmailEvents investigation does not stop at one query. Follow the message from sender identity to delivery, click activity and user impact.
1. Start with the messageCapture Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction and NetworkMessageId.
2. Validate authenticationReview AuthenticationDetails for SPF, DKIM, DMARC, spoof and composite authentication signals.
3. Compare sender alignmentCheck SenderFromDomain against SenderMailFromDomain and decide whether the sending pattern makes sense.
4. Prioritise delivered riskFocus first on suspicious messages that reached users or were allowed by policy.
5. Group repeated activityUse summarize to find repeated senders, subjects, recipient spread and campaign windows.
6. Pivot into clicksUse NetworkMessageId to join EmailEvents with UrlClickEvents and check user interaction.

Related Agent Foskett email investigations

These related pages connect this EmailEvents guide to the wider Microsoft 365 email investigation cluster.
Email Spoofing KQL InvestigationInvestigate spoofed email using EmailEvents, AuthenticationDetails and sender alignment. DMARC Failures KQLGo deeper on dmarc=fail, SPF, DKIM, delivery actions and URL click pivots. Detect Delivered DMARC Fail EmailsFocus on DMARC failures that still reached users. SpoofedDomain in EmailEventsUnderstand what SpoofedDomain means and how to investigate it. The Email Came From MeA practical spoofing case where visible identity did not prove mailbox compromise. The User Clicked The Link Three Days LaterFollow email evidence into delayed click activity and user impact.

Learn the KQL behind this guide

These Academy lessons explain the KQL operators used throughout this EmailEvents page.
Microsoft Security TablesUnderstand where EmailEvents, UrlClickEvents and identity data fit. Filtering KQL ResultsUse where clauses to isolate suspicious sender and authentication evidence. Choosing Useful ColumnsProject the fields that matter in email investigations. Using has_anySearch AuthenticationDetails for spoof, dmarc=fail, spf=fail and dkim=fail. Counting and Grouping with summarizeFind repeated senders, subjects and campaign patterns. Connecting Tables with joinJoin EmailEvents to UrlClickEvents using NetworkMessageId.

Frequently asked questions

What is EmailEvents in Microsoft Defender?

EmailEvents is a Microsoft Defender XDR advanced hunting table used to investigate email activity, including sender details, recipient, subject, authentication evidence, delivery action, threat types and message identifiers.

How do I use EmailEvents to detect spoofed email?

Start by filtering AuthenticationDetails and ThreatTypes for spoofing, DMARC, SPF or DKIM failure signals. Then compare SenderFromDomain with SenderMailFromDomain and review DeliveryAction.

Why is NetworkMessageId important?

NetworkMessageId lets you pivot from EmailEvents into UrlClickEvents and other message-related evidence, helping you determine whether a delivered email led to user interaction.

What should I check after a suspicious email is delivered?

Check URL clicks, sign-ins, mailbox activity, device telemetry and whether similar messages reached other users. Delivered suspicious email is where exposure and response decisions begin.

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 KQL Investigate spoofing indicators, sender mismatch, AuthenticationDetails and suspicious delivery outcomes.

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

Review DMARC failures →
Full KQL threat hunting guide The investigation doesn’t start with alerts — it starts with understanding the data.

AuthenticationDetails reveals what really happened behind email delivery and user trust.

Understand authentication →

Open the full investigation guide →
Sender mismatch detection EmailEvents reveals both SenderFrom and SenderMailFrom — and they don’t always match.

Understanding this difference is critical for detecting spoofed emails.

Learn sender mismatch →
AuthenticationDetails Explained Learn how to analyse EmailEvents in Microsoft Defender — including sender details, authentication results, delivery behaviour and how spoofing activity appears in real data.
Start with the email story Look at the subject, message tone and intent. Crypto scams rely on urgency, rewards and user action — not exploits.

This investigation shows how a simple email can lead to wallet access and user-approved compromise.
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