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

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.

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.

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.

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?

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.

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