ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Email Security • DMARC • Microsoft Defender XDR

The DMARC Failure Was The First Clue

The email looked convincing.

The sender appeared to be a trusted supplier. The logo was familiar. The request sounded urgent, but not unusual.

Then Microsoft Defender recorded one small detail that changed the investigation: DMARC = Fail.

Discuss email security Back to briefings
Agent Foskett Microsoft Defender XDR DMARC failure investigation
Briefing summary

A payment update email looked legitimate to the user, but authentication telemetry told a different story. Agent Foskett follows DMARC, SPF, DKIM, Composite Authentication and sender identity evidence to determine whether the message deserved trust.

DMARC = Fail
Sender Identity = Mismatch
EmailEvents = Starting Point
Final Answer = Authentication Evidence

The email looked trustworthy

The user saw branding, urgency and a familiar supplier name. Agent Foskett saw an identity claim that needed proof.
The display name looked familiar The sender name matched a supplier the organisation recognised. That made the message feel normal before anyone checked the underlying authentication.
The request sounded urgent The email asked for a payment update, invoice confirmation or account action. The wording created enough pressure for the user to consider responding.
The first clue was authentication The investigation did not start with the subject line. It started with Microsoft Defender recording that DMARC had failed.

Why DMARC mattered

DMARC helps determine whether the visible sender domain aligns with the infrastructure authorised to send the message.
SPF checks the sending path SPF helps determine whether the sending server was authorised for the envelope sender domain.
DKIM checks message signing DKIM helps determine whether the message was signed by a domain and whether that signature survived delivery.
DMARC checks alignment DMARC brings the visible sender domain into the trust decision. A failure can mean the email is not who it claims to be.

The first KQL question

Agent Foskett searches Defender XDR for messages where authentication evidence contains a DMARC failure.
dmarc-failure-search.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"
| where AuthenticationDetails has "fail"
| project
    Timestamp,
    NetworkMessageId,
    SenderFromAddress,
    SenderMailFromAddress,
    RecipientEmailAddress,
    Subject,
    ThreatTypes,
    DeliveryAction,
    DeliveryLocation,
    AuthenticationDetails

The sender identities did not line up

The visible sender is only one part of the story. Defender investigations compare several identities.
SenderFromAddress This is the sender address the user usually sees. Attackers often abuse this field because it influences user trust.
SenderMailFromAddress This can reveal the envelope sender or return path used during transport. A mismatch can expose spoofing or relay abuse.
AuthenticationDetails This is where SPF, DKIM, DMARC and Composite Authentication can explain why the message did or did not deserve trust.

Compare visible sender and mail-from sender

A supplier name in the email body is not enough. Agent Foskett compares the sender values Defender recorded.
sender-identity-comparison.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 Subject has_any ("payment", "invoice", "account", "bank")
| extend SenderFromDomain = tostring(split(SenderFromAddress, "@")[1])
| extend SenderMailFromDomain = tostring(split(SenderMailFromAddress, "@")[1])
| where SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderMailFromAddress,
    SenderFromDomain,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    DeliveryLocation

What the failure could mean

A DMARC failure is not the entire verdict, but it is a strong reason to keep investigating.
Spoofed sender domain The attacker may have placed a trusted supplier domain in the visible sender field without permission to send for that domain.
Unauthorised infrastructure The message may have come from mail infrastructure that was not authorised by the claimed domain owner.
Broken or suspicious alignment SPF or DKIM may have passed for another domain, but DMARC failed because the domains did not align with the visible From address.

Was the email delivered?

The next question is whether the authentication failure changed the delivery decision.
dmarc-delivery-outcome.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"
| where AuthenticationDetails has "fail"
| summarize
    TotalMessages = count(),
    Recipients = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromAddress, SenderMailFromAddress, DeliveryAction, DeliveryLocation, ThreatTypes
| order by TotalMessages desc

Check for links and clicks

