ACSC Logo
© 2026 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 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.

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 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 →
EmailEvents Investigation Guide 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 2026