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

DMARC Failures Explained with KQL

DMARC failures can look scary at first glance, but they do not always mean a mailbox has been compromised.

This page explains how to investigate DMARC failures in Microsoft Defender XDR using EmailEvents, AuthenticationDetails, sender alignment, delivery actions and URL click pivots.

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

Discuss your environment Back to briefings
DMARC failures explained with KQL in Microsoft Defender by GEMXIT
DMARC investigation summary

A focused Microsoft Defender KQL resource for investigating dmarc=fail results, sender alignment issues, delivery decisions and click activity.

EmailEvents and AuthenticationDetails
DMARC, SPF and DKIM failure checks
Delivery, campaign and URL click pivots
🚨 What this means for your environment
Even if you're not actively monitoring this:

• DMARC failures may already be occurring across your domain
• Emails may be bypassing authentication controls and still being delivered
• Your organisation may be vulnerable to impersonation or phishing campaigns

👉 This is exactly what we uncover during Microsoft 365 email security and DMARC assessments

👉 Or explore how we approach Microsoft security operations
Book a DMARC & email security review →

How to read DMARC failures (what actually matters)

A DMARC failure on its own does not tell the full story. What matters is how that failure behaves in your environment: whether it was delivered, who received it, whether the sender alignment makes sense, and whether anyone interacted with the message.
High risk signals DMARC fail + Delivered
Internal-looking sender
Multiple recipients or repeated subjects
Common false positives Third-party senders
Forwarded mail breaking alignment
Mailing platforms using separate sending domains
What to do next Check delivery action
Pivot to URL clicks
Review sign-ins and user behaviour

Start with DMARC failures in EmailEvents

Start here when Microsoft Defender shows a DMARC failure in AuthenticationDetails. This gives you the sender, recipient, subject, delivery action and message ID needed to decide whether the event is normal third-party sending, a misconfiguration, or a spoofing attempt.
dmarc-failures-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
  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
What this finds Messages where DMARC failed and the sender identity deserves review.
Why it matters DMARC failure is a trust signal problem. It may be spoofing, forwarding, or a sending service that is not aligned correctly.
Best pivot Check whether the message was delivered, who received it, and whether anyone clicked.

How to read this query

Running the query is only the first step. The real value comes from understanding how authentication, delivery and user behaviour connect.
What to look for DMARC fail + Delivered = high interest
SenderFromDomain ≠ SenderMailFromDomain
Repeated subject across users = campaign signal
What normal can look like Trusted services failing alignment
Forwarded mail breaking authentication
Blocked or quarantined failures already handled
Investigation flow Message → Recipient → Click → Sign-in
Always follow the behaviour, not just the alert

👉 Next step → Compare with full spoofing patterns or continue into the full KQL threat hunting guide.

Compare DMARC, SPF and DKIM failures

DMARC depends on sender alignment and authentication results. Looking at SPF, DKIM and DMARC together gives a clearer picture than chasing one word in the AuthenticationDetails field.
spf-dkim-dmarc-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
  20. 20
  21. 21
  22. 22
  23. 23
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail")
| extend
    SPF_Fail = iff(AuthenticationDetails has "spf=fail", "Yes", "No"),
    DKIM_Fail = iff(AuthenticationDetails has "dkim=fail", "Yes", "No"),
    DMARC_Fail = iff(AuthenticationDetails has "dmarc=fail", "Yes", "No")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    SPF_Fail,
    DKIM_Fail,
    DMARC_Fail,
    AuthenticationDetails,
    DeliveryAction
| order by Timestamp desc
Used for Separating full authentication failure from partial failure or sender alignment issues.
What to review Look at visible sender, envelope sender, DKIM result, SPF result and final delivery action.
Agent Foskett tip Do not assume compromise from one failed check. Use the whole authentication story.

Find delivered messages where DMARC failed

A DMARC failure that was blocked or quarantined is one thing. A DMARC failure that was delivered deserves closer attention, especially if the sender name or subject looks trusted.
delivered-dmarc-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 "dmarc=fail"
| where DeliveryAction !in~ ("Blocked", "Quarantined", "Junked")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
What this finds DMARC failures that may have still reached users.
Why it matters Delivered failures create user exposure. This is where business risk starts to matter.
Best next step Pivot to URL clicks, user sign-ins and mailbox activity around the same time.

👉 Next step → Compare delivered DMARC failures with full spoofing patterns.

Group DMARC failures by sender domain

One failed message may be noise. Repeated DMARC failures from the same sender domain, subject or delivery pattern may indicate a campaign, broken sender configuration, or impersonation pattern.
dmarc-failures-by-domain.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 "dmarc=fail"
| summarize
    MessageCount = count(),
    RecipientCount = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromDomain, SenderMailFromDomain, Subject, DeliveryAction
| order by MessageCount desc
Used for Turning single DMARC failures into patterns across domains, subjects and recipients.
Why it matters Patterns help separate background mail noise from targeted spoofing or a broken sender.
Best pivot Review top sender domains, then inspect sample messages and delivery outcomes.

Pivot DMARC failures to URL clicks

If a message failed DMARC and a user clicked a URL from that message, the investigation moves from email hygiene to possible impact.
dmarc-failure-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 DMARCFailures =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction;
DMARCFailures
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(30d)
    | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc
Used for Confirming whether a DMARC-failed message led to user interaction.
What to review Allowed clicks, blocked clicks, repeated clicks, suspicious domains and timing after delivery.
Best next step Move from the user and timestamp into sign-ins, device activity and mailbox actions.
Want the full spoofing investigation path?
See the Microsoft Defender email spoofing guide for sender alignment, spoofed domain checks and click pivots.
View Spoofing Guide

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

What to do after a DMARC failure

Once you understand the pattern, the next step is response. That might mean fixing SPF/DKIM alignment, adjusting a third-party sender, tightening DMARC policy, hunting for clicks, or communicating with users if a delivered message created risk.
Fix alignment Check SPF, DKIM and DMARC alignment for approved third-party senders.
Investigate exposure Review delivered messages, affected recipients, URL clicks and any unusual sign-in activity.
Improve posture Move toward stronger DMARC enforcement when reporting and legitimate sender alignment are under control.

Continue your investigation

DMARC failures are only one part of the investigation. These pages take you deeper into real-world Microsoft Defender, Sentinel and identity analysis.
Email spoofing detection Use KQL to compare sender alignment, spoofing indicators and click activity.
Full KQL threat hunting guide Follow the broader investigation path across email, identity, endpoint and cloud signals.
Identity and session checks Check sign-in behaviour after suspicious delivery or clicks.
EmailEvents investigation guide Understand how EmailEvents reveals sender details, authentication results and delivery behaviour behind DMARC failures.
Detect Email Spoofing (Full Guide) Learn how to detect spoofed emails in Microsoft Defender using real KQL queries — including EmailEvents, AuthenticationDetails, DMARC failures and user click analysis.

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

Need help investigating DMARC failures in your environment?
Running the query is one thing. Knowing what matters is another. GEMXIT helps organisations review Microsoft 365 email security, Defender signals, DMARC alignment and practical threat hunting workflows.
Book a Security Review →
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

DMARC Failures Explained with KQL

Copy-paste KQL queries for investigating dmarc=fail results in Microsoft Defender XDR using EmailEvents and AuthenticationDetails.

AuthenticationDetails DMARC Fail EmailEvents

This page targets technical searches around AuthenticationDetails, dmarc=fail, EmailEvents, Microsoft Defender, sender alignment and URL click investigation.

GEMXIT Microsoft Security

GEMXIT uses Microsoft Defender, Sentinel and Entra ID to support practical security operations, DMARC reviews, email spoofing investigations, threat hunting and response planning.