ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • EmailEvents • EmailAuthenticationResults Investigation

The EmailAuthenticationResults Looked Fine

The email looked legitimate.

The sender appeared trusted.

The delivery succeeded.

At first glance, the message looked completely normal.

But hidden inside Microsoft Defender XDR EmailEvents telemetry was a field many defenders overlook: EmailAuthenticationResults.

This field can reveal important authentication behaviour involving SPF, DKIM, DMARC and composite authentication analysis.

The message may have partially passed.

The sender may have aligned just enough to avoid suspicion.

The inbox may never have shown a warning.

But the telemetry told a different story.

This Agent Foskett investigation explores how defenders can investigate EmailAuthenticationResults, AuthenticationDetails, SpoofedDomain and suspicious email authentication behaviour using KQL inside Microsoft Defender XDR.

The email looked fine.

The logs wanted a second opinion.

Discuss email authentication investigations Back to Investigation Hub
Agent Foskett investigates EmailAuthenticationResults inside Microsoft Defender XDR EmailEvents telemetry
Briefing summary

EmailAuthenticationResults can help defenders understand whether SPF, DKIM, DMARC and other authentication signals really supported the sender identity users saw in the inbox.

Review EmailAuthenticationResults
Compare AuthenticationDetails
Hunt SPF, DKIM and DMARC anomalies
🚨 The email passed enough checks to feel trusted.
But “trusted enough” is not the same as safe. EmailAuthenticationResults helps defenders inspect the authentication story behind the message.
Book a security review →

What is EmailAuthenticationResults?

EmailAuthenticationResults is a Microsoft Defender XDR EmailEvents field that can help defenders understand how email authentication checks were interpreted. It may include authentication signals related to SPF, DKIM, DMARC and other sender trust decisions.
The sender looked trustedThe visible sender may appear familiar, but defenders need to verify what the authentication telemetry actually proved.
The checks may be mixedSPF, DKIM and DMARC can tell different parts of the story. One pass does not automatically mean the whole email is safe.
The investigation needs contextEmailAuthenticationResults should be reviewed alongside AuthenticationDetails, SpoofedDomain, DeliveryAction, ThreatTypes and user activity.

Why defenders miss it

Email authentication can be misunderstood because the inbox experience is simple, while the authentication chain is not. A message can look normal to the user while the telemetry contains subtle clues worth investigating.
The display name looked rightUsers trust names, logos and familiar language. Attackers know this and build emails around visual trust.
The delivery succeededSuccessful delivery does not prove the sender was safe. It only proves the email reached the mailbox.
The signal was buriedThe best clue may not be a loud alert. It may be a field value sitting quietly inside EmailEvents.

First hunt: review EmailAuthenticationResults

Start by reviewing messages where EmailAuthenticationResults contains useful authentication data. This gives defenders visibility into the authentication story behind the message.
emailauthenticationresults-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
EmailEvents
| where Timestamp > ago(7d)
| where EmailAuthenticationResults != ""
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          EmailAuthenticationResults,
          AuthenticationDetails,
          SpoofedDomain,
          DeliveryAction
| order by Timestamp desc
What to reviewLook at sender, recipient, subject, EmailAuthenticationResults, AuthenticationDetails, SpoofedDomain and delivery action.
Why it mattersThis field can reveal the difference between what the user saw and what the system authenticated.
Best next pivotPivot into DMARC failures, SpoofedDomain values, UrlClickEvents and suspicious post-delivery activity.

How EmailAuthenticationResults relates to AuthenticationDetails

EmailAuthenticationResults and AuthenticationDetails should be read together. One field may show the authentication result summary, while the other can expose more detail about SPF, DKIM, DMARC and composite authentication behaviour.
SPF can be misleadingSPF may pass for the envelope sender while the visible From identity still deserves further review.
DKIM can reveal signing gapsDKIM failures or unexpected signing domains can help defenders identify sender alignment issues.
DMARC ties it togetherDMARC alignment can reveal whether the authenticated sender matched the identity the user saw.

Second hunt: DMARC failures and authentication anomalies

DMARC failures are not always malicious, but they are always worth understanding. Combine EmailAuthenticationResults with AuthenticationDetails to investigate why authentication did not align.
emailauthenticationresults-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
EmailEvents
| where Timestamp > ago(7d)
| where AuthenticationDetails has "dmarc=fail"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          EmailAuthenticationResults,
          AuthenticationDetails,
          SpoofedDomain,
          ThreatTypes
