EmailEvents • Sender Identity • Microsoft Defender XDR

The Sender Wasn't Really The Sender

The display name looked familiar.

The visible sender looked trusted.

But the envelope sender, return path and authentication details told a different story.

Agent Foskett investigation into sender identity fields in Microsoft Defender XDR EmailEvents
Briefing summary

An email appeared to come from a trusted sender, but Microsoft Defender XDR showed the sender identity did not align. Agent Foskett compared SenderFromAddress, SenderMailFromAddress, ReturnPath, SpoofedDomain and authentication results to determine who really sent the message.

Visible From looked trusted
Envelope sender told another story
EmailEvents exposed the mismatch

What happened

The message looked like it came from a known organisation. The data showed the identity was not that simple.
The display name looked right The email appeared to come from a familiar sender. To the recipient, the message looked routine enough to trust.
The sender fields did not align SenderFromAddress, SenderMailFromAddress and ReturnPath did not tell the same story. The visible identity and sending infrastructure were different.
The investigation shifted The question was no longer what the email claimed. The question became which identity actually controlled the delivery path.

The fields that changed the investigation

In Microsoft Defender XDR, sender identity is not a single field. It is a comparison.
sender-identity-investigation.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
EmailEvents
| where Timestamp > ago(7d)
| project Timestamp, RecipientEmailAddress,
          SenderFromAddress, SenderMailFromAddress,
          SenderDisplayName, ReturnPath,
          SpoofedDomain, AuthenticationDetails,
          EmailDirection, DeliveryAction
SenderFromAddress The visible From address shown to the user. This is often the field attackers want the recipient to trust.
SenderMailFromAddress The envelope sender used during SMTP handling. This can reveal infrastructure that does not match the visible From address.
ReturnPath The bounce path can expose the real sending service, marketing platform, compromised system or attacker-controlled infrastructure.

Agent Foskett moment

The user saw one sender. Defender telemetry showed several.
The visible sender was the lure Attackers rely on the fact that people usually read the display name and From address, not the delivery path behind the message.
The envelope sender was the clue When the envelope sender and visible sender do not align, the investigation should slow down and compare the evidence.
Authentication was not the whole answer SPF, DKIM or DMARC outcomes matter, but they must be interpreted alongside sender alignment, SpoofedDomain and message intent.

What most environments miss

Sender investigations fail when teams only look at the name at the top of the email.
Display names are weak evidence A display name can say Microsoft, finance, payroll or a supplier. That does not prove who sent the message.
Alignment matters The strongest clue is often the mismatch between visible identity, envelope identity, authentication domain and the link destination.
Passed authentication still needs context A message can pass technical checks for a sending domain and still impersonate a brand, supplier or internal process.

How defenders can investigate it

Treat sender identity as a set of signals, not a single value.
Compare sender fields Review SenderFromAddress, SenderMailFromAddress, SenderDisplayName, ReturnPath and any domain mismatch across the message.
Review authentication details Check AuthenticationDetails and EmailAuthenticationResults for SPF, DKIM, DMARC and composite authentication outcomes.
Pivot into intent Correlate the message with UrlClickEvents, EmailAttachmentInfo and similar subjects to determine whether the mismatch was accidental or malicious.

Related investigations

SpoofedDomain In EmailEvents Microsoft Defender email telemetry can reveal when a message attempts to impersonate a trusted domain. Read more →
EmailEvents KQL Guide Learn how to investigate sender, recipient, delivery and authentication signals in Microsoft Defender XDR. Read more →
AuthenticationDetails Explained Authentication details help explain how SPF, DKIM, DMARC and composite authentication contributed to the verdict. Read more →
The EmailAuthenticationResults Looked Fine A message can look technically acceptable while still being suspicious when sender identity and intent are reviewed together. Read more →
The Disney Email Wasn't From Disney A familiar brand can make a message feel safe until the sender, link and authentication details are reviewed. Read more →
The Email Came From Me Display names, spoofing and sender authentication must be reviewed together before trusting the visible sender. Read more →
The From address made a claim.
The sender fields provided the evidence.
Contact GEMXIT

Final thought

In email investigations, the sender is not who the display name says it is. The sender is what the telemetry proves.
At GEMXIT We help organisations investigate Microsoft Defender XDR telemetry, EmailEvents, sender authentication, spoofing patterns, phishing risk and Microsoft 365 identity compromise. If you want to understand how this applies to your environment, see our Cyber Security services.
Agent Foskett mindset Do not stop at the From field. Compare the envelope sender, return path, authentication results, spoofed domain and the action the email is trying to create.

The display name looked trusted, but EmailEvents showed the visible sender, envelope sender and return path were not aligned. Explore related investigations including SpoofedDomain In EmailEvents, EmailEvents KQL Guide, and AuthenticationDetails Explained.

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

Sender Identity Investigation In Microsoft Defender XDR

This Agent Foskett briefing explains how to compare SenderFromAddress, SenderMailFromAddress, SenderDisplayName, ReturnPath, SpoofedDomain and AuthenticationDetails during Microsoft Defender XDR email investigations.

EmailEvents SenderFromAddress SenderMailFromAddress ReturnPath

EmailEvents can help defenders identify sender mismatches by comparing the visible From address with the envelope sender, return path and authentication results.

Email Spoofing And Sender Alignment

Not every suspicious email relies on malware or attachments. Some attacks depend on sender identity confusion, display name trust and delivery infrastructure that does not match the visible claim.