ACSC Logo
© 2026 GEMXIT
GEMXIT Logo
Agent Foskett Academy • Lesson 53 • Email Investigation

Investigating SenderFromAddress vs SenderMailFromAddress in Microsoft Defender XDR.

The sender looked familiar.

The display name looked trusted.

The email address looked close enough.

But the message transport evidence told a different story.

In Microsoft Defender XDR, SenderFromAddress and SenderMailFromAddress help defenders compare what the user saw with how the email was actually sent.

Start Lesson 53 Back to Academy
Agent Foskett Academy lesson explaining SenderFromAddress and SenderMailFromAddress in Microsoft Defender XDR
Lesson overview

Learn how to compare visible sender information with the envelope sender evidence used during Microsoft 365 email transport.

Compare visible and transport sender fields
Investigate phishing and spoofing evidence
Add authentication and DMARC context
Understand why sender mismatch matters

Why sender fields matter

Email investigations often begin with the sender. The problem is that email has more than one sender field, and each one tells a different part of the story.
The user sees one senderSenderDisplayName and SenderFromAddress are usually the values the user notices in the inbox.
Mail transport may show another senderSenderMailFromAddress reflects the envelope sender used during message delivery and SPF evaluation.
The difference can explain the riskA mismatch may be normal for bulk senders, but it can also reveal spoofing, impersonation or suspicious mail flow.

The fields used in this lesson

These fields help defenders compare what the email claimed to be with how it was actually transmitted.
SenderDisplayNameThe friendly name shown to the recipient, such as Microsoft Support, Accounts Payable or a known executive.
SenderFromAddressThe visible From address in the message. This is often what the recipient assumes is the sender.
SenderMailFromAddressThe envelope sender used during SMTP transport. This is often important for SPF and sender alignment checks.
SenderFromDomainThe domain portion of the visible sender address.
SenderMailFromDomainThe domain portion of the envelope sender address.
EmailAuthenticationResultsAuthentication context that helps explain whether the sender relationship was expected or suspicious.

Step 1 — Review sender evidence

Start with the basic sender fields so you can see what the user saw and what mail transport recorded.
sender-fields-basic-review.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(30d)
| project Timestamp,
          SenderDisplayName,
          SenderFromAddress,
          SenderMailFromAddress,
          RecipientEmailAddress,
          Subject
| order by Timestamp desc

Step 2 — Find sender mismatches

A mismatch between SenderFromAddress and SenderMailFromAddress is not automatically malicious, but it is worth reviewing during phishing and spoofing investigations.
find-sender-address-mismatches.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(30d)
| where SenderFromAddress != SenderMailFromAddress
| project Timestamp,
          SenderFromAddress,
          SenderMailFromAddress,
          RecipientEmailAddress,
          Subject,
          DeliveryAction
| order by Timestamp desc

Step 3 — Compare sender domains

Domain comparison is often easier to review than full addresses. This helps defenders identify visible sender domains that do not align with the envelope sender domain.
compare-visible-and-envelope-domains.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
EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| project Timestamp,
          SenderFromDomain,
          SenderMailFromDomain,
          SenderFromAddress,
          SenderMailFromAddress,
          Subject,
          DeliveryAction
| order by Timestamp desc

Step 4 — Add authentication context

Sender mismatch becomes more meaningful when reviewed alongside SPF, DKIM, DMARC and composite authentication results.
sender-mismatch-with-authentication.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
| project Timestamp,
          SenderFromAddress,
          SenderMailFromAddress,
          EmailAuthenticationResults,
          AuthenticationDetails,
          DeliveryAction,
          Subject
| order by Timestamp desc

Step 5 — Focus on messages that reached users

Delivered sender mismatches deserve attention because the message reached a mailbox and may have influenced a user.
delivered-sender-mismatches.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
EmailEvents
| where Timestamp > ago(30d)
| where SenderFromDomain != SenderMailFromDomain
| where DeliveryAction =~ "Delivered"
| project Timestamp,
          SenderFromAddress,
          SenderMailFromAddress,
          RecipientEmailAddress,
          Subject,
          NetworkMessageId
