ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 60 • Email Investigation

Investigating AuthenticationDetails in Microsoft Defender XDR.

The email looked legitimate.

The sender appeared trusted.

The domain matched the company name.

Yet something still felt wrong.

Agent Foskett needed to understand how Microsoft evaluated the message.

Did SPF pass? Did DKIM validate? Did DMARC succeed?

In Microsoft Defender XDR, AuthenticationDetails helps defenders review SPF, DKIM, DMARC and composite authentication results during email investigations.

Start Lesson 60 Back to Academy
Agent Foskett Academy lesson explaining AuthenticationDetails in Microsoft Defender XDR
Lesson overview

Learn how to investigate email authentication evidence and use AuthenticationDetails to understand SPF, DKIM, DMARC and composite authentication outcomes.

Review SPF, DKIM and DMARC results
Investigate spoofing and impersonation
Compare authentication and delivery outcomes
Validate sender authenticity evidence

Why AuthenticationDetails matters

AuthenticationDetails helps defenders understand whether the sending infrastructure and visible sender identity passed important email authentication checks.
It validates sender authenticityAuthenticationDetails helps reveal how Microsoft evaluated SPF, DKIM, DMARC and composite authentication.
It supports spoofing investigationsFailed or misaligned authentication can provide important evidence when messages pretend to come from trusted domains.
It improves phishing analysisAuthentication evidence helps defenders compare sender claims, threat classification, delivery action and user exposure.

The fields used in this lesson

These fields help defenders connect authentication evidence to sender, delivery and threat classification context.
AuthenticationDetailsContains SPF, DKIM, DMARC and composite authentication evaluation results.
SenderFromAddressThe visible sender address shown in the message.
SenderFromDomainThe visible sender domain that should align with authentication evidence during trusted mail flow.
ThreatTypesThreat classification such as phishing, malware, spam or spoofing.
DeliveryActionThe action Microsoft 365 applied to the message during delivery and filtering.
NetworkMessageIdThe message identifier used to connect email, URL, attachment and click evidence.

Step 1 — Review AuthenticationDetails

Start by reviewing recent messages where Microsoft recorded email authentication evidence.
review-authenticationdetails.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
EmailEvents
| where Timestamp > ago(30d)
| where isnotempty(AuthenticationDetails)
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          AuthenticationDetails
| order by Timestamp desc

Step 2 — Search for DMARC failures

DMARC failures can indicate domain alignment problems, spoofing attempts or legitimate senders that are not configured correctly.
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
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails contains "dmarc=fail"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          AuthenticationDetails
| order by Timestamp desc

Step 3 — Search for SPF failures

SPF failures help defenders identify messages sent from infrastructure that may not be authorised for the sender domain.
spf-failures.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails contains "spf=fail"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          AuthenticationDetails
| order by Timestamp desc

Step 4 — Search for DKIM failures

DKIM failures can indicate message signing problems, sender configuration issues or suspicious delivery paths.
dkim-failures.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
EmailEvents
| where Timestamp > ago(30d)
| where AuthenticationDetails contains "dkim=fail"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          AuthenticationDetails
| order by Timestamp desc

Step 5 — Review failed authentication with threat context

Authentication failures are more useful when reviewed with Microsoft threat classification and delivery outcomes.
failed-authentication-with-threats.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 contains "fail"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          ThreatTypes,
          AuthenticationDetails,
          DeliveryAction
| order by Timestamp desc

Step 6 — Compare authentication patterns

Summarising AuthenticationDetails can reveal recurring authentication patterns, misconfigured senders and repeat spoofing activity.
summarise-authenticationdetails.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
EmailEvents
| where Timestamp > ago(30d)
| where isnotempty(AuthenticationDetails)
| summarize MessageCount = count() by AuthenticationDetails
| order by MessageCount desc

How to read the results

AuthenticationDetails provides technical evidence, but the result must be interpreted alongside visible sender, delivery outcome and message intent.
SPF tells you sending infrastructureSPF helps determine whether the sending server was authorised for the envelope sender domain.
DKIM tells you message signingDKIM helps determine whether the message was signed and validated by the claimed sending domain.
DMARC tells you alignmentDMARC helps determine whether authentication results align with the visible From domain.

Common investigation uses

AuthenticationDetails is useful whenever defenders need to prove whether an email really came from where it claimed to come from.
Spoofing investigationsReview SPF, DKIM and DMARC results when analysing messages that impersonate trusted brands, suppliers or internal users.
Business email compromiseUnderstand whether a message was authenticated, misaligned, relayed through an unusual sender or delivered despite authentication failure.
Mail flow validationConfirm whether legitimate business systems, third-party platforms and marketing tools are authenticating correctly.

Common mistakes

Email authentication evidence is powerful, but it is easy to misread when reviewed in isolation.
Looking at SPF aloneSPF is important, but DMARC alignment and DKIM validation may change the interpretation.
Assuming pass means safeAn authenticated message can still be malicious if the sender is compromised, abused or sending harmful content.
Ignoring delivery outcomeAlways compare AuthenticationDetails with DeliveryAction, ThreatTypes, DetectionMethods and user exposure evidence.
The sender looked trusted. The authentication told the truth.
Use AuthenticationDetails to understand how Microsoft evaluated SPF, DKIM, DMARC and composite authentication before deciding whether the message deserves trust.
Back to Academy →

What you learned

AuthenticationDetails explains authenticationIt helps defenders review SPF, DKIM, DMARC and composite authentication outcomes.
Authentication failures need contextReview failures with sender domains, ThreatTypes, DeliveryAction and DetectionMethods.
Authenticated does not always mean safeA message can authenticate correctly and still be malicious if the sender or sending platform is compromised.

Related Agent Foskett Academy lessons

Investigating EmailEventsStart with core email evidence including sender, recipient, subject and delivery fields.
Investigating DeliveryActionUnderstand what Microsoft 365 did with the message during delivery.
Investigating ThreatTypesReview whether Microsoft classified the message as phishing, malware, spam, spoofing or another threat type.
Investigating DetectionMethodsUnderstand how Microsoft identified and classified suspicious email activity.
Investigating EmailDirectionDetermine whether messages were inbound, outbound or internal.
Investigating OrgLevelActionReview organisational policy actions applied to suspicious email messages.
Investigating SenderFromAddress vs SenderMailFromAddressCompare visible sender and envelope sender evidence.
Investigating NetworkMessageIdConnect the same email across URL, click and attachment telemetry.

Coming next

Lesson 61 — Investigating SenderIPv4 in Microsoft Defender XDRNext, Agent Foskett Academy will explain how defenders use SenderIPv4 to investigate the sending infrastructure behind suspicious email messages.
Why this mattersAuthenticationDetails explains whether authentication passed or failed. SenderIPv4 helps reveal where the message actually came from.
What you will learn nextLearn how sender IP evidence supports spoofing, phishing, reputation and mail flow investigations.

Final thought

The sender name was only the surface. The authentication evidence showed what was underneath.
Agent Foskett mindsetDo not trust the sender name alone. Check how the message authenticated and whether the result aligns with the claim.
Read the authenticationAuthenticationDetails turns SPF, DKIM and DMARC into practical investigation evidence.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Investigating AuthenticationDetails in Microsoft Defender XDR

Agent Foskett Academy Lesson 60 teaches defenders how to investigate AuthenticationDetails during Microsoft Defender XDR email investigations.

Learn email authentication investigation in Defender XDR

This lesson explains how AuthenticationDetails, SPF, DKIM, DMARC, ThreatTypes, DetectionMethods and DeliveryAction help defenders understand whether suspicious email messages authenticated correctly and whether sender claims can be trusted.