Agent Foskett • Microsoft Defender • EmailEvents KQL

SpoofedDomain in EmailEvents: Detecting Spoofed Emails in Microsoft Defender

The email looked legitimate.

The sender appeared familiar.

But Microsoft Defender telemetry told a different story.

This Agent Foskett investigation shows how SpoofedDomain, EmailEvents, AuthenticationDetails and DMARC signals can help uncover spoofed emails, sender impersonation and suspicious delivery activity using KQL in Microsoft Defender XDR.

Discuss your environment Back to briefings

Agent Foskett SpoofedDomain EmailEvents Microsoft Defender KQL investigation

Briefing summary

Learn how SpoofedDomain, EmailEvents, AuthenticationDetails and DMARC results help defenders identify spoofed emails, sender impersonation and suspicious delivery activity in Microsoft Defender XDR.

Detect spoofed sender domains

Read EmailEvents and AuthenticationDetails

Pivot into clicks, delivery and user impact

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.

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.

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
| 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.

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