ACSC Logo
© GEMXIT
GEMXIT Logo
Email Investigation • Microsoft 365 • Defender XDR • KQL

Investigate Suspicious Email in Microsoft 365 with KQL

A suspicious email does not always announce itself. Sometimes the branding looks right, the sender looks familiar and the subject feels normal. But email trust should never be judged by appearance alone. This page shows how GEMXIT uses KQL in Microsoft Defender XDR to investigate whether a message was genuinely authenticated, poorly aligned, impersonated, or delivered despite warning signs. It supports stronger identity and access controls and practical security operations.

Discuss your environment Back to briefings
Agent Foskett email spoofing KQL briefing
Investigation summary

This page is written as an investigation guide. It uses EmailEvents, AuthenticationDetails, sender alignment and delivery context to help decide whether a suspicious email was genuinely trusted or simply convincing enough to get through.

Authentication results that do not align
Visible sender vs envelope sender checks
Follow-up pivots after message delivery
🚨 Why this matters in a real Microsoft 365 tenant
Even if there is no obvious alert: • A trusted-looking email may still fail authentication • A delivered message may still deserve review • A spoofed domain can create user trust without mailbox compromise 👉 This is the type of evidence we validate during Microsoft 365 email security assessments 👉 Or explore how we approach Microsoft security operations
Book an email security review →

What you'll learn on this page

Use this as a practical Microsoft 365 email spoofing investigation path. Start with authentication evidence, validate the sender story, then pivot into delivery, clicks and user impact.
1. Check AuthenticationDetails Find SPF, DKIM and DMARC failures in EmailEvents. 2. Compare sender alignment Validate visible From against Mail From / envelope sender values. 3. Investigate internal-looking email Find self-addressed and domain impersonation patterns. 4. Cluster repeated campaigns Group suspicious messages by sender, subject and recipient spread. 5. Pivot into UrlClickEvents Check whether a suspicious message became user interaction. 6. Build the investigation workflow Move from message suspicion to impact and response.

What this investigation page helps you answer

When a suspicious email is reported, the real question is not just whether it was spoofed. The real question is whether the message should have been trusted, delivered, clicked or escalated.
The message created trust The visible sender, display name and message style can all look normal, even when the underlying authentication story is weak.
The technical trust story failed SPF, DKIM, DMARC and sender alignment reveal whether the message was actually allowed to speak for that domain.
The investigation goal The aim is to move from suspicion to evidence: who sent it, how it authenticated, who received it and what happened next.

Start with authentication evidence

