KQL Query Library • Defender XDR • Email Security

Microsoft Defender Email Security KQL Queries

This page is built as a hands-on KQL resource. It is not written as a story. It is designed as a practical set of Microsoft Defender XDR queries you can copy, run, adapt and understand. Use it when you need to analyse email authentication, sender alignment, delivery outcomes, repeated targeting and URL click behaviour across your Microsoft 365 environment.

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

Discuss your environment Back to briefings

Detect Email Spoofing in Microsoft Defender with KQL by GEMXIT

Query library summary

A practical query library for analysts and administrators who want reusable Microsoft Defender KQL examples for EmailEvents, AuthenticationDetails, sender alignment and URL click analysis.

Reusable EmailEvents query patterns

Sender alignment comparison queries

Authentication and click investigation pivots

🚨 Why these queries are useful
When you need to move quickly: • Start with authentication and delivery evidence • Compare visible sender details with logged sender values • Pivot from suspicious messages into users, URLs and timing 👉 These are practical investigation building blocks for Microsoft 365 email security 👉 Or explore how we approach Microsoft security operations

Book an email security review →

How to read these KQL queries

These queries are not just for copying and pasting. The real value comes from understanding what the data is showing, what looks normal, and what deserves investigation.

1. Start with the table EmailEvents tells the email delivery story. UrlClickEvents tells you whether a user interacted. The table tells you what kind of evidence you are looking at.

2. Look for the anomaly Delivered mail with failed authentication, sender mismatch, repeated subject lines, or unusual click timing is where the investigation starts to matter.

3. Pivot, do not guess Good hunting does not stop at one result. Move from the message to sender alignment, user clicks, recipient spread and sign-in behaviour.

Baseline query: authentication and spoofing indicators

Use this as your first reusable query when you want to surface authentication failures, spoof indicators and delivery outcomes from Microsoft Defender XDR EmailEvents.

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,
    ThreatTypes,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc

Query purpose Surfaces messages where authentication, spoofing or sender trust signals need review before you decide the next action.

Why it matters Repeated subjects, senders and recipient spread can show that this is not a single suspicious email. It may be an active campaign.

Best next query Move from the message into sender alignment, URL activity, recipient spread and the surrounding timeline.

Query: visible sender versus envelope sender

The visible From address is what the user sees. The Mail From sender is part of the delivery path. Mismatches are not always malicious, but they are worth checking.

EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction
| order by Timestamp desc

Used for Use this query when you want to separate one-off noise from a repeated phishing or spoofing campaign across multiple recipients.

Check context Sender mismatch needs context. Review the domain, delivery action, subject, authentication detail and whether users interacted with the message.

Agent Foskett tip Do not stop at a mismatch. Ask what the message pretended to be, who received it and whether it caused action.

Query: repeated sender and subject patterns

One strange message is interesting. Repeated sender, subject or authentication patterns across recipients may indicate a campaign.

EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail", "spoof")
| summarize
    MessageCount = count(),
    RecipientCount = dcount(RecipientEmailAddress)
    by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| where MessageCount >= 3
| order by MessageCount desc

Used for Use this query when a message looks legitimate but the visible sender and envelope sender do not tell the same story.

Why it matters A failed authentication signal becomes more important when the message was delivered, looked internal, or reached multiple users.

Next step Group by recipient count, subject and sender, then review URL clicks or user reports tied to the same campaign window.

Query: URL click investigation after delivery

A suspicious email becomes more serious when a user clicked. This query joins suspicious messages to UrlClickEvents using NetworkMessageId.

let SuspiciousMessages =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail", "spoof")
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject;
SuspiciousMessages
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(30d)
    | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc

Used for Use this query when you need to confirm whether a suspicious delivered email turned into user interaction.

What to review Look for unfamiliar domains, repeated clicks, unusual timing and any user who clicked shortly after delivery.

Best next query Move from the clicked user into sign-in activity, device events and mailbox activity around the same time window.

How to read this query
The important fields are ClickTime, AccountUpn, Url and ActionType. A suspicious message becomes a higher priority when the URL was allowed, clicked more than once, or followed by unusual sign-in behaviour.

👉 To understand how this ties back to the original email data, start with the EmailEvents KQL Guide and follow the full investigation path.

Check sign-in pivots →

Continue your investigation

This page is one part of the wider Agent Foskett KQL and Microsoft Security investigation path. Use the links below to move from email evidence into broader threat hunting.

Full KQL threat hunting guide Connect email, identity, endpoint, cloud activity and user behaviour into one investigation workflow.

Open the KQL hub →

DMARC failure analysis Go deeper on dmarc=fail, authentication alignment and why some failed messages still need review.

Review DMARC failures →

Authentication signals Before following identity activity, it’s important to understand how the email was trusted in the first place.

AuthenticationDetails reveals whether DMARC, SPF and DKIM actually aligned — even when the email was delivered.

Understand authentication →

Session and identity pivots When a user interacts with an email, the next question is whether the identity activity still makes sense.

Review sign-ins, session reuse and location patterns to confirm the activity matches the user.

Review session hijacking →

User behaviour and data access If access continues, the final step is to validate behaviour.

Look for unusual file activity, after-hours access and patterns that don’t align with the user.

Investigate after-hours file access →

Detect Email Spoofing (Full Investigation Guide) Follow a complete real-world investigation using Microsoft Defender — from spoofed emails and DMARC failures through to user clicks, identity pivots and full attack path visibility.