ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Microsoft Defender • DMARC Fail • EmailEvents • KQL

Detect DMARC Fail Emails in Microsoft Defender

The email looked normal.

The sender looked familiar.

But the authentication data told a different story: DMARC failed.

This Agent Foskett guide shows how to use Microsoft Defender KQL, EmailEvents and AuthenticationDetails to find DMARC failures, check whether the email was delivered, and decide where to pivot next.

Discuss your environment Back to briefings
Detect DMARC fail emails in Microsoft Defender with KQL by Agent Foskett
Guide summary

This page focuses on one high-value email investigation signal: DMARC failures inside Microsoft Defender XDR.

Find dmarc=fail in AuthenticationDetails
Check delivery action and user exposure
Pivot into spoofing, campaigns and URL clicks
🧠 Looking for this?
If you searched for "dmarc=fail" "EmailEvents", "AuthenticationDetails" "dmarc=fail", or Microsoft Defender DMARC fail KQL, you are in the right place.

This page is built to answer one question quickly: how do you find and interpret DMARC failures in Microsoft Defender?
View KQL hub →

Why DMARC fail matters

DMARC fail does not automatically mean a mailbox has been compromised. It means the trust story needs to be checked. Sometimes it is spoofing. Sometimes it is a misconfigured third-party sender. Sometimes it is a message that should never have been delivered.
The sender may look trusted The visible From address can feel familiar to the user, even when the underlying authentication result is warning you to look closer.
Delivery action matters A failed authentication result is more interesting when the message was delivered, allowed, or reached users before it was investigated.
Patterns reveal campaigns One DMARC failure is a signal. Repeated failures across users, senders or subjects can reveal a phishing or spoofing campaign.

Start with DMARC failures in EmailEvents

This query looks for messages where Microsoft Defender recorded DMARC failure inside AuthenticationDetails. It keeps the key investigation fields visible: sender, recipient, subject, delivery action and authentication details.
dmarc-fail-emailevents.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 AuthenticationDetails has "dmarc=fail"
| project
          Timestamp,
          SenderFromAddress,
          SenderFromDomain,
          SenderMailFromDomain,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          ThreatTypes,
          AuthenticationDetails
| order by Timestamp desc
How to read this query
  • AuthenticationDetails tells you the authentication result recorded by Defender.
  • DeliveryAction tells you what happened to the message after evaluation.
  • SenderFromDomain and SenderMailFromDomain help you compare what the user sees with the underlying sending path.

👉 If DMARC failed and the email was delivered, that is where the investigation should start.

Find DMARC fail emails that were delivered

A DMARC failure is useful. A DMARC failure that still reached the user is higher interest. This query narrows the view to delivered messages so you can quickly review exposure.
dmarc-fail-delivered.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
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| where DeliveryAction has "Delivered"
| project
          Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          AuthenticationDetails,
          NetworkMessageId
| order by Timestamp desc
Used for Finding authentication failures that reached users and may need mailbox review, user follow-up or click investigation.
What to check Review the sender, subject, recipient, message timing, links, attachments and whether the same pattern hit other users.
Best pivot Use NetworkMessageId to investigate URL clicks, message details and related activity around the same email.

Compare visible sender and mail-from domain

DMARC depends on alignment. When the visible sender domain and the mail-from domain do not line up, the message needs context. It may be legitimate third-party sending, or it may be spoofing.
dmarc-fail-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 AuthenticationDetails has "dmarc=fail"
| where SenderFromDomain != SenderMailFromDomain
| project
          Timestamp,
          SenderFromAddress,
          SenderFromDomain,
          SenderMailFromDomain,
          RecipientEmailAddress,
          Subject,
          DeliveryAction,
          AuthenticationDetails
| order by Timestamp desc
How to read this query
  • SenderFromDomain is the domain the user is likely to notice.
  • SenderMailFromDomain helps reveal the sending path behind the message.
  • A mismatch is not always malicious, but it should make sense for that sender and message type.

👉 The key question is not just “are these different?” It is “does this difference make sense?”

Group DMARC failures into patterns

One failed message may be noise. Multiple failed messages with the same sender, domain or subject can become a campaign pattern. This query helps turn individual events into a useful summary.
dmarc-fail-campaign-patterns.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
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| 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 for Finding repeated DMARC failures across subjects, senders, recipients and delivery outcomes.
Why it matters Repeated failed-authentication emails may indicate spoofing, phishing, misconfigured senders or an active campaign.
Response decision Decide whether the response is one mailbox review, tenant-wide search, user communication, allow/block tuning or sender validation.

Pivot from DMARC fail to URL clicks

If a DMARC fail email contained a link, the next question is simple: did anyone click? This query joins suspicious messages to URL click activity using NetworkMessageId.
dmarc-fail-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
let DMARCFailMessages =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject;

DMARCFailMessages
| join kind=inner (
          UrlClickEvents
          | where Timestamp > ago(30d)
          | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc
How to read this query
  • NetworkMessageId connects the email event to click telemetry.
  • ActionType helps show whether the click was allowed, blocked or scanned.
  • The clicked URL, account and timestamp become the starting point for identity and endpoint pivots.

👉 A DMARC fail email becomes more urgent when a user clicked the link.

🚨 What this means for your environment
DMARC fail is not the end of the investigation. It is the start of one.

• Was the email delivered?
• Did the sender domain make sense?
• Was the same subject sent to multiple people?
• Did anyone click?
• Should policy, allow lists, third-party senders or user awareness be reviewed?

👉 This is exactly the type of evidence GEMXIT reviews during Microsoft 365 security and email threat hunting assessments.
Book a security review →

Agent Foskett investigation checklist

Use this checklist when DMARC failures appear in Microsoft Defender. The goal is not just to find failed authentication. The goal is to understand risk, exposure and response.
Review the message Check sender, recipient, subject, timestamps, authentication result, delivery action, links and attachments.
Look for patterns Group by sender, domain, subject and recipient count. Repeated activity changes the response decision.
Pivot with purpose Move from email to click, from click to sign-in, and from sign-in to user and device activity if needed.

Continue hunting

This page is part of the Agent Foskett Microsoft Defender KQL threat hunting series. Use it as a focused DMARC failure page, then link back into the broader KQL hub and spoofing pages.
KQL Threat Hunting Guide Return to the main Microsoft Defender KQL hub for broader hunting examples.
Email spoofing guide Deep dive into spoofed sender analysis, sender alignment and EmailEvents investigation.

If you want help improving Microsoft Defender hunting, alert investigation and security visibility, 👉 review Microsoft Defender services

Develop IT. Protect IT. GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Detect DMARC Fail Emails in Microsoft Defender

This guide explains how GEMXIT uses Microsoft Defender XDR and KQL to find DMARC fail emails using EmailEvents and AuthenticationDetails.

EmailEvents AuthenticationDetails DMARC Fail KQL

Practical KQL examples include dmarc=fail filtering, delivered DMARC fail email review, sender alignment analysis, campaign pattern detection and URL click investigation pivots.

Microsoft 365 Email Security and Threat Hunting

GEMXIT uses Microsoft Defender, Sentinel, Entra ID and KQL to support Microsoft 365 security operations, email investigation and practical threat hunting.