| order by Timestamp desc

How to read the results

The goal is not to panic every time the fields differ. The goal is to understand whether the relationship makes sense.
Expected mismatchA legitimate marketing platform or transactional mail provider may send on behalf of a trusted domain.
Suspicious mismatchThe visible sender imitates a trusted organisation, but the envelope sender belongs to an unrelated or suspicious domain.
High-value mismatchThe visible sender references an executive, vendor, bank, Microsoft or another trusted brand and the authentication evidence does not support the claim.

Common investigation uses

SenderFromAddress and SenderMailFromAddress help defenders investigate email trust, sender alignment and impersonation risk.
Phishing investigationsIdentify messages where the sender shown to the user does not match the sender used during transport.
DMARC investigationsReview whether visible sender domains align with authentication and envelope sender evidence.
Business email compromiseValidate whether an apparent supplier, executive or trusted contact was genuinely represented by the sending infrastructure.

Common mistakes

Sender investigations become unreliable when defenders trust one field without comparing the full sender story.
Trusting the display nameAttackers can make a display name look convincing. Display names are evidence, not proof.
Ignoring the envelope senderSenderMailFromAddress helps explain how the message was actually sent and authenticated.
Forgetting authentication resultsSender mismatch without SPF, DKIM, DMARC and delivery context can lead to the wrong conclusion.
The sender shown to the user is not always the sender that transmitted the email.
Compare the visible sender, envelope sender and authentication evidence before deciding whether the message can be trusted.
Back to Academy →

What you learned

Sender fields have different meaningsSenderFromAddress reflects the visible sender, while SenderMailFromAddress reflects transport-level sender evidence.
Mismatches require contextA mismatch may be legitimate or suspicious depending on authentication, delivery and sender relationship evidence.
Email trust must be provenDefenders should compare what the user saw against what Microsoft Defender XDR recorded.

Related Agent Foskett Academy lessons

Investigating EmailEventsStart with core email evidence including sender, recipient, subject and delivery fields.
Investigating EmailAuthenticationResultsAdd SPF, DKIM, DMARC and composite authentication context.
Investigating NetworkMessageIdFollow the same email across related Defender XDR tables.
Investigating UrlClickEventsConfirm whether users clicked links from suspicious email.
Investigating EmailAttachmentInfoReview attachment names, hashes and payload evidence.
Investigating EmailUrlInfoInvestigate URLs extracted from email messages.
Connecting Tables with joinCombine evidence from related tables into one investigation.
The Timeline Told The StoryCombine evidence across email, identity, cloud and incident telemetry.

Coming next

Lesson 54 — Investigating DeliveryLocation in Microsoft Defender XDRNext, Agent Foskett Academy will continue email investigations by showing how defenders determine whether a message reached the inbox, junk folder, quarantine or another destination.
Why this mattersAfter identifying the sender and authentication result, defenders need to know where the email actually went.
What you will learn nextLearn how delivery location and delivery action help explain whether a message reached users or was contained by policy.

Final thought

The inbox showed one sender. The transport evidence showed another.
Agent Foskett mindsetDo not trust the sender because it looks familiar. Prove the sender relationship with telemetry.
Compare the fieldsSenderFromAddress and SenderMailFromAddress are strongest when reviewed together.
Develop IT. Protect IT.GEMXIT PTY LTD | GEMXIT UK LTD
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT 2026

Investigating SenderFromAddress vs SenderMailFromAddress in Microsoft Defender XDR

Agent Foskett Academy Lesson 53 teaches defenders how to compare SenderFromAddress and SenderMailFromAddress during Microsoft Defender XDR email investigations.

Learn sender field comparison for Defender XDR email investigations

This lesson explains how sender mismatch evidence supports phishing, spoofing, impersonation and DMARC investigations by comparing visible sender fields, envelope sender fields, authentication results and delivery outcomes.