ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett • Microsoft Defender • EmailEvents KQL

SpoofedDomain and EmailEvents: Detecting Spoofed Emails in Microsoft Defender

The email looked legitimate.

The sender name looked familiar. The message reached the mailbox. No one immediately panicked.

But inside Microsoft Defender, the evidence was already there.

SpoofedDomain. EmailEvents. AuthenticationDetails. DMARC failure signals.

This Agent Foskett briefing looks at how Microsoft Defender XDR and KQL can help uncover spoofed emails, sender mismatch, failed authentication and suspicious delivery behaviour that may not be obvious to the user.

The inbox may show a trusted name. The logs show what actually happened.

Discuss your environment Back to briefings
Agent Foskett SpoofedDomain EmailEvents Microsoft Defender KQL investigation
Briefing summary

SpoofedDomain and EmailEvents can expose email spoofing that users may never notice. GEMXIT looks at how Microsoft Defender XDR, AuthenticationDetails, DMARC results and KQL help investigate suspicious email authentication behaviour.

Detect spoofed sender domains
Read EmailEvents and AuthenticationDetails
Pivot into clicks, delivery and user impact
🚨 The display name looked trusted. The domain did not.
Spoofed emails are not always obvious to users. Microsoft Defender data can reveal sender mismatch, DMARC failures and authentication signals that explain why a message should not have been trusted.
Book a security review →

What happened

A suspicious email appeared to come from a trusted organisation, but the Microsoft Defender data told a different story. The visible sender and the authenticated sender did not align.
The email looked legitimate The sender display name and message content appeared familiar, which is exactly what makes spoofed email so effective.
The domains did not align EmailEvents and AuthenticationDetails showed sender mismatch, spoofing indicators or authentication results that did not match the visible message.
The logs already knew The important evidence was not in the email body. It was in the telemetry: SpoofedDomain, EmailEvents, AuthenticationDetails and delivery outcome.

Why SpoofedDomain and EmailEvents matter

Attackers rely on trust. Microsoft Defender helps security teams test whether that trust is real, inherited, misconfigured or completely faked.
Display names can lie A user sees a friendly name. Defender sees the sender address, sender domain, mail-from domain, authentication result and delivery action.
DMARC fail may still be delivered A failed authentication result does not always mean the message was blocked. Policy, forwarding, allow rules and delivery settings can still allow exposure.
Context completes the picture The real question is not only whether spoofing was detected. It is whether the message was delivered, clicked, replied to or used to start identity compromise.

First hunt: find spoofed or mismatched sender domains

Start with EmailEvents. Look for messages marked as spoof, or where the visible sender domain does not align with the mail-from domain.
spoofeddomain-emailevents-detection.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 TimeGenerated > ago(7d)
| where ThreatTypes has "Spoof"
    or SenderFromDomain != SenderMailFromDomain
| project TimeGenerated,
          SenderFromAddress,
          SenderFromDomain,
          SenderMailFromDomain,
          RecipientEmailAddress,
          Subject,
          ThreatTypes,
          DeliveryAction,
          NetworkMessageId
| order by TimeGenerated desc
What to review Look for mismatched domains, spoof indicators, suspicious subjects, unusual sender infrastructure and messages delivered to high-value users.
Why it matters Spoofed emails often rely on the user trusting what they see, while the underlying message headers tell a different story.
Best next pivot Pivot into AuthenticationDetails, delivery action, URL clicks, related messages and any sign-in activity after user interaction.

Second hunt: investigate AuthenticationDetails and DMARC failures

AuthenticationDetails can show whether SPF, DKIM, DMARC and composite authentication aligned with the sender identity presented to the user.
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
EmailEvents
| where TimeGenerated > ago(14d)
| where AuthenticationDetails has "dmarc=fail"
    or AuthenticationDetails has "spf=fail"
    or AuthenticationDetails has "dkim=fail"
| project TimeGenerated,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          AuthenticationDetails,
          ThreatTypes,
          DeliveryAction,
          NetworkMessageId
| order by TimeGenerated desc
What to review Look for dmarc=fail, spf=fail, dkim=fail, compauth failures and delivered messages where authentication did not align.
Why it matters Authentication failures do not always mean compromise, but they do tell you the sender identity needs investigation.
Best next pivot Check whether the email was delivered, quarantined, clicked, forwarded or part of a wider campaign.

