Passed every authentication check. Still landed in Junk.
An enterprise client sending through Salesforce Marketing Cloud reported that their email consistently landed in Outlook's Junk folder, despite SPF, DKIM, and DMARC all passing, no blacklist listings anywhere, and enterprise-grade sending infrastructure. The objective was simple: find out why Outlook considered it spam. The answer turned out to have almost nothing to do with authentication.
This engagement is covered by a signed NDA, so client identity, domains, hostnames, and IP addresses in this write-up have been altered. The diagnostic path and findings are unchanged.
- Original .EML: provided by the client
- Microsoft message headers: pulled directly from Outlook
- SMTP route: reconstructed from the headers
- MX header forensics: full field-by-field analysis
- DNS audit: run through DNSPulse
- Infrastructure audit: run through DNSPulse
SCL: 5
SFV: SPM · CAT: SPM
BCL: 0
CompAuth: pass
This one read immediately ruled out SPF, DKIM, DMARC, and bulk-sender status as the cause. Microsoft's own header was saying: identity accepted, reputation not.
Phase 3 · Authentication investigation
Before trusting the header's implication, every authentication mechanism was verified independently rather than taken on faith from the sending platform.
No authentication issue existed anywhere in the chain.
Phase 4 · SMTP route reconstruction
Every hop between sender and inbox was reconstructed and documented:
Sender
↓ ESP sending infrastructure
↓ Exchange Online Protection
↓ Outlook mailbox
Every relay checked out. No failures anywhere in the route.
Phase 5 · Infrastructure investigation
Most investigations stop once the SMTP route and authentication both check out clean. This one didn't. Every piece of infrastructure connected to the sending domain was audited, not just the mail server.
clientdomain.com
bounce.s1.mc.espdomain.com
mta1.espdomain.com
203.0.113.45 (ESP sending IP)
198.51.100.20 (Exchange Online Protection)
203.0.113.88 (hosted website)
Additional infrastructure audited: PTR records, DNS, DMARC, SPF, reverse DNS, the hosted website itself, SSL configuration, blocklist status, and reputation signals across all of it.
Phase 6 · The missing piece
The email infrastructure looked healthy end to end. So the question changed: what else could Microsoft's reputation engine be associating with this sender?
The answer: the hosted website. Historical hosting records showed the domain's website had previously sat on infrastructure with materially weaker reputation signals than the dedicated ESP delivery network handling the actual email send. That website resolved to 203.0.113.88, and DNSPulse flagged that infrastructure as blocked during the investigation.
Phase 7 · Corrective action
Hosted website
↓ migrated
↓ new infrastructure, new hosting IP
↓ reputation rebuilt
↓ emails retested
Phase 8 · Result
Following the hosting migration and reputation rebuild, subsequent Outlook tests delivered to the Inbox instead of Junk.
Authentication was never the limiting factor here. The decisive factor was Microsoft's broader reputation assessment, one that extends past SPF, DKIM, and DMARC into infrastructure trust and historical reputation signals most authentication reports never surface.
Something like this happening to you?
If your authentication checks out clean and the inbox still disagrees, that's exactly what Email Forensics is built to find. Send us what you're seeing.