When Outlook sends business email to Junk, the message may be technically delivered but not trusted enough for the inbox. Outlook and Microsoft 365 use authentication, sender reputation, recipient behavior, message characteristics, and organizational filtering together. The right fix starts with a fresh example and clear evidence—not a blind rewrite of DNS records.
Read Microsoft’s filtering signals
In Microsoft 365 headers, SCL means Spam Confidence Level. Microsoft’s current SCL guidance explains that SCL alone no longer determines the verdict or action in cloud organizations. Inspect CAT (category), other anti-spam headers, and the tenant policy or message trace to understand what actually filtered the message. Outlook.com also uses Microsoft’s broader SmartScreen filtering signals, which combine message, sender, reputation, and recipient feedback.
If you send from a dedicated IP, enroll in Microsoft’s Smart Network Data Services (SNDS) for IP health data and Junk Mail Reporting Program (JMRP) for complaint feedback. For Outlook.com delivery problems after fixing the cause, use the sender support form linked from Microsoft’s Postmaster troubleshooting page. For Microsoft 365 IP-block rejections, follow the exact non-delivery report instructions, which may point to the separate Office 365 Anti-Spam IP Delist Portal. Delisting and Junk-folder placement are different problems. These programs do not override poor authentication or unwanted-mail complaints.
Identify which Outlook environment is involved
Ask whether the recipient uses Outlook.com, Microsoft 365 at work, or Outlook connected to another provider. A business tenant can also have its own anti-spam policies, safe-sender lists, and security gateway. Save a fresh example message, the recipient domain, timestamp, and complete headers. One recipient’s local rule does not prove a domain-wide deliverability failure.
Check whether the message passed authentication
Inspect the message headers or authentication details for SPF, DKIM, and DMARC results. SPF shows whether the sending system was authorized; DKIM verifies a signature; DMARC checks aligned authentication for the visible From domain. Use the SPF check guide, the DKIM check guide, and the DMARC check guide to compare the public configuration with a real message.
Look for alignment problems
A message can show SPF pass or DKIM pass and still fail DMARC alignment. This is common when a marketing or CRM platform uses its own return-path or signing domain. Record the visible From domain, SPF identity, DKIM signing domain, and DMARC result. Correct the specific sender configuration rather than weakening the overall policy for every stream.
Separate sender streams
Employee mail, invoices, support tickets, form notifications, and promotional email can use different platforms and reputations. Test them independently. If newsletters go to Junk while invoices arrive, focus on the newsletter platform, list source, volume, and unsubscribe experience. If all streams struggle, investigate domain authentication, sender reputation, and organization-wide filters more closely.
Review reputation and recipient signals
Recipients marking messages as junk, high bounce rates, sudden volume increases, and low engagement can all reduce trust. Authentication confirms identity; it does not create recipient interest. Send only to people who expect the message, honor suppression lists, avoid purchased lists, and make promotional unsubscribe options clear. A small consent-based test segment is safer than scaling a damaged stream.
Inspect content and links without chasing myths
There is no universal banned-word list that explains every Junk placement. Instead, ask whether the sender is recognizable, the purpose is clear, links point to expected destinations, and the call to action matches the recipient relationship. Avoid deceptive subjects, unexpected attachments, and sudden changes in message format. Use consistent branding and a real reply path.
Check recent infrastructure changes
Review new email vendors, Microsoft 365 configuration, sending domains, DNS edits, agency access, and list imports. A vendor may have enabled sending before DKIM or SPF was finished. Compare the current public DNS result with the intended configuration, then send a fresh test after any correction. See DNS propagation and email issues when caches create temporary inconsistent lookups.
Use an evidence-based recovery plan
- Pause expansion of the affected stream.
- Preserve a fresh message header and sending-platform logs.
- Fix the confirmed authentication, list, or configuration issue.
- Test a small expected audience.
- Review placement, complaints, and replies before scaling.
For a broader decision path, use the deliverability troubleshooting flowchart. Run Beacon’s free domain check to review the public authentication signals behind your Outlook delivery.
Document the final tested sender configuration for future troubleshooting.