Agent Foskett Academy • Lesson 52 • Email Authentication
Investigating EmailAuthenticationResults in Microsoft Defender XDR.
The sender looked trusted.
The display name looked familiar.
The message reached the mailbox.
But the authentication evidence needed a closer look.
EmailAuthenticationResults helps defenders understand what SPF, DKIM, DMARC and composite authentication really said about the message.
Lesson overview
Learn how EmailAuthenticationResults supports Microsoft Defender XDR email investigations by exposing SPF, DKIM, DMARC and composite authentication evidence.
Read authentication outcomes
Compare SPF, DKIM and DMARC
Investigate sender alignment
Separate trusted-looking from trusted
What EmailAuthenticationResults is
EmailAuthenticationResults records authentication evidence for an email message. It helps defenders understand whether the sender passed SPF, DKIM, DMARC and composite authentication checks.
SPFShows whether the sending server was authorised to send mail for the envelope sender domain.
DKIMShows whether the message had a valid cryptographic signature connected to a sending domain.
DMARCShows whether SPF or DKIM aligned with the visible sender domain shown to the recipient.
Why this field matters
A message can look legitimate to the user while the authentication evidence tells a more complicated story.
The visible sender can be misleadingSender display names and visible From addresses are designed for people. Attackers know users trust what they recognise.
Authentication adds evidenceEmailAuthenticationResults gives defenders a technical view of how the message was authenticated.
Passed does not always mean safeSome malicious emails pass authentication because attackers use domains they control properly.
Fields to review with EmailAuthenticationResults
Email authentication is strongest when reviewed alongside sender, domain and delivery context.
SenderFromAddressThe visible sender address most users are likely to notice.
SenderMailFromAddressThe envelope sender used during SMTP handling and SPF evaluation.
SenderFromDomainThe domain shown in the visible From address.
SenderMailFromDomainThe domain used by the envelope sender.
AuthenticationDetailsAdditional authentication evidence that may include SPF, DKIM, DMARC and spoofing details.
DeliveryActionShows what Microsoft Defender did with the message after evaluation.
Step 1 — Start with recent email authentication evidence
Begin by reviewing the messages and projecting the fields that explain authentication and sender context.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
EmailEvents
| where Timestamp > ago(30d)
| project Timestamp,
SenderFromAddress,
SenderMailFromAddress,
SenderFromDomain,
SenderMailFromDomain,
RecipientEmailAddress,
Subject,
DeliveryAction,
EmailAuthenticationResults,
AuthenticationDetails
| order by Timestamp desc
Investigation question: What did the user see, and what did the authentication evidence say?
Step 2 — Find DMARC failures
DMARC failures are useful starting points when investigating spoofing, brand impersonation and sender alignment issues.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
EmailEvents
| where Timestamp > ago(30d)
| where EmailAuthenticationResults has "dmarc=fail"
or AuthenticationDetails has "dmarc=fail"
| project Timestamp,
SenderFromAddress,
SenderMailFromAddress,
RecipientEmailAddress,
Subject,
DeliveryAction,
EmailAuthenticationResults,
AuthenticationDetails
| order by Timestamp desc
Investigation question: Did the visible sender domain fail alignment checks?
Step 3 — Compare visible sender and envelope sender
Sender mismatch does not automatically prove malicious activity, but it is a valuable signal during email investigations.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 14
- 15
EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| project Timestamp,
SenderFromAddress,
SenderMailFromAddress,
SenderFromDomain,
SenderMailFromDomain,
Subject,
DeliveryAction,
EmailAuthenticationResults
| order by Timestamp desc
Investigation question: Does the sender the user saw match the sender used for mail handling?
Step 4 — Review messages that passed but still look suspicious
Attackers can send authenticated email from domains they own. That means authentication should be treated as evidence, not a final verdict.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
EmailEvents
| where Timestamp > ago(30d)
| where EmailAuthenticationResults has "dmarc=pass"
| where Subject has_any ("invoice", "payment", "password", "verify", "account")
| project Timestamp,
SenderFromAddress,
RecipientEmailAddress,
Subject,
DeliveryAction,
ThreatTypes,
EmailAuthenticationResults
| order by Timestamp desc
Investigation question: Did the message authenticate successfully but still use suspicious language or behaviour?
Step 5 — Connect authentication to the message trail
NetworkMessageId allows defenders to keep the same message in scope while reviewing authentication, URL, click and attachment evidence.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
let MessageId = "<NetworkMessageId>";
EmailEvents
| where NetworkMessageId == MessageId
| project Timestamp,
NetworkMessageId,
SenderFromAddress,
SenderMailFromAddress,
Subject,
DeliveryAction,
EmailAuthenticationResults,
AuthenticationDetails
Investigation question: Which authenticated message are we following through the rest of Defender XDR?
How to read authentication results
The words pass and fail are useful, but defenders need to understand what passed, what failed and whether alignment supports trust.
SPF passThe sending server was allowed by the envelope sender domain. This does not always mean the visible From domain is trustworthy.
DKIM passThe message signature validated for a domain. Investigators still need to check whether that domain aligns with the visible sender.
DMARC passAt least one aligned authentication mechanism passed for the visible sender domain.
DMARC failThe visible sender domain did not align with SPF or DKIM authentication in a way that satisfied DMARC.
Composite authenticationMicrosoft may combine multiple signals to make a broader authentication decision.
Delivery outcomeAuthentication should be compared against DeliveryAction, ThreatTypes and user interaction evidence.
Common investigation uses
EmailAuthenticationResults is useful whenever defenders need to explain why an email looked trusted, failed authentication or was still suspicious despite passing checks.
Phishing investigationsReview whether suspicious messages passed or failed SPF, DKIM and DMARC.
Spoofing analysisCompare visible sender domains against mail-from domains and authentication results.
False positive reviewsExplain why a legitimate email was blocked, junked or quarantined.
Common mistakes
Email authentication is powerful, but it is easy to misread when defenders focus on only one result.
Assuming pass means safeA malicious sender can pass authentication when they use their own domain correctly.
Ignoring alignmentSPF and DKIM results matter most when you understand which domain they validated.
Ignoring the user viewThe visible sender, display name and subject are still important because they explain why the user trusted the message.
What you learned
EmailAuthenticationResults explains authenticationIt helps defenders review SPF, DKIM, DMARC and composite authentication evidence.
Sender context mattersThe visible sender and envelope sender should be compared during phishing and spoofing investigations.
Authentication is only one part of trustDefenders still need to review delivery, threats, clicks, attachments and user behaviour.
Related Agent Foskett Academy lessons
Investigating EmailEventsStart with the suspicious message and understand sender, recipient and delivery evidence.
Investigating NetworkMessageIdConnect email evidence across multiple Defender XDR tables.
Investigating UrlClickEventsConfirm whether a user clicked a suspicious URL.
Investigating EmailUrlInfoReview URLs extracted from messages and connect them to phishing investigations.
Investigating EmailAttachmentInfoReview attachment names, hashes and file evidence.
Using has_anyFind suspicious terms across subjects, senders and authentication evidence.
Extracting Evidence with extract()Extract useful indicators from structured and semi-structured text fields.
Lesson 50 — The Timeline Told The StoryConnect evidence into one complete investigation story.
Coming next
Lesson 53 — Investigating SenderFromAddress vs SenderMailFromAddressNext, Agent Foskett Academy will compare the visible sender with the envelope sender and explain why the sender is not always really the sender.
Why this mattersAuthentication results become clearer when defenders understand which sender domain the user saw and which sender domain the mail system evaluated.
What you will learn nextLearn how to compare SenderFromAddress, SenderMailFromAddress, sender domains and spoofing signals in Microsoft Defender XDR.
Final thought
The inbox showed a sender. The telemetry showed the evidence.
Agent Foskett mindsetDo not stop at what the user saw. Compare the visible sender, the authenticated sender and the delivery outcome.
Trust but verifyEmail authentication helps explain trust, but the investigation still needs context.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
