Lesson 45 — The Message Passed Authentication — But Was Still Suspicious
The analyst opened the email evidence and found something reassuring.
SPF: Pass.
DKIM: Pass.
DMARC: Pass.
Case closed?
Not quite.
The message was asking the recipient to urgently review a payment request through an unfamiliar website.
Agent Foskett looked at the authentication results again.
The question was not simply whether the email authenticated. The question was: what exactly had authenticated?
Everything passed
SPF, DKIM and DMARC results are valuable evidence, but the SOC still has to determine which domain authenticated and whether the message itself makes sense.
Case briefing
Investigation objective
Interpret email authentication results correctly, identify the domains involved and combine authentication with sender, URL, delivery and business-context evidence before reaching a verdict.
Investigator's rule
Authentication answers a technical identity question. It does not answer whether the sender's story is true.
Stage 1 — retrieve the message evidence
EmailEvents
| where Timestamp > ago(7d)
| where Subject =~ "Urgent Payment Review"
| project Timestamp,
NetworkMessageId,
SenderDisplayName,
SenderFromAddress,
SenderFromDomain,
SenderMailFromAddress,
SenderMailFromDomain,
RecipientEmailAddress,
DeliveryAction,
DeliveryLocation
| order by Timestamp desc
Start with the domains
Compare the visible sender identity with the actual sender address, sender domain and envelope sender information recorded by Microsoft 365.
Do not let a familiar name win
A display name such as “Contoso Accounts Team” is presentation. It should not override evidence showing that the message originated from an unrelated domain.
Stage 2 — inspect the authentication details
let MessageId = "<NETWORK-MESSAGE-ID>";
EmailEvents
| where NetworkMessageId == MessageId
| project Timestamp,
SenderFromAddress,
SenderFromDomain,
SenderMailFromDomain,
AuthenticationDetails,
ThreatTypes,
DetectionMethods,
DeliveryAction,
DeliveryLocation
AuthenticationDetails is evidence
Review the recorded authentication results alongside the domains involved. A pass becomes meaningful only when the analyst understands which identity the result supports.
Ask the better question
Instead of asking only “Did DMARC pass?”, ask “Which domain passed DMARC, and is that the organisation the user believed they were dealing with?”
Stage 3 — understand what the controls tell you
| Control | What it helps establish | What it does not establish |
|---|---|---|
| SPF | Whether the sending infrastructure is authorised for the relevant envelope domain. | That the business request is genuine. |
| DKIM | Whether a message carries a valid cryptographic signature for the signing domain. | That the domain belongs to the company the sender claims to represent. |
| DMARC | Whether SPF and/or DKIM authentication aligns appropriately with the visible From domain under DMARC rules. | That an attacker-controlled but correctly configured domain is trustworthy. |
Attackers can authenticate their own domains
An attacker who controls a domain can configure SPF, DKIM and DMARC correctly. Successful authentication may therefore prove that the attacker sent an authentic message from their domain.
Pass does not mean safe
Authentication reduces some forms of sender spoofing. It is not a universal phishing verdict and should never replace analysis of the sender identity, content, links and context.
Stage 4 — compare the claimed identity with the authenticated identity
Technical authenticity and business legitimacy differ
The SOC needs both. A technically authenticated message can still use social engineering, look-alike branding or misleading business context.
Expected domains matter
Business knowledge helps the analyst recognise when a supplier, executive or internal department is suddenly represented by a domain that has never been part of the legitimate relationship.
Stage 5 — inspect the URLs
let MessageId = "<NETWORK-MESSAGE-ID>";
EmailUrlInfo
| where NetworkMessageId == MessageId
| project Timestamp,
NetworkMessageId,
Url,
UrlDomain
| order by Timestamp asc
Compare sender and destination
A message from one unfamiliar domain directing the recipient to a second unrelated domain adds another layer of evidence that deserves investigation.
The URL may tell a different story
Even when the sender domain looks plausible, the destination may expose the true objective of the message: credential harvesting, fake payment portals or malicious content.
Stage 6 — scope the sender domain
EmailEvents
| where Timestamp > ago(7d)
| where SenderFromDomain =~ "contoso-payment-review.com"
| summarize
Messages = count(),
Recipients = dcount(RecipientEmailAddress),
Subjects = make_set(Subject, 20)
by SenderFromDomain
| order by Messages desc
One message or a campaign?
If the same authenticated domain has contacted many recipients with similar subjects, the incident may be part of a broader phishing campaign rather than a single-user event.
Authentication can actually strengthen attribution
Once the SOC understands that the suspicious domain itself authenticated correctly, repeated messages from that domain can be grouped and investigated as activity tied to the same sending identity.
Stage 7 — combine the evidence
Stage 8 — avoid the two authentication mistakes
| Mistake | Better SOC reasoning |
|---|---|
| “DMARC passed, so it is legitimate.” | Identify the aligned domain and determine whether that domain itself is trustworthy and expected. |
| “The domain is suspicious, so authentication must have failed.” | An attacker-controlled domain may authenticate perfectly. Treat authentication and legitimacy as separate questions. |
Stage 9 — write the investigation finding
Lesson 45 key takeaways
- SPF, DKIM and DMARC results are important evidence, but they are not a complete phishing verdict.
- Always determine which domain an authentication result supports.
- A display name does not prove sender identity.
- Attackers can correctly configure authentication for domains they control.
- A DMARC pass can coexist with a deceptive or attacker-controlled domain.
- Compare the sender domain with the organisation the message claims to represent.
- Inspect URL domains independently of sender authentication.
- Business context remains part of email investigation.
- Scope suspicious authenticated domains across other recipients.
- Technical authenticity does not automatically equal business legitimacy.
Module 5 — Email & Phishing: From Message to Compromise
Lesson 45 showed why successful authentication does not end a phishing investigation. Lesson 46 follows the incident into identity response after the user confirms they entered their credentials.
Continue your SOC Analyst training
🔎 SOC Analyst Academy — Module 5: Email & Phishing: From Message to Compromise
SPF DKIM and DMARC pass but email is still suspicious
Lesson 45 of the Agent Foskett SOC Analyst Academy explains why successful email authentication does not automatically make a message legitimate. SOC analysts learn to compare sender domains, authentication details, URL domains and business context in Microsoft Defender XDR.
Investigate authenticated phishing emails with Microsoft Defender XDR
Use EmailEvents and EmailUrlInfo in Advanced Hunting to determine which domain authenticated, identify deceptive or attacker-controlled domains, scope related messages and build a defensible phishing verdict.