Third hunt: correlate suspicious email with URL clicks

The email itself is only one part of the investigation. The next question is whether the user clicked, submitted credentials or triggered a follow-on sign-in event.
emailevents-urlclickevents-correlation.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
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
EmailEvents
| where TimeGenerated > ago(7d)
| where ThreatTypes has "Spoof"
    or AuthenticationDetails has "dmarc=fail"
| join kind=leftouter (
    UrlClickEvents
    | project NetworkMessageId,
              ClickTime = TimeGenerated,
              AccountUpn,
              Url,
              ActionType
) on NetworkMessageId
| project TimeGenerated,
          ClickTime,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          Url,
          ActionType,
          DeliveryAction
| order by TimeGenerated desc
What to review Look for URL clicks, allowed click actions, suspicious domains, repeated clicks and users interacting with spoofed messages.
Why it matters The risk often begins after delivery. A click can lead to credential harvesting, MFA session theft or malware delivery.
Best next pivot Pivot into SigninLogs, device telemetry, new inbox rules, risky sign-ins and post-click Microsoft 365 activity.

What this kind of activity can indicate

SpoofedDomain and EmailEvents findings are not just email problems. They can be the first sign of a wider identity or business email compromise attempt.
Business email compromise Attackers may impersonate executives, suppliers, finance teams or internal users to trigger payment, approval or data disclosure.
Credential harvesting Spoofed emails often lead users to fake Microsoft 365 login pages designed to capture credentials or session tokens.
MFA session theft Adversary-in-the-middle phishing can capture a session after the user completes MFA, making the email investigation an identity investigation.
Misconfigured legitimate senders Not every DMARC failure is malicious. Some reveal third-party senders, marketing tools or SaaS platforms that are not correctly aligned.
Weak domain protection Domains without strong SPF, DKIM and DMARC enforcement are easier for attackers to abuse or imitate.
Delivered risk The most important question may be simple: did the spoofed or failed-authentication email reach a user?

How GEMXIT approaches spoofed email investigations

At GEMXIT, we do not stop at whether an email was flagged. We look at sender authentication, delivery, user interaction and post-click identity behaviour together.
We inspect the message evidence EmailEvents, AuthenticationDetails, sender domains, delivery action and NetworkMessageId help explain what really happened.
We follow the behaviour UrlClickEvents, SigninLogs, Defender telemetry and audit data help determine whether the user interacted and what happened next.
We improve prevention The outcome should improve SPF, DKIM, DMARC, Defender policies, user reporting and KQL hunting visibility.
The inbox showed a message. Defender showed the evidence.
GEMXIT helps organisations investigate Microsoft Defender XDR, EmailEvents, AuthenticationDetails, DMARC failures, spoofed domains and suspicious user interaction across Microsoft 365 environments.
Contact GEMXIT

Final thought

The email looked trusted. The telemetry disagreed.
At GEMXIT We help organisations use Microsoft Defender XDR, Microsoft Sentinel and KQL to investigate spoofed email, authentication failures and suspicious post-delivery behaviour.
Agent Foskett mindset The important question is not only: “Did the email arrive?”

It is: “Did the sender identity actually make sense?”

Continue the investigation with Email Spoofing Detection Guide, EmailEvents KQL Guide, AuthenticationDetails Explained, DMARC Failed But Delivered, SenderFrom vs SenderMailFrom and The User Passed MFA But It Wasn't Really Them.

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

SpoofedDomain and EmailEvents Microsoft Defender KQL Investigation

This Agent Foskett briefing explains how to investigate SpoofedDomain, EmailEvents, sender mismatch, DMARC failures and suspicious authentication signals in Microsoft Defender XDR using KQL.

AuthenticationDetails, DMARC Failures and Spoofed Email Detection

GEMXIT helps organisations investigate AuthenticationDetails, dmarc=fail, spf=fail, dkim=fail, compauth results, delivery actions, spoofed sender domains and suspicious Microsoft 365 email activity.

Microsoft Defender XDR, EmailEvents, UrlClickEvents and KQL Threat Hunting

Example investigation areas include EmailEvents, SpoofedDomain, AuthenticationDetails, UrlClickEvents, NetworkMessageId correlation, suspicious URL clicks, delivered spoofed emails, sender domain mismatch and post-delivery identity risk.