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

DMARC Failed… But the Email Was Delivered

The email looked legitimate. The sender felt familiar. No high-severity alert appeared.

But something did not add up.

Behind the scenes, DMARC had failed. Authentication did not align. The message should have raised concern.

Yet it was still delivered.

This Agent Foskett investigation shows how to use Microsoft Defender XDR and KQL to uncover delivered DMARC failures, sender mismatch and spoofing behaviour that can hide behind normal-looking email delivery.

The goal is simple: stop assuming “delivered” means safe.

Discuss your environment Back to briefings
DMARC failed but email delivered investigation using Microsoft Defender KQL by GEMXIT
DMARC delivery summary

A practical Microsoft Defender investigation focused on email that failed DMARC but still reached users, showing how AuthenticationDetails, sender alignment and delivery outcome need to be read together.

Detect delivered DMARC failures
Review sender mismatch and spoofing signals
Pivot from delivery to clicks and identity
🚨 Why delivered DMARC failures matter
DMARC failure does not always mean the message was blocked. Depending on policy, configuration and the wider email protection pipeline, a message may still reach the user.

The investigation question is not only: “Did DMARC fail?”
It is: “Did the message still get delivered, and did the user trust it?”

👉 Or explore how GEMXIT approaches Microsoft security operations
Book an email security review →

What we are looking for

This investigation is not only looking for blocked emails. It is looking for authentication failures that still reached users and created risk.
1. DMARC failedThe message failed DMARC authentication, but still needs to be reviewed in context.
2. Sender mismatchThe visible sender and envelope sender may not align, creating a spoofing or impersonation signal.
3. Delivered despite failureThe message reached the mailbox even though the authentication evidence deserved attention.

Baseline query: DMARC failed but email was delivered

Use this query to find messages where AuthenticationDetails shows DMARC failure and the delivery outcome still indicates the message reached the user.
dmarc-failed-but-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
  16. 16
  17. 17
  18. 18
  19. 19
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| where DeliveryAction has_any ("Delivered", "Allowed", "Junked")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Used forFinding emails where DMARC failed but the message still appears to have reached a user.
Why it mattersBlocked email is useful for reporting. Delivered email is where user risk begins.
Best next stepCompare sender fields, review recipients, then pivot into URL clicks using NetworkMessageId.
How to read this query
Look for messages where AuthenticationDetails contains dmarc=fail and DeliveryAction shows the message was delivered, allowed or junked. Then compare SenderFromDomain with SenderMailFromDomain. A failed result that still reached users is more important than a failed result that was blocked.
Open EmailEvents guide →

What this activity can indicate

A delivered DMARC failure is not automatically a breach. But it is a strong signal that the message deserves investigation.
Spoofing without compromiseThe attacker may not have access to a mailbox. They may simply be pretending to be someone the user trusts.
Policy gapDMARC failure may not result in rejection depending on policy, alignment and how mail protection handled the message.
User trust riskThe system may allow the email, but the user still sees a familiar sender, subject or brand.

Query: sender alignment and DMARC failure

This query compares the visible From domain with the envelope Mail From domain when DMARC failure is present.
dmarc-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. 15
  17. 16
  18. 17
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| where SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction
| order by Timestamp desc
Used forFinding DMARC failures where sender identity and envelope identity do not align.
What to checkReview whether the mismatch is expected for a legitimate platform or suspicious for the message context.
Agent Foskett tipA mismatch is not always malicious. But a mismatch plus DMARC fail plus delivery deserves a closer look.
How to read this query
Start with SenderFromAddress because that is what the user sees. Then compare SenderFromDomain and SenderMailFromDomain. If the visible sender looks trusted but the authentication evidence does not support it, you have a stronger investigation path.
Review spoofing detection →

Query: group delivered DMARC failures by campaign pattern

One delivered DMARC failure may be noise. Repeated subjects or senders across recipients may reveal a campaign.
delivered-dmarc-fail-campaign-summary.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_any ("Delivered", "Allowed", "Junked")
| summarize
    MessageCount = count(),
    RecipientCount = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromAddress, SenderFromDomain, Subject, DeliveryAction
| where MessageCount >= 2
| order by MessageCount desc
Used forGrouping delivered DMARC failures so repeated sender or subject patterns become visible.
What to checkLook for the same subject or sender across multiple recipients in a short time window.
Next stepTake the highest-volume candidates and pivot into clicks, users and sign-in activity.

Query: pivot from delivered DMARC failure to URL clicks

If a delivered DMARC failure contained a link, the next question is whether anyone clicked it.
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
  16. 16
let DeliveredDmarcFailures =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has "dmarc=fail"
| where DeliveryAction has_any ("Delivered", "Allowed", "Junked")
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject;
DeliveredDmarcFailures
| join kind=inner (
    UrlClickEvents
    | where Timestamp > ago(30d)
    | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc
Used forFinding users who clicked links from emails that failed DMARC but were still delivered.
What to reviewReview the URL, click action, user account and time between delivery and click.
Why it mattersOnce a user clicks, the investigation moves from email analysis into identity and endpoint behaviour.
How to read this query
The key pivot is NetworkMessageId. It lets you move from a delivered email to user interaction. If a user clicked after a DMARC failure, review the user, device, sign-in activity and any follow-up access.
Review click investigation →

What happens after the user trusts the message?

A delivered spoofed email is often just the beginning. Once the user trusts it, the risk can move into sessions, files and data access.
MFA session hijackingUnderstand how attackers can reuse trusted sessions after authentication.

View session hijacking →
After-hours file accessSee how trusted-looking activity can become suspicious when timing, volume and SharePoint access do not match the user.

Investigate file access →
When nothing looks wrongLearn how behaviour can reveal risk even when no high-severity alert is triggered.

Read more →

Continue your investigation

This investigation is part of the wider Agent Foskett Microsoft Defender and KQL investigation path.
EmailEvents KQL guideUnderstand sender fields, AuthenticationDetails, delivery actions and investigation pivots.

Open guide →
KQL email spoofingDetect spoofed domains, sender mismatch and suspicious message delivery in Microsoft Defender.

Review spoofing →
KQL threat hunting guideBuild a full investigation workflow across Defender, Sentinel and Entra ID.

Open KQL hub →
Need help reviewing delivered DMARC failures?
Finding dmarc=fail is easy. Understanding whether it mattered is harder. GEMXIT helps organisations investigate Microsoft Defender EmailEvents, AuthenticationDetails, spoofing behaviour, user clicks and real-world Microsoft 365 email risk.
Book an Email Security Review →
ACSC Logo

GEMXIT PTY LTD   |   GEMXIT UK LTD   |   © GEMXIT 2026

DMARC failed but email was delivered Microsoft Defender KQL investigation

Practical Microsoft Defender XDR KQL guide covering EmailEvents, AuthenticationDetails, dmarc=fail, delivered DMARC failure, spoofed email domains, sender alignment, DeliveryAction and Microsoft 365 email investigation workflows.

Detect delivered DMARC fail emails with EmailEvents KQL

This page targets practical searches for dmarc=fail EmailEvents, AuthenticationDetails DMARC failure, spoofed sender domains, Microsoft Defender email analysis, delivered spoofed emails and URL click investigation pivots.

GEMXIT Microsoft Security Operations

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