ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
EmailEvents • AuthenticationDetails • DMARC • SPF • DKIM • CompAuth

AuthenticationDetails Explained

The email was delivered. The sender looked familiar. The user saw a message that appeared to belong in the mailbox.

But the authentication story did not fully line up.

AuthenticationDetails is one of the most useful fields in Microsoft Defender XDR, but it is also one of the easiest to misread. It can show DMARC, SPF, DKIM and Composite Authentication results inside the same email event.

This Agent Foskett investigation explains how to read AuthenticationDetails with KQL, how to recognise sender alignment problems, and why a message can look trusted even when the evidence says it deserves a closer review.

The goal is simple: stop reading authentication as pass or fail only. Read it as a story.

Discuss your environment Back to briefings
AuthenticationDetails explained using Microsoft Defender KQL by GEMXIT
AuthenticationDetails summary

A practical Microsoft Defender guide to interpreting DMARC, SPF, DKIM and CompAuth results inside EmailEvents so authentication evidence can be explained clearly.

Read AuthenticationDetails correctly
Understand DMARC, SPF, DKIM and CompAuth
Pivot from authentication to spoofing risk
🚨 Why AuthenticationDetails matters
AuthenticationDetails helps explain whether the message identity can be trusted. It is where DMARC, SPF, DKIM and CompAuth results can appear together.

The investigation question is not only: “Did authentication pass?”
It is: “Do the authentication results, sender fields and delivery outcome make sense together?”

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

What we are looking for

This guide is not only about finding failures. It is about understanding what the authentication evidence means when it is combined with sender fields and delivery outcomes.
1. DMARC resultsDMARC tells you whether the visible From domain aligns with authenticated sending evidence.
2. SPF and DKIM signalsSPF and DKIM may pass individually, but that does not always mean DMARC alignment succeeded.
3. CompAuth contextComposite Authentication can help explain why Microsoft assessed a message differently from a single authentication result.

Baseline query: view AuthenticationDetails in EmailEvents

Use this query to create a clean view of the fields needed to read authentication evidence in Microsoft Defender XDR.
authenticationdetails-baseline.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)
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Used forCreating a readable investigation view of sender identity, authentication evidence and delivery outcome.
Why it mattersYou cannot understand email trust by looking at one field. Sender fields and AuthenticationDetails need to be read together.
Best next stepFilter for DMARC failures, sender mismatch, suspicious delivery outcomes or repeated campaign patterns.
How to read this query
Start with SenderFromAddress, because that is what the user sees. Then compare SenderFromDomain with SenderMailFromDomain. Finally, read AuthenticationDetails and DeliveryAction together. If authentication evidence is weak but the message was delivered, the investigation should continue.
Open EmailEvents guide →

What AuthenticationDetails can tell you

AuthenticationDetails often contains the evidence needed to explain why a message was trusted, blocked, quarantined or allowed.
DMARCShows whether the visible sender domain aligned with SPF or DKIM authentication results.
SPF and DKIMShow whether the sending infrastructure and signed message evidence passed their checks.
CompAuthShows Microsoft composite authentication assessment, which may combine multiple signals into a broader trust result.

Query: find DMARC failures in AuthenticationDetails

This query focuses on the most common investigation pivot: messages where AuthenticationDetails contains a DMARC failure.
authenticationdetails-dmarc-fail.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,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction
| order by Timestamp desc
Used forFinding messages where DMARC failed and the sender trust story needs closer review.
What to checkReview whether the visible From domain aligns with the actual sending domain and whether the message was delivered.
Agent Foskett tipA DMARC failure is not always an attack. But a DMARC failure plus delivery plus sender mismatch is a much stronger signal.
How to read this query
Do not stop at dmarc=fail. Ask whether the email was delivered, whether the sender mismatch is expected, and whether multiple recipients received similar messages. AuthenticationDetails provides evidence, but the story comes from context.
Review delivered DMARC failures →

Query: sender mismatch with authentication evidence

This query compares the visible sender domain with the envelope sender domain while keeping AuthenticationDetails visible.
authenticationdetails-sender-mismatch.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 SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction
| order by Timestamp desc
Used forFinding messages where what the user sees and what the mail system processed do not fully align.
What to checkSome third-party services legitimately use different Mail From domains. Context decides whether the mismatch matters.
Next stepCombine sender mismatch with DMARC failure, delivery outcome and recipient spread to prioritise investigations.
How to read this query
A sender mismatch is not a verdict. It is a question. Is this an expected sending platform, or is the message pretending to be someone the user trusts? AuthenticationDetails helps answer that question.
Review spoofing detection →

Query: summarise AuthenticationDetails patterns

This query groups authentication evidence so repeated patterns become easier to see across your environment.
authenticationdetails-pattern-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
EmailEvents
| where Timestamp > ago(30d)
| summarize
    MessageCount = count(),
    RecipientCount = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromDomain, SenderMailFromDomain, AuthenticationDetails, DeliveryAction
| where MessageCount >= 3
| order by MessageCount desc
Used forGrouping repeated authentication patterns by sender domain, mail-from domain and delivery outcome.
What to checkLook for repeated DMARC failures, suspicious sender domains, unusual delivery outcomes or campaigns affecting multiple recipients.
Next stepTake the highest-volume patterns and pivot into detailed EmailEvents, UrlClickEvents and identity activity.

Query: pivot from authentication evidence to URL clicks

AuthenticationDetails explains trust. UrlClickEvents shows whether the user interacted with the message.
authenticationdetails-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 SuspiciousAuthMail =
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail", "dkim=fail", "spoof")
| where DeliveryAction has_any ("Delivered", "Allowed", "Junked")
| project NetworkMessageId, EmailTime = Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, AuthenticationDetails;
SuspiciousAuthMail
| 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 with suspicious authentication evidence.
What to reviewReview the URL, click action, user account, message subject and how quickly the click happened after delivery.
Why it mattersOnce a user clicks, the investigation moves beyond email trust and into identity, session and endpoint behaviour.
How to read this query
The key pivot is NetworkMessageId. It connects the delivered message to user interaction. If a message had suspicious AuthenticationDetails and a user clicked, review the user, device, sign-ins and any follow-up access.
Review click investigation →

What happens after authentication looks questionable?

Suspicious authentication evidence is often just the beginning. The real investigation moves into clicks, sessions and data access.
DMARC failed but deliveredSee how failed authentication can still result in delivered email.

View delivered DMARC case →
MFA session hijackingUnderstand how trusted sessions can continue after authentication.

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

Investigate file access →

Continue your investigation

This AuthenticationDetails guide 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 reading Microsoft Defender AuthenticationDetails?
Finding AuthenticationDetails is easy. Understanding what it means is harder. GEMXIT helps organisations investigate Microsoft Defender EmailEvents, AuthenticationDetails, sender alignment, 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

AuthenticationDetails explained Microsoft Defender KQL investigation

Practical Microsoft Defender XDR KQL guide covering AuthenticationDetails, EmailEvents, DMARC, SPF, DKIM, CompAuth, sender alignment, DeliveryAction and Microsoft 365 email investigation workflows.

Read DMARC SPF DKIM and CompAuth in EmailEvents KQL

This page targets practical searches for AuthenticationDetails KQL, dmarc=fail, spf=fail, dkim=fail, compauth, spoofed sender domains, Microsoft Defender email analysis and delivered suspicious emails.

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.