Agent Foskett • Microsoft Defender XDR • Email Investigation

The Email Passed SPF… But Was Still Malicious

SPF passed.

DKIM passed.

DMARC passed.

Microsoft 365 accepted the message. No high-severity alert triggered. The sender looked legitimate.

But something still felt wrong.

The user had received an email from a trusted supplier they communicated with regularly. The branding matched. The conversation thread looked genuine. The authentication checks all passed successfully.

Yet the investigation uncovered suspicious reply-to behaviour, unusual redirection patterns and indicators of account compromise.

This Agent Foskett briefing investigates a dangerous Microsoft 365 reality: authentication success does not always mean the email is safe.

Agent Foskett Microsoft Defender XDR SPF pass malicious email investigation
Briefing summary

Emails can successfully pass SPF, DKIM and DMARC authentication while still being malicious. GEMXIT investigates suspicious email behaviour, reply-chain abuse and compromised trusted senders inside Microsoft Defender XDR.

Investigate SPF pass emails
Hunt suspicious reply-chain activity
Review EmailEvents authentication data
🚨 SPF passing does not automatically mean safe.
Compromised vendors, reply-chain abuse, trusted SaaS platforms and account takeovers can all produce emails that pass authentication checks while still being dangerous.
Book a security review →

What happened

The message looked legitimate. Authentication succeeded. Microsoft 365 delivered the email successfully. But deeper investigation exposed behaviour that normal filtering alone would not detect.
Authentication passed SPF, DKIM and DMARC all passed successfully during message processing.
The email looked normal The sender matched an existing supplier relationship and the conversation thread appeared genuine.
The danger was behavioural Suspicious reply-to patterns, unusual URLs and account compromise indicators exposed the real risk.
The reply path changed The sender appeared trusted, but the response path and requested action did not match normal business behaviour.
The links needed review The visible message looked genuine, but the URL path and redirection behaviour needed to be investigated separately.
The logs still mattered EmailEvents, AuthenticationDetails and UrlClickEvents helped separate authenticated delivery from actual trust.

Why SPF pass does not always mean safe

SPF helps validate whether a sending server is authorised for a domain. It does not prove that the sender's account is uncompromised, that the message intent is safe, or that the user should trust the request.
Compromised accounts can pass If an attacker controls a real mailbox or trusted SaaS account, authentication can succeed because the source is legitimate.
Trusted platforms can be abused Email sent through legitimate services may authenticate correctly while still delivering a phishing workflow.
Authentication is not intent SPF, DKIM and DMARC validate technical alignment. They do not guarantee the business request is legitimate.

First hunt: review authentication results

Start by reviewing emails that passed authentication checks. Successful delivery does not remove the need for investigation.
email-authentication-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
  13. 13
  14. 14
EmailEvents
| where Timestamp > ago(7d)
| where AuthenticationDetails has "spf=pass"
| project Timestamp,
          SenderFromAddress,
          RecipientEmailAddress,
          Subject,
          AuthenticationDetails,
          ThreatTypes,
          DeliveryAction,
          NetworkMessageId
| order by Timestamp desc
What to review Look for messages where authentication passed but delivery, threat type, sender pattern or subject behaviour still deserves attention.
Why it matters Authentication success can make an email look clean, even when the surrounding behaviour is suspicious.
Best next pivot Use NetworkMessageId to pivot into URLs, clicks, attachments, delivery actions and user activity.

Second hunt: investigate suspicious reply chains

One of the most dangerous attacks is a compromised trusted sender. Authentication still succeeds because the account itself is legitimate.
suspicious-reply-chain-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
  13. 13
  14. 14
  15. 15
EmailEvents
| where Timestamp > ago(14d)
| where Subject has_any ("RE:", "FW:", "invoice", "payment")
| project Timestamp,
          SenderFromAddress,
          ReplyToAddress,
          Subject,
          RecipientEmailAddress,
          AuthenticationDetails,
          ThreatTypes,
          NetworkMessageId
| order by Timestamp desc
What to review Look for trusted senders sending unusual payment, invoice, credential or document requests inside reply threads.
Why it matters Reply-chain abuse can bypass user suspicion because the conversation context already feels familiar.
Best next pivot Compare the sender, reply-to address, URL domains and recent communication history with the same contact.

Third hunt: investigate URL behaviour

Safe-looking emails often become dangerous only after the user interacts with links inside the message.
suspicious-url-click-investigation.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
UrlClickEvents
| where Timestamp > ago(7d)
| project Timestamp,
          AccountUpn,
          Url,
          ActionType,
          IPAddress,
          NetworkMessageId
| order by Timestamp desc
What to review Review whether a user clicked, whether the click was allowed, and whether the link redirected to unexpected infrastructure.
Why it matters The email may have passed authentication, but the post-delivery user journey can reveal the attack.
Best next pivot Use NetworkMessageId to correlate the clicked URL back to the original email and recipient.

Where this becomes dangerous

The danger is not that SPF passed. The danger is believing SPF pass is the end of the investigation.
Business email compromise Attackers can use trusted conversations to redirect payments, request documents or change bank details.
Credential harvesting A legitimate-looking email may send users to a fake Microsoft sign-in page or document portal.
Supplier compromise The message may authenticate because the attacker is sending from a real supplier account.

What should organisations do?

Email authentication is essential, but it should be one layer in a wider investigation model. Trust should be validated through sender behaviour, user action, URL analysis and business context.
Review authentication and behaviour Do not stop at SPF, DKIM or DMARC. Review the sender, message pattern, URLs, recipients and requested action.
Correlate EmailEvents and UrlClickEvents Use Microsoft Defender XDR to connect the delivered message with clicks, delivery actions and affected users.
Escalate unusual business requests Payment changes, document requests and credential prompts should be verified through a separate trusted channel.

How GEMXIT approaches Microsoft Defender email investigations

At GEMXIT, we do not simply ask whether an email passed authentication. We investigate whether the email should be trusted.
We review Defender telemetry EmailEvents, AuthenticationDetails, UrlClickEvents and message identifiers help trace the full investigation path.
We validate the business context Trusted sender history, reply chains, supplier relationships and requested actions are reviewed together.
We reduce practical risk The goal is not only to improve filtering. The goal is to stop dangerous emails from becoming business incidents.
The email passed SPF. The investigation was not finished.
GEMXIT helps organisations review Microsoft Defender XDR, Microsoft 365 email security, KQL hunting queries, DMARC alignment and suspicious email behaviour before small signals become real incidents.
Contact GEMXIT

Final thought

SPF is important.

DKIM is important.

DMARC is important.

But authentication alone is not the full investigation.

Sometimes the most dangerous emails are the ones that technically look legitimate.
At GEMXIT We help organisations review Microsoft 365, Defender XDR, email authentication, DMARC alignment, suspicious sender behaviour, URL click telemetry and business email compromise risks before they become incidents.
Agent Foskett mindset The important question is not only: “Did the email pass SPF?”

It is: “Should this email still be trusted?”

Microsoft Defender SPF Pass Investigation

This Agent Foskett briefing explains how malicious emails can pass SPF, DKIM and DMARC authentication checks while still presenting phishing, reply-chain abuse and business email compromise risk inside Microsoft 365 and Microsoft Defender XDR.

EmailEvents AuthenticationDetails Investigation

GEMXIT helps organisations investigate AuthenticationDetails, EmailEvents, UrlClickEvents, ReplyToAddress, ThreatTypes, DeliveryAction, NetworkMessageId and suspicious sender behaviour in Microsoft Defender XDR.

SPF Pass Does Not Always Mean Safe

Example investigation areas include compromised trusted senders, malicious emails that pass authentication, suspicious URLs, reply-chain abuse, credential harvesting, business email compromise and Microsoft 365 email security reviews.