Agent Foskett Investigation • Email Security • SPF • Microsoft Defender XDR • KQL
The SPF Check Passed... For The Wrong Domain
The email looked legitimate.
The visible sender used a familiar company name.
Microsoft Defender recorded SPF = Pass.
Everyone assumed the sender had been authenticated.
Nobody asked which domain SPF had actually checked.
Email Authentication Investigation
SPF passed. The visible sender still did not deserve trust.
Compare visible and envelope sender domains
Inspect raw authentication evidence
Use KQL to find domain misalignment
The message looked authenticated
Every visible clue encouraged the analyst to trust the sender.
Familiar visible senderThe From address displayed a recognised organisation and looked appropriate for the message.
SPF passedThe sending infrastructure was authorised for the domain used during the SMTP envelope transaction.
The investigation stopped earlyThe analyst treated an SPF pass as proof that the visible sender identity was legitimate.
SPF passed—but for which identity?
SPF normally evaluates the envelope sender domain. It does not automatically validate the visible From domain shown to the recipient.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
Visible From address: accounts@trusted-brand.example Envelope sender: bounce@mailer-platform.example SPF result: PASS — for mailer-platform.example
The first KQL question
Start by putting both sender identities and the authentication evidence in the same result.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
EmailEvents
| where Timestamp > ago(7d)
| project Timestamp,
Subject,
SenderFromAddress,
SenderMailFromAddress,
AuthenticationDetails,
NetworkMessageId
Find messages where the domains do not align
A mismatch is not automatically malicious, but it is a valuable investigation lead—especially when branding, urgency or payment instructions are involved.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
EmailEvents
| where Timestamp > ago(7d)
| extend VisibleFromDomain = tostring(split(SenderFromAddress, "@")[1])
| extend EnvelopeFromDomain = tostring(split(SenderMailFromAddress, "@")[1])
| where isnotempty(VisibleFromDomain)
| where isnotempty(EnvelopeFromDomain)
| where VisibleFromDomain != EnvelopeFromDomain
| project Timestamp,
Subject,
SenderFromAddress,
SenderMailFromAddress,
AuthenticationDetails,
NetworkMessageId
Narrow the results to SPF evidence
AuthenticationDetails can be inspected as raw text first. This avoids assuming a structure before seeing how the tenant presents the field.
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
EmailEvents
| where Timestamp > ago(7d)
| extend VisibleFromDomain = tostring(split(SenderFromAddress, "@")[1])
| extend EnvelopeFromDomain = tostring(split(SenderMailFromAddress, "@")[1])
| where VisibleFromDomain != EnvelopeFromDomain
| where tostring(AuthenticationDetails) has "spf"
| project Timestamp,
SenderFromAddress,
SenderMailFromAddress,
AuthenticationDetails,
DeliveryAction,
DeliveryLocation
What each field tells the investigator
No single field proves the message is safe. Together, they explain how the sender presented itself and how the service evaluated it.
SenderFromAddressThe visible From identity presented to the recipient and commonly associated with the displayed sender.
SenderMailFromAddressThe envelope sender used during SMTP delivery and the identity normally evaluated by SPF.
AuthenticationDetailsThe authentication evidence used to inspect SPF, DKIM, DMARC and composite authentication outcomes.
DeliveryActionShows what Microsoft 365 did with the message during delivery.
DeliveryLocationShows where the message ultimately landed, including inbox, junk or quarantine outcomes.
NetworkMessageIdProvides a useful correlation key for continuing the investigation across related email telemetry.
Why a mismatch can be legitimate
Marketing systems, ticketing platforms and other third-party senders often use different envelope and visible domains. Context determines whether the mismatch is expected.
Approved sending platformA legitimate organisation may authorise a specialist platform to send on its behalf.
Expected authentication alignmentDKIM, DMARC and composite authentication may provide the additional alignment needed to establish trust.
Known business relationshipSender reputation, message history and expected business activity can explain the difference.
Why attackers benefit from the confusion
A technically valid SPF pass can look reassuring when the recipient never sees the domain that actually passed.
The visible brand attracts trustThe recipient focuses on the familiar From name and address.
The attacker's domain passes SPFThe attacker can legitimately authorise infrastructure to send for a domain they control.
The analyst stops at “Pass”The technical result is mistaken for validation of the visible sender identity.
Agent Foskett's investigation mindset
Authentication results are evidence—not verdicts.
Do not ask only: Did SPF pass?A pass result is incomplete without knowing which domain was evaluated.
Ask: Does the domain align?Compare the visible From identity with the envelope sender and the wider authentication results.
Ask: Does the message deserve trust?Review the content, sender history, links, attachments, delivery outcome and authentication together.
Investigation findings
SPF worked exactly as designed. The misunderstanding came from trusting the wrong identity.
SPF did not failThe sending server was authorised for the envelope sender domain.
The domains did not alignThe identity seen by the user differed from the identity authenticated by SPF.
KQL exposed the differenceMicrosoft Defender XDR placed the sender fields and authentication evidence into one investigation view.
Related Agent Foskett investigations
Continue with email authentication, sender identity and Microsoft Defender XDR investigations.
SenderFromAddress vs SenderMailFromAddressCompare the visible and envelope sender identities in Microsoft Defender XDR.
The Email Passed SPF But Was Still MaliciousSee why one successful authentication control does not make a message safe.
SPF, DKIM and DMARC Passed—Why Did Composite Authentication Fail?Investigate how Microsoft combines authentication evidence into a broader trust decision.
The DMARC Failure Was The First ClueFollow an authentication anomaly into a complete spoofing investigation.
EmailEvents KQL GuideLearn the Microsoft Defender XDR fields used throughout email investigations.
Agent Foskett AcademyBuild practical KQL and Microsoft security investigation skills through structured lessons.
Final thought
SPF can be completely correct while the recipient still trusts the wrong sender.
SPF authenticated a domainThe sending infrastructure was authorised for the envelope identity.
The investigator compared the identitiesThe visible From domain and envelope sender domain told different stories.
Trust required more than “Pass”The complete authentication and message context determined whether the email deserved trust.
