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

What you'll learn on this page

Use this as a practical DMARC investigation workflow for Microsoft Defender XDR. Start with dmarc=fail evidence, understand alignment, then decide whether the message created business risk.
1. Read the DMARC failure correctly Understand what matters beyond the dmarc=fail text. 2. Query EmailEvents Find DMARC failures using AuthenticationDetails. 3. Compare SPF, DKIM and DMARC Separate alignment problems from real spoofing risk. 4. Find delivered failures Prioritise messages that reached users. 5. Group by sender domain Turn single events into patterns and campaigns. 6. Pivot to UrlClickEvents Check whether a failed message became user interaction.

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.

DMARC failure investigation workflow

A good DMARC investigation follows the behaviour from authentication failure to delivery, user exposure and possible impact.
Step 1: Confirm the failure Use EmailEvents and AuthenticationDetails to confirm whether DMARC, SPF or DKIM failed.
Step 2: Check alignment Compare SenderFromDomain and SenderMailFromDomain, then review whether the sender is an approved third-party platform.
Step 3: Review delivery action Prioritise messages that were delivered, allowed, or visible to users over messages already blocked or quarantined.
Step 4: Look for campaign patterns Group by sender, subject, delivery action and recipient count to identify repeated targeting.
Step 5: Pivot to clicks Join EmailEvents with UrlClickEvents using NetworkMessageId to see whether a user interacted with the message.
Step 6: Decide response Fix sender alignment, tune email controls, notify users, investigate identity activity, or escalate if interaction occurred.

Related Agent Foskett investigations

These pages connect this DMARC failure guide to the broader Microsoft 365 email investigation cluster.
Email Spoofing KQL Investigation Investigate suspicious email in Microsoft 365 using EmailEvents, AuthenticationDetails and sender alignment. Detect DMARC Fail Emails Focus on dmarc=fail messages in Defender and what analysts should check next. The DMARC Failure Nobody Investigated A practical case-style investigation showing why ignored authentication failures matter. The Email Came From Me A spoofing scenario where the visible sender looked trusted but the evidence told another story. The Email Passed SPF But Was Still Malicious Shows why SPF alone is not enough and why the full sender story matters. The User Clicked The Link Three Days Later Follow the message after delivery into delayed user click activity.

Learn the KQL behind this DMARC investigation

These Academy lessons support the operators and investigation techniques used throughout this page.
What is KQL? Understand how KQL helps investigators ask better questions of Defender data. Filtering KQL Results Use where filters to reduce noise and focus on dmarc=fail evidence. Using has_any Find SPF, DKIM and DMARC failure strings inside AuthenticationDetails. Creating Evidence Fields with extend Build readable fields such as SPF_Fail, DKIM_Fail and DMARC_Fail. Counting and Grouping with summarize Group DMARC failures by sender domain, subject and delivery action. Connecting Tables with join Join EmailEvents to UrlClickEvents when a delivered failure may have been clicked.

Frequently asked questions

What does dmarc=fail mean in Microsoft Defender?

It means the message did not pass DMARC evaluation in the authentication details. That may indicate spoofing, sender misalignment, forwarding, or a third-party service that is not correctly aligned.

Does DMARC fail mean the email is malicious?

No. A DMARC failure is a signal that needs investigation. Analysts should review sender alignment, delivery action, message content, recipient spread and user interaction before deciding impact.

Which Defender table shows DMARC failures?

EmailEvents is the usual starting point. The AuthenticationDetails field can contain SPF, DKIM and DMARC results, while DeliveryAction and NetworkMessageId help with response and pivots.

Why are delivered DMARC failures important?

A blocked or quarantined failure may already be contained. A delivered DMARC failure may have reached a user, which means you should check clicks, sign-ins, mailbox activity and campaign patterns.

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

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.