| order by Timestamp desc

Third hunt: follow user clicks after suspicious delivery

Authentication anomalies become more important when the user interacts with the message. After reviewing EmailEvents, pivot into UrlClickEvents to identify whether the recipient clicked a link after suspicious delivery.
url-clicks-after-authentication-anomaly.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
UrlClickEvents
| where Timestamp > ago(7d)
| project Timestamp,
          AccountUpn,
          Url,
          ActionType,
          ThreatTypes,
          NetworkMessageId
| order by Timestamp desc

What EmailAuthenticationResults does not automatically mean

EmailAuthenticationResults is evidence, not the verdict. It helps defenders understand authentication behaviour, but the message still needs surrounding context before deciding whether it is malicious, misconfigured or benign.
Third-party mail can complicate resultsSaaS platforms, marketing systems and ticketing tools often send on behalf of domains and may require proper SPF, DKIM and DMARC alignment.
Forwarding can change the storyForwarders, relays, hybrid mail systems and security gateways can affect authentication results and require careful interpretation.
Misconfiguration is commonAuthentication anomalies may indicate configuration drift rather than a confirmed attack, but they still create risk.

Where defenders get caught

Email authentication investigations fail when teams assume one passing result means the whole message is safe. Strong investigations compare the visible sender, authentication details, delivery action and what the user did next.
They trust a single passSPF passing does not automatically prove the message was safe or aligned with the visible sender.
They ignore alignmentThe real question is whether the authenticated sender matched the sender identity the user saw.
They stop before the clickIf the email was delivered and clicked, the investigation must continue into URL clicks, sign-ins and mailbox behaviour.

How GEMXIT approaches this type of investigation

At GEMXIT, we treat EmailAuthenticationResults as one part of the wider email investigation story. We review authentication results, sender alignment, delivery outcome, threat signals and user interaction together.
We compare sender fieldsSenderFromAddress, SenderMailFromAddress, domains, display names and authentication results all help explain the real sender story.
We correlate user behaviourDelivery alone is not the full incident. URL clicks, mailbox access and sign-in activity help reveal whether the user interacted with the threat.
We improve authentication controlsResponse may include SPF cleanup, DKIM signing, DMARC enforcement, sender alignment review, Defender tuning and user education.
The authentication looked fine. The investigation still needed proof.
GEMXIT helps organisations investigate EmailAuthenticationResults, AuthenticationDetails, DMARC failures, SpoofedDomain, Defender XDR telemetry and practical KQL hunting workflows.
Contact GEMXIT

Final thought

The inbox looked normal.

The sender looked trusted.

The email passed through the environment quietly.

But the telemetry already knew something deserved a second look.

The real investigation started with one field:

EmailAuthenticationResults.
At GEMXITWe help organisations investigate Microsoft Defender XDR, email authentication anomalies, DMARC failures, suspicious delivery, URL clicks and real-world security operations workflows.
Agent Foskett mindsetThe question is not only: “Did the email pass authentication?”

It is: “What exactly passed — and what quietly failed?”

Continue the investigation with SpoofedDomain in EmailEvents, KQL Email Spoofing, Detect DMARC Fail Emails in Microsoft Defender, EmailEvents KQL Guide, AuthenticationDetails Explained, The Email Passed SPF But Was Still Malicious, SpoofedDomain and EmailEvents in Microsoft Defender, Microsoft Defender KQL Threat Hunting Guide, Microsoft Security and the GEMXIT Security Review.

Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

The EmailAuthenticationResults Looked Fine

This Agent Foskett briefing explains what EmailAuthenticationResults means inside Microsoft Defender XDR EmailEvents and how defenders can use it during email authentication and phishing investigations.

Microsoft Defender XDR EmailEvents EmailAuthenticationResults Investigation

GEMXIT helps organisations investigate EmailAuthenticationResults, EmailEvents, AuthenticationDetails, SpoofedDomain, DMARC failures, SPF, DKIM, suspicious delivery and user click activity.

AuthenticationDetails, DMARC Failures and KQL Hunting

Defenders should compare EmailAuthenticationResults with AuthenticationDetails, SPF, DKIM, DMARC, sender fields, delivery actions and UrlClickEvents to understand whether an email was trusted, misconfigured, spoofed or malicious.