ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Microsoft Defender • EmailEvents • AuthenticationDetails • KQL

Detect Email Spoofing in Microsoft Defender

Most spoofed emails do not start with a dramatic alert. They often look ordinary, familiar and technically boring.

This guide shows how to detect email spoofing in Microsoft Defender XDR using EmailEvents, AuthenticationDetails, DMARC, SPF, DKIM, sender alignment, delivery actions and URL click pivots.

It is built for practical investigation: what was sent, who received it, whether it was delivered, whether anyone clicked, and what to check next.

Discuss your environment Back to briefings
Detect email spoofing in Microsoft Defender with KQL by GEMXIT
Email spoofing investigation summary

A focused Microsoft Defender KQL resource for finding spoofed sender domains, failed authentication, suspicious delivery outcomes and click activity.

EmailEvents and AuthenticationDetails
DMARC, SPF, DKIM and sender alignment
Delivery action, campaign and URL click pivots
🚨 Why this matters
Spoofing is dangerous because it abuses trust. The attacker may not need a password, malware or a vulnerability. They only need the recipient to believe the message long enough to click, approve, reply or pay.

👉 Develop IT. Protect IT. GEMXIT.

👉 Explore our broader Microsoft security operations approach.
Book an email security review →

What this guide helps you detect

Email spoofing investigations should not stop at one field or one alert. The goal is to build the full story across authentication, delivery and user behaviour.
Spoofed sender domainsMessages where the visible sender appears trusted, but the underlying sending domain, authentication result or alignment does not make sense.
Authentication failuresDMARC, SPF and DKIM results hidden inside AuthenticationDetails that help explain why trust broke.
User exposureDelivered messages, URL clicks and post-delivery activity that turn email investigation into real business risk.

Start here: find authentication failures in EmailEvents

This query finds email where SPF, DKIM or DMARC failed. It gives you the core fields needed to compare the visible sender, envelope sender, recipient, subject, authentication result and delivery action.
email-spoofing-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
  19. 19
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    ThreatTypes,
    NetworkMessageId
| order by Timestamp desc
What this findsMessages where authentication results suggest spoofing, forwarding issues or misaligned sending services.
Why it mattersThe visible sender may look legitimate even when authentication and alignment tell a different story.
Best pivotCheck DeliveryAction first, then pivot to URL clicks and sign-in behaviour.

Agent Foskett mindset: do not just ask whether something failed

A single failed authentication result does not always mean compromise. Real threat hunting asks whether the whole behaviour makes sense.
Don’t ask onlyDid DMARC, SPF or DKIM fail?
Ask insteadWas it delivered, who received it, did anyone click, and does the sender relationship make sense?
Follow behaviourMessage → recipient → click → sign-in → device → mailbox action.

Find DMARC failures specifically

DMARC failures are one of the strongest signals for spoofing or sender alignment problems. Start here when your investigation focuses on dmarc=fail results inside AuthenticationDetails.
dmarc-failures-authenticationdetails.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
  19. 19
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    ThreatTypes,
    NetworkMessageId
| order by Timestamp desc

👉 Related deep dive → DMARC failures explained with KQL.

Find delivered spoofing risk

A failed authentication result that was blocked is useful. A failed authentication result that was delivered is more important, because a user may have seen or interacted with it.
delivered-spoofing-risk.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 ("dmarc=fail", "spf=fail", "dkim=fail")
| where DeliveryAction !in~ ("Blocked", "Quarantined", "Junked")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
What to reviewDelivered messages from suspicious or unfamiliar sender domains.
High interest signalDMARC fail + Delivered + trusted-looking sender name.
Next movePivot into URL clicks using NetworkMessageId.

Compare visible sender and envelope sender

Spoofing investigations often come down to sender alignment. The address the user sees may not match the domain that actually sent the email.
sender-alignment-review.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 SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Visible senderSenderFromAddress and SenderFromDomain are what users often recognise.
Envelope senderSenderMailFromAddress and SenderMailFromDomain help reveal the underlying sending path.
Analyst noteMismatch is not automatically malicious, but it is worth validating for trusted brands and internal-looking messages.