Use this baseline query when the message looks legitimate but the authentication evidence says the sender story needs validation.
email-spoofing-baseline.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
EmailEvents
| where Timestamp > ago(14d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail")
| project
                            Timestamp,
                            SenderFromAddress,
                            SenderFromDomain,
                            SenderMailFromAddress,
                            SenderMailFromDomain,
                            RecipientEmailAddress,
                            Subject,
                            AuthenticationDetails,
                            ThreatTypes,
                            DeliveryAction
| order by Timestamp desc
What this query proves It quickly surfaces recent messages where email authentication failed, then places sender, recipient, subject and delivery outcome in one investigation view.
Signals to validate Look for familiar domains, internal-looking senders, urgent business subjects, failed authentication and any message that was still delivered.
How GEMXIT applies it We use this as a first pass, then pivot into sender alignment, repeated targeting, URL clicks and user activity around the same timeframe.

Validate visible sender against envelope sender

A user sees the display sender. Defender shows the delivery path. Comparing those two values helps reveal whether the email identity is aligned or misleading.
from-vs-mailfrom-alignment.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 Timestamp > ago(14d)
| where SenderFromDomain != SenderMailFromDomain
| project
                            Timestamp,
                            SenderFromAddress,
                            SenderFromDomain,
                            SenderMailFromAddress,
                            SenderMailFromDomain,
                            RecipientEmailAddress,
                            Subject,
                            AuthenticationDetails
| order by Timestamp desc
Use this when The displayed From domain looks trustworthy, but the envelope sender or routing identity tells a different story.
Why this matters Misalignment does not automatically prove malicious activity, but it gives analysts a strong reason to validate the message path.
Next pivot Check delivery action, recipient spread, URLs in the message, user reports and any related sign-in or device activity around the same time.

Investigate emails pretending to be internal

When a message appears to come from the same person it was sent to, or looks internal when it should not, it deserves immediate attention.
self-addressed-and-internal-looking.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
let TargetDomain = "yourdomain.com";
EmailEvents
| where Timestamp > ago(14d)
| where SenderFromDomain =~ TargetDomain
| where RecipientEmailAddress endswith TargetDomain
| where SenderFromAddress =~ RecipientEmailAddress
                            or AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail")
| project Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, AuthenticationDetails, DeliveryAction, UrlCount
| order by Timestamp desc
Use this when Self-addressed spoofing, internal-looking impersonation, and messages that exploit familiarity more than technical sophistication.
Why this matters This is where users think “it came from me” or “it looks internal” and trust it before checking whether the identity was actually verified.
Best pivot Move straight into URL clicks, mailbox investigation, user reports, and any related sign-in or device activity around the same time.

Cluster suspicious messages into campaigns

A single suspicious email may be part of a wider campaign. Grouping by sender, subject and recipient count helps separate one-off noise from coordinated targeting.
repeat-patterns-by-sender.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
EmailEvents
| where Timestamp > ago(14d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail")
| summarize
                            MessageCount = count(),
                            RecipientCount = dcount(RecipientEmailAddress)
                            by SenderFromAddress, SenderFromDomain, Subject
| where MessageCount >= 3
| order by MessageCount desc
Use this when Identifying repeated spoofing attempts, same-subject campaigns, or one sender pattern targeting multiple recipients.
Why this matters A suspicious message becomes more important when it is clearly part of a broader delivery pattern rather than an isolated oddity.
How GEMXIT applies it To decide whether the issue is a single suspicious message, a spoofed sender campaign, or something that requires wider user communication and response.

Follow the trail after delivery

Once a suspicious message is identified, the next question is simple: did anyone interact with it, and did that interaction lead to anything else?
email-to-click-pivot.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
let SuspiciousMessages =
EmailEvents
| where Timestamp > ago(14d)
| where AuthenticationDetails has_any ("spf=fail", "dkim=fail", "dmarc=fail")
| project NetworkMessageId, Timestamp, SenderFromAddress, RecipientEmailAddress, Subject;

SuspiciousMessages
| join kind=inner (
                            UrlClickEvents
                            | where Timestamp > ago(14d)
                            | project NetworkMessageId, ClickTime = Timestamp, AccountUpn, Url, ActionType
) on NetworkMessageId
| order by ClickTime desc
Use this when Linking suspicious messages to user interaction so the investigation can move from mail telemetry to actual user impact.
Best next step Take the user and timestamp into sign-ins, process activity and network events to confirm whether the click was contained or became compromise.
Why this matters The difference between suspicious delivery and real incident often appears only after the user interacts with the message.

What a good suspicious email investigation includes

The point is not to stare at one field. It is to build a clean progression from message suspicion to delivery context to user impact.
Start with authentication AuthenticationDetails gives you the first evidence layer before you rely on the visible From address.
Compare what users saw with what Defender logged Users see display names and From addresses. Analysts need to compare those values with the real sender path.
Move quickly into user impact Once the message is located, check whether anyone clicked, replied, forwarded or had related activity.
Start with the email story Look at the subject, message tone and intent. Crypto scams rely on urgency, rewards and user action — not exploits.

This investigation shows how a simple email can lead to wallet access and user-approved compromise.
If a message looks trusted but the authentication story fails,
that is exactly the moment security teams need better hunting, not just better hope.
Contact GEMXIT

Related Agent Foskett email investigations

These related investigations strengthen the Microsoft 365 email security cluster and give readers a clear next step after this spoofing guide.
The Email Came From Me A practical spoofing investigation showing why a message can appear trusted while the authentication story says otherwise. DMARC Failures KQL Use Defender XDR and EmailEvents to investigate DMARC failures, sender alignment and delivery outcomes. The EmailAuthenticationResults Looked Fine A deeper look at why email authentication fields need context, not blind trust. The User Clicked The Link Three Days Later Follow the trail from suspicious delivery into delayed user click activity. The Missing Click Use UrlClickEvents and message evidence to understand where the user interaction really happened. SenderFrom vs SenderMailFrom Understand the sender fields that matter when an email looks legitimate but does not align.

Learn the KQL fundamentals behind this investigation

If you are still building confidence with KQL, these Academy lessons connect the investigation workflow back to the core operators used on this page.
What is KQL? Start with the basics of how KQL helps investigators ask questions of security data. Filtering KQL Results Learn how where filters reduce noise and focus the investigation. Using has_any Find suspicious text patterns such as spf=fail, dkim=fail and dmarc=fail. Connecting Tables with join Link EmailEvents to UrlClickEvents and build a proper investigation timeline. Counting and Grouping with summarize Turn single emails into campaign patterns by sender, subject and recipient count. Building Investigation Timelines Use timestamps and pivots to understand what happened before and after delivery.

Frequently asked questions

How do I investigate email spoofing in Microsoft 365?

Start with Microsoft Defender XDR EmailEvents, review AuthenticationDetails for SPF, DKIM and DMARC results, compare SenderFromDomain with SenderMailFromDomain, then check delivery action, recipient targeting and UrlClickEvents.

What KQL table is used for suspicious email investigations?

EmailEvents is usually the starting point for Microsoft Defender XDR email investigations. UrlClickEvents, IdentityLogonEvents, DeviceProcessEvents and CloudAppEvents can then help validate click activity, identity behaviour and endpoint impact.

Does a DMARC failure always mean the email is malicious?

No. A DMARC failure is an important signal, but it needs context. Analysts should review sender alignment, delivery outcome, recipient targeting, message content and any user interaction before deciding impact.

Why compare SenderFromDomain and SenderMailFromDomain?

The visible sender is what the user sees, while the Mail From path helps show the underlying sending route. A mismatch may be normal for third-party services, but it should be validated when investigating suspicious mail.

Final Agent Foskett thought

Spoofing works because it borrows trust. Good KQL hunting helps you prove whether that trust was justified.
At GEMXIT, We use Microsoft hunting data to validate what is real, what only looks real, and what requires action across identity, email, endpoint and response.
Agent Foskett investigation mindset The question is never just “Did SPF fail?” It is “What did the message pretend to be, who trusted it, and what happened next?”

If you want help improving Microsoft email visibility, hunting, and operational response, 👉 review Microsoft security operations

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

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

Suspicious Email Investigation with KQL and EmailEvents

This page explains how GEMXIT uses Microsoft Defender XDR EmailEvents data to investigate suspicious email, authentication failures, sender alignment and delivery outcomes in Microsoft 365.

How to Validate Email Trust in Microsoft 365

Practical examples include AuthenticationDetails filtering, From versus Mail From comparison, internal-looking sender checks, campaign clustering and post-delivery pivots into user activity.

Microsoft 365 Suspicious Email Investigation by GEMXIT

GEMXIT uses KQL to turn email telemetry into evidence-led investigation paths across delivery context, identity trust, user behaviour and operational response.