ACSC Logo
© 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 →

What you'll learn on this page

This page is focused on one practical Defender XDR question: which DMARC failures were delivered, and what should an analyst check next?
1. Why DMARC fail mattersUnderstand why dmarc=fail is a signal, not the final answer. 2. Start with EmailEventsFind dmarc=fail inside AuthenticationDetails. 3. Find delivered failuresPrioritise failures that reached users. 4. Compare sender alignmentReview visible sender vs Mail From domain. 5. Group campaign patternsSummarise repeated subjects, senders and recipients. 6. Pivot to URL clicksUse NetworkMessageId to see whether users clicked.

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.

Delivered DMARC failure decision path

Once you find a delivered dmarc=fail message, use this investigation path to decide whether it is misconfiguration, tolerated third-party sending, or a real phishing/spoofing risk.
1. Confirm dmarc=failStart in EmailEvents and confirm the failure appears in AuthenticationDetails.
2. Confirm deliveryCheck DeliveryAction so you can separate blocked or quarantined messages from user exposure.
3. Validate sender alignmentCompare SenderFromDomain and SenderMailFromDomain, then check whether the sender is legitimate.
4. Check repetitionGroup by sender, subject, recipient count and delivery action to see whether this is a campaign.
5. Pivot into clicksUse NetworkMessageId to join EmailEvents to UrlClickEvents and confirm interaction.
6. Decide responseReview allow lists, sender configuration, DMARC policy, user notifications and follow-on identity checks.

Related Agent Foskett investigations

These pages connect this delivered DMARC failure guide to the broader Microsoft 365 email investigation cluster.
DMARC Failures KQLThe broader DMARC investigation guide covering SPF, DKIM, DMARC, delivery and click pivots. Email Spoofing KQL InvestigationInvestigate suspicious email using EmailEvents, AuthenticationDetails and sender alignment. The DMARC Failure Nobody InvestigatedA case-style investigation showing why ignored DMARC failures can matter. The Email Came From MeUnderstand self-addressed spoofing and why a familiar sender does not prove trust. The Email Passed SPF But Was Still MaliciousSee why SPF alone is not enough and why the full sender story matters. The User Clicked The Link Three Days LaterFollow email delivery into delayed user click activity and impact analysis.

Learn the KQL behind this page

These Academy lessons support the operators used in this investigation and help analysts build confidence with the query patterns.
Filtering KQL ResultsUse where filters to find dmarc=fail, Delivered actions and suspicious sender patterns. Using has_anySearch AuthenticationDetails for SPF, DKIM and DMARC failure strings. Choosing Useful ColumnsProject the fields that matter: sender, recipient, subject, delivery action and message ID. Counting and Grouping with summarizeTurn single email events into sender and campaign patterns. Connecting Tables with joinJoin EmailEvents to UrlClickEvents using NetworkMessageId. Building Investigation TimelinesFollow a delivered message into click, sign-in and endpoint evidence.

Frequently asked questions

How do I find DMARC fail emails in Microsoft Defender?

Use the EmailEvents table and filter AuthenticationDetails for dmarc=fail. Then project sender, recipient, subject, DeliveryAction and NetworkMessageId so you can decide what to investigate next.

Why focus on delivered DMARC fail emails?

Delivered DMARC failures may have reached users. That makes them higher priority than messages that were already blocked, quarantined or junked before user exposure.

Does dmarc=fail mean the email is malicious?

No. It may be spoofing, forwarding, a third-party sender alignment issue or a misconfiguration. The analyst needs to review delivery action, sender alignment, message content, recipient spread and user clicks.

How do I check whether a DMARC fail email was clicked?

Use NetworkMessageId to join EmailEvents with UrlClickEvents. Then review AccountUpn, Url, ActionType and ClickTime to see whether a user interacted with the message.

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 follow the investigation into authentication, EmailEvents, spoofing and broader analysis.
AuthenticationDetails explained Detecting DMARC failures is only the first step.

AuthenticationDetails explains whether SPF, DKIM and DMARC actually aligned — and why an email may still have been delivered.

Understand authentication signals →
EmailEvents investigation guide Understand how EmailEvents reveals sender details, authentication results and delivery behaviour behind DMARC failures.

Open EmailEvents guide →
Email spoofing guide Deep dive into spoofed sender analysis, sender alignment and EmailEvents investigation.

Review spoofing guide →
KQL Threat Hunting Guide Return to the main Microsoft Defender KQL hub for broader hunting examples across email, identity, endpoint and cloud activity.

Open KQL hub →
Microsoft Defender services Need 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

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.