ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
EmailEvents • Sender Alignment • Microsoft Defender XDR • KQL Investigation

SenderFrom vs SenderMailFrom Explained

The email looked legitimate. The sender name looked familiar. The visible From address matched what the user expected.

But the mail system told a different story.

In Microsoft Defender EmailEvents, SenderFrom is the sender identity the user sees. SenderMailFrom is the envelope sender used during mail delivery. When those values do not align, the result may be normal platform behaviour — or it may be a spoofing signal worth investigating.

This Agent Foskett guide shows how to compare SenderFromAddress, SenderFromDomain, SenderMailFromAddress and SenderMailFromDomain using KQL, and how to decide whether the mismatch is expected, suspicious or part of a broader email attack.

The goal is simple: stop trusting the visible sender without checking the delivery evidence.

Discuss your environment Back to briefings
SenderFrom versus SenderMailFrom Microsoft Defender KQL investigation by GEMXIT
Sender alignment summary

A practical Microsoft Defender guide for understanding visible sender identity, envelope sender identity, domain mismatch, DMARC alignment and spoofing indicators in EmailEvents.

Compare visible and envelope sender fields
Identify suspicious sender mismatch
Pivot into AuthenticationDetails and DMARC
🚨 Why sender alignment matters
The user sees one sender. The mail system may process another.

The investigation question is not only: “Who did the email appear to come from?”
It is: “Does the visible sender match the technical sender and authentication evidence?”

👉 Or start with the full EmailEvents investigation guide
Book an email security review →

What these fields mean

SenderFrom and SenderMailFrom are not the same thing. Understanding the difference helps explain why an email looked trusted, why DMARC failed, and whether the message deserves deeper investigation.
1. SenderFromThe visible From identity. This is what the user normally sees in Outlook or the mail client.
2. SenderMailFromThe envelope sender used for technical delivery. This can differ from the visible sender, especially with bulk mail platforms.
3. Alignment questionThe key question is whether the mismatch is expected for that sender, platform and domain — or suspicious in context.

Baseline query: compare SenderFrom and SenderMailFrom

Use this query to review the visible sender fields and the envelope sender fields side by side.
senderfrom-vs-sendermailfrom-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
EmailEvents
| where Timestamp > ago(30d)
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Used forViewing the sender identity the user saw and the sender identity the mail system processed.
Why it mattersA mismatch can be legitimate, but it can also reveal spoofing, misalignment or unexpected delivery behaviour.
Best next stepCompare the sender fields with AuthenticationDetails, DMARC results and delivery outcome.
How to read this query
Start with SenderFromAddress because that is what the user saw. Then compare it with SenderMailFromAddress. If the domains differ, check whether the mismatch is expected for a legitimate sending platform or whether it conflicts with the authentication story.
Understand AuthenticationDetails →

Query: find sender domain mismatch

This query focuses on emails where the visible From domain does not match the envelope Mail From domain.
sender-domain-mismatch.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. 19
EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction
| order by Timestamp desc
Used forFinding visible sender and envelope sender mismatch in Microsoft Defender EmailEvents.
What to checkReview whether the sender is a known platform, expected newsletter, trusted third party or unexpected external source.
Agent Foskett tipA mismatch is not a conviction. It is a question that needs authentication and delivery context.
How to read this query
Look for familiar visible sender domains backed by unfamiliar Mail From domains. Then check the subject, recipient pattern, delivery action and authentication evidence before deciding whether the message is normal or suspicious.
Review spoofing detection →

Query: sender mismatch plus DMARC failure

A sender mismatch becomes more interesting when AuthenticationDetails also shows DMARC failure or other authentication concerns.
sender-mismatch-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
  17. 17
  18. 18
  19. 19
EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| where AuthenticationDetails has_any ("dmarc=fail", "spf=fail", "dkim=fail", "spoof")
| project
    Timestamp,
    SenderFromAddress,
    SenderFromDomain,
    SenderMailFromAddress,
    SenderMailFromDomain,
    RecipientEmailAddress,
    Subject,
    AuthenticationDetails,
    DeliveryAction,
    NetworkMessageId
| order by Timestamp desc
Used forPrioritising messages where sender mismatch and authentication signals appear together.
Why it mattersMismatch plus authentication failure is stronger than mismatch alone, especially if the message was delivered.
Best next stepReview DeliveryAction, check for repeated subjects and pivot into URL clicks using NetworkMessageId.
How to read this query
This is a higher-interest view. If the visible sender appears trusted, the envelope sender differs, and authentication signals failed, the email deserves review — especially if it reached the inbox or a user clicked.
Review delivered DMARC failures →

Query: group mismatched sender patterns

One mismatch may be normal. Repeated mismatches from the same sender, domain or subject can reveal campaign behaviour or a misconfigured third-party sender.
sender-mismatch-campaign-summary.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(30d)
| where SenderFromDomain != SenderMailFromDomain
| summarize
    MessageCount = count(),
    RecipientCount = dcount(RecipientEmailAddress),
    FirstSeen = min(Timestamp),
    LastSeen = max(Timestamp)
    by SenderFromDomain, SenderMailFromDomain, SenderFromAddress, Subject, DeliveryAction
| where MessageCount >= 3
| order by MessageCount desc
Used forGrouping sender mismatch activity so repeated patterns become visible.
What to checkLook for repeated subjects, multiple recipients, unexpected Mail From domains and short time windows.
Next stepSeparate legitimate bulk senders from suspicious impersonation attempts and follow delivered messages into clicks.

Investigation checklist

Use this checklist when sender fields do not align. The goal is not just to find mismatch. The goal is to understand whether the mismatch matters.
Review authenticationCheck AuthenticationDetails for SPF, DKIM, DMARC and CompAuth signals.

Understand authentication →
Review deliveryCheck whether the message was blocked, junked, allowed or delivered to the user.

Review delivered failures →
Review user actionIf the message was delivered, check whether the user clicked or interacted with the email.

Review click investigation →

Continue your investigation

This page is part of the wider Agent Foskett Microsoft Defender and KQL investigation path. Use it to connect sender alignment into authentication, spoofing, delivery and user behaviour.
EmailEvents KQL guideUnderstand sender fields, AuthenticationDetails, delivery actions and investigation pivots.

Open EmailEvents guide →
Email spoofing with KQLInvestigate spoofing indicators, sender mismatch, AuthenticationDetails and suspicious delivery outcomes.

Open spoofing guide →
KQL threat hunting guideConnect email, identity, endpoint, cloud activity and user behaviour into one investigation workflow.

Open KQL hub →
Need help reviewing Microsoft Defender sender alignment?
Finding sender mismatch is easy. Understanding whether it is normal, misconfigured or malicious is harder. GEMXIT helps organisations investigate EmailEvents, AuthenticationDetails, DMARC alignment, spoofing behaviour and Microsoft 365 email risk.
Book an Email Security Review →
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

SenderFrom vs SenderMailFrom Microsoft Defender KQL

Practical Microsoft Defender XDR KQL guide covering EmailEvents, SenderFromAddress, SenderFromDomain, SenderMailFromAddress, SenderMailFromDomain, sender mismatch, DMARC alignment, AuthenticationDetails and spoofed email investigations.

Detect sender mismatch in EmailEvents with KQL

This page targets practical searches for SenderFrom vs SenderMailFrom, SenderFromDomain mismatch, SenderMailFromDomain, EmailEvents sender alignment, DMARC fail delivered, spoofed sender domains and Microsoft Defender email investigation workflows.

GEMXIT Microsoft Security Operations

GEMXIT uses Microsoft Defender, Microsoft Sentinel and Entra ID to support practical security operations, KQL threat hunting, email security reviews and Microsoft 365 security assessments.