If the email included a link, the investigation moves from authentication to user impact.
EmailUrlInfo EmailUrlInfo helps identify URLs found inside the message and can show whether the campaign included a redirect, tracking page or credential harvesting destination.
UrlClickEvents UrlClickEvents shows whether users clicked, when they clicked and what action Microsoft Defender recorded.
User exposure A DMARC failure identifies sender trust risk. Click telemetry helps determine whether the risk became user impact.

Follow the URL evidence

The message may have started as an authentication failure, but the payload may have been a malicious link.
dmarc-fail-url-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. 16
  17. 17
let SuspiciousMessages =
    EmailEvents
    | where Timestamp > ago(30d)
    | where AuthenticationDetails has "DMARC"
    | where AuthenticationDetails has "fail"
    | project NetworkMessageId, SenderFromAddress, RecipientEmailAddress, Subject;
EmailUrlInfo
| join kind=inner SuspiciousMessages on NetworkMessageId
| project
    Timestamp,
    SenderFromAddress,
    RecipientEmailAddress,
    Subject,
    Url,
    UrlDomain

Agent Foskett moment

The email did not fail because it looked bad. It failed because it could not prove who it claimed to be.
The user saw a supplier The human view was branding, wording and a familiar name. That is exactly what the attacker wanted the user to evaluate.
Defender saw the sender chain Microsoft Defender evaluated the technical evidence: sender domains, authentication results, alignment and delivery outcome.
The first clue was enough DMARC failure did not finish the case, but it gave Agent Foskett the first thread to pull.

Questions every analyst should ask

When DMARC fails, do not stop at the pass or fail result. Reconstruct the sender story.
Who did the email claim to be from? Review SenderFromAddress, display name, visible branding and the domain the user was expected to trust.
Who actually sent it? Compare SenderMailFromAddress, sender IP, sending infrastructure, SPF result and DKIM signing domain.
Did anyone interact? Check EmailUrlInfo, UrlClickEvents and endpoint telemetry if links, downloads or follow-up activity were involved.

Related investigations

The Email Passed SPF, DKIM and DMARC — Why Did Composite Authentication Still Fail? Understand why traditional authentication passing does not always mean Microsoft Defender should trust the message.
The Link Said USPS — The URL Told A Different Story Investigate how visible link text can hide a completely different destination.
The User Reported The Email — But It Was Already Gone Learn how Defender telemetry can explain what happened after a suspicious email disappeared.
Microsoft Defender Email Security KQL Queries Use EmailEvents and authentication evidence to detect spoofed sender domains and suspicious delivery outcomes.
AuthenticationDetails Explained Understand how Microsoft Defender records SPF, DKIM, DMARC and composite authentication signals.
EmailEvents KQL Guide Build practical Defender XDR email investigations using sender, recipient, delivery and threat fields.
The email looked legitimate.
But DMARC failure was the first clue that the sender identity did not deserve trust.
Contact GEMXIT

Final thought

Authentication failures are not just technical details. They are investigation clues.
At GEMXIT We help organisations investigate Microsoft Defender XDR, phishing, spoofing, DMARC failures, Microsoft 365 security and practical threat hunting. If you want to understand how this applies to your environment, see our Microsoft Security services.
Agent Foskett mindset Do not only ask whether the email looked real. Ask whether the sender proved it was allowed to send as the domain the user trusted.
Develop IT. Protect IT. The subject line started the concern. The authentication evidence started the investigation. GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The DMARC Failure Was The First Clue

This Agent Foskett investigation explains how Microsoft Defender XDR can help analysts investigate a suspicious email where DMARC failure exposed a sender identity problem.

Microsoft Defender XDR DMARC Failure Investigation

EmailEvents, EmailAuthenticationResults, AuthenticationDetails, SenderFromAddress, SenderMailFromAddress, DeliveryAction, DeliveryLocation, EmailUrlInfo and UrlClickEvents can help defenders reconstruct spoofed email investigations.

DMARC, SPF, DKIM And Composite Authentication

DMARC failure can reveal sender spoofing, domain alignment issues, unauthorised mail infrastructure and suspicious email delivery behaviour inside Microsoft 365 environments.