Group suspicious messages into patterns

One message can be noise. Repeated messages from the same sender, domain or subject can reveal campaigns, impersonation attempts or broken third-party sender configuration.
spoofing-patterns-by-domain-subject.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
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail", "dkim=fail")
| summarize
    MessageCount = count(),
    RecipientCount = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromDomain, SenderMailFromDomain, Subject, DeliveryAction
| order by MessageCount desc
Used forTurning individual suspicious messages into campaign-level patterns.
Look forRepeated subject lines, multiple recipients, recent first seen dates and delivered outcomes.
Next pivotOpen representative messages, then check click and sign-in activity.

Pivot spoofed emails to URL clicks

If a user clicked a link from a spoofed or authentication-failed email, the investigation changes. You are no longer only checking email hygiene; you are checking possible impact.
spoofed-email-to-url-clicks.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
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
let SuspiciousEmails =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail", "dkim=fail")
| project
    NetworkMessageId,
    EmailTime = Timestamp,
    SenderFromAddress,
    RecipientEmailAddress,
    Subject,
    DeliveryAction;
SuspiciousEmails
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(30d)
    | project
        NetworkMessageId,
        ClickTime = Timestamp,
        AccountUpn,
        Url,
        ActionType
) on NetworkMessageId
| order by ClickTime desc
What this provesWhether a suspicious email moved from inbox exposure to user interaction.
Review carefullyAllowed clicks, repeated clicks, suspicious URL domains and time between delivery and click.
After a clickCheck Entra ID sign-ins, device activity and mailbox rules around the same time.

👉 If clicks are present, continue → check identity activity after interaction.

Check whether spoofing was already classified

Microsoft Defender may already classify some messages with threat types. This query helps you compare explicit spoofing classifications with authentication details and delivery outcomes.
threattypes-spoof-review.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)
| where ThreatTypes has_any ("Spoof", "Phish") or AuthenticationDetails has "dmarc=fail"
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    RecipientEmailAddress,
    Subject,
    ThreatTypes,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc

What to do after you find spoofing

Detection is only useful if it leads to action. The right response depends on whether the issue is malicious spoofing, a legitimate third-party sender problem, or a delivered message that users interacted with.
Fix sender alignmentReview SPF, DKIM and DMARC alignment for approved third-party senders and business platforms.
Investigate exposureIdentify recipients, delivered messages, clicks, sign-ins and any unusual mailbox behaviour.
Improve postureTighten DMARC policy, improve Defender policies and build repeatable hunting queries for your SOC workflow.

Continue your investigation

Use this page as the central guide, then branch into the more detailed Agent Foskett investigations below.
DMARC failures explainedInvestigate dmarc=fail results, delivery actions and URL click pivots in Microsoft Defender.
Full KQL threat hunting guideFollow the broader investigation path across email, identity, endpoint and cloud signals.
EmailEvents investigation guideUnderstand sender details, authentication results and delivery behaviour inside EmailEvents.
Identity and session checksCheck sign-in behaviour after suspicious delivery or clicks.

Related case study → The email came from me… but I never sent it.

Need help detecting spoofed emails in your Microsoft 365 environment?
GEMXIT helps organisations review Microsoft 365 email security, Defender signals, DMARC alignment, Sentinel visibility and practical threat hunting workflows.
Book a Security Review →
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Detect Email Spoofing in Microsoft Defender

Practical Microsoft Defender KQL guide for detecting email spoofing using EmailEvents, AuthenticationDetails, DMARC failures, SPF, DKIM, sender alignment, delivery actions and URL click pivots.

EmailEvents SpoofedDomain AuthenticationDetails KQL

This page targets technical searches around spoofeddomain, EmailEvents, AuthenticationDetails, dmarc=fail, SenderFromAddress, SenderMailFromDomain, Microsoft Defender XDR and Microsoft 365 email security investigations.

GEMXIT Microsoft Security Threat Hunting

GEMXIT helps organisations investigate email spoofing, Microsoft Defender signals, Sentinel hunting, Entra ID sign-ins, DMARC alignment and practical security operations.