Friday Cyber Briefing • Exchange Online • Microsoft Defender for Office 365 • Email Headers
I Blocked The Domain... So Why Did The Email Still Arrive?
The domain was blocked.
Yet the email still arrived.
Had Microsoft 365 ignored the policy?
Agent Foskett checked the Internet headers.
The answer was no.
Exchange Online authenticated the sender, classified the message as high-confidence spam and delivered it to Junk.
Message-Header Investigation
The visible sender raised the question. The Internet headers explained the authentication, spam verdict and final delivery location.
Verify SPF, DKIM and DMARC
Interpret SCL and spam category
Confirm the final delivery action
The block looked ineffective
A marketing email from the same domain appeared again, even though the domain had already been added to a Microsoft 365 anti-spam block list.
10:21 — Message received
An unsolicited marketing email arrived from
thinkbusinessstrategy.life.
10:23 — Existing block confirmed
The sender's domain was already present in the organisation's anti-spam policy.
10:27 — Headers reviewed
The full Internet headers revealed how Exchange Online authenticated, scored and delivered the message.
The sender was real
The first important finding was that the visible From address had not simply been spoofed. The sender authenticated successfully using its own domain.
- 1
- 2
- 3
- 4
- 5
- 6
spf=pass smtp.mailfrom=thinkbusinessstrategy.life
dkim=pass header.d=thinkbusinessstrategy.life
dmarc=pass header.from=thinkbusinessstrategy.life
compauth=pass reason=100
Authentication did not mean the message was safe
SPF, DKIM and DMARC answered one question: did this domain genuinely send the email? They did not answer whether the recipient wanted it.
SPF validated the sending IP
The domain authorised the connecting server to send mail on its behalf.
DKIM validated the signature
The cryptographic signature matched the sending domain and the signed content had not been altered.
DMARC validated alignment
The authenticated domains aligned with the visible From domain, confirming the sender's identity.
Exchange Online had already called it spam
The most important clue appeared in the Microsoft anti-spam headers.
- 1
- 2
- 3
- 4
- 5
X-MS-Exchange-Organization-SCL: 9
CAT:HSPM
BCL:8
What those values meant
The message was authenticated, but Microsoft still assessed its content and sending behaviour as unwanted bulk mail.
SCL 9 — High confidence spam
A Spam Confidence Level of 9 represents Microsoft's strongest spam classification.
CAT:HSPM — High-confidence spam
The Forefront classification explicitly identified the message as high-confidence spam.
BCL 8 — Bulk mail
The Bulk Complaint Level indicated a strong likelihood that the message came from bulk-marketing infrastructure.
The final delivery action
The mailbox-delivery header confirmed that Exchange Online had not placed the message in the Inbox.
- 1
- 2
- 3
- 4
- 5
dest:J
OFR:SpamFilterAuthJ
RF:JunkEmail
The message did not bypass Microsoft 365
The filtering system had accepted the authenticated connection, evaluated the message as high-confidence spam and routed it to Junk.
The identity was verified
The domain genuinely sent the message. Authentication worked as designed.
The content was assessed separately
Microsoft's anti-spam engine recognised unwanted bulk-mail characteristics despite successful authentication.
The message was sent to Junk
The final delivery headers confirmed that the message was filtered rather than allowed into the Inbox.
Why a blocked domain can still appear
A block-list entry does not always produce an invisible deletion. The outcome depends on where the block was configured, which policy applied and what action that policy assigns.
Policy actions matter
A blocked or high-confidence spam message may be routed to Junk or quarantine instead of being silently deleted.
Policy precedence matters
A different inbound anti-spam policy may apply to the recipient before the administrator's expected policy.
Delivery location matters
Seeing a message in Junk does not mean it reached the Inbox or escaped anti-spam processing.
When complete rejection is required
If the business never wants to accept mail from a particular domain, an Exchange Online mail flow rule can provide a more explicit outcome.
Reject the message
Return a non-delivery response so the sending system knows the organisation refused the email.
Quarantine the message
Keep the email away from user mailboxes while retaining evidence for administrator review.
Delete without notification
Silently remove the message, recognising that this option can make troubleshooting and auditing more difficult.
What administrators should inspect
Before changing policies, build the delivery story from the headers and Microsoft 365 message trace.
Authentication-Results
Check SPF, DKIM, DMARC and composite authentication before deciding whether the visible sender was spoofed.
Anti-spam verdicts
Review SCL, category, BCL and filtering details to understand Microsoft's classification.
Final delivery result
Confirm whether the message reached the Inbox, Junk, quarantine or another destination.
Investigation lessons
Email authentication, spam classification and policy enforcement are related controls, but they do not answer the same question.
Authentication proves identity
SPF, DKIM and DMARC can confirm who sent an email without confirming that the email is desirable or safe.
Spam scoring decides treatment
Exchange Online applies content, reputation and behavioural analysis after authentication.
Headers explain the decision
The message headers often reveal more than the visible From address or the mailbox folder alone.
Related Agent Foskett investigations
Continue with practical investigations covering email identity, spoofing, authentication, malicious delivery and the evidence hidden inside Microsoft security telemetry.
AuthenticationDetails Explained
Understand how Microsoft records SPF, DKIM, DMARC and composite authentication results in email telemetry.
The Invoice Wasn't An Email. It Was A Calendar Invite.
Attackers can deliver social-engineering content through channels users may trust differently.
The User Opened The Attachment Two Days Later
Delivery and execution may occur at different times, making timeline reconstruction essential.
The QR Code Was Trusted
Trusted-looking content can move users away from the controls that normally inspect links.
Email Spoofing KQL
Hunt for sender mismatches, authentication failures and suspicious email identity signals.
EmailEvents KQL Guide
Investigate delivery actions, authentication details, threats and sender information in Defender XDR.
Final thought
The domain was blocked. The email still appeared. The headers showed why.
The sender proved its identity
The successful authentication results showed that this was genuine mail from the sending domain, not a simple spoof.
Microsoft still identified the spam
SCL 9 and CAT:HSPM showed that Exchange Online recognised the message as high-confidence spam.
The headers told the whole story
The control had not been bypassed. It had accepted, classified and redirected the message according to policy.
