Trouble with legitime e-mails beeing flagged as SPAM in Outlook (or not showing up at all)

Several different mechanisms in Microsoft 365/Outlook.com can cause legitimate messages to be treated as spam or not appear in the Inbox, even when SPF and DMARC pass.

Key causes and what to check:

1. Email authentication and reputation

• Even if SPF and DMARC pass, Outlook.com/Microsoft 365 also evaluates:
  • DKIM
  • Composite authentication (compauth)
  • IP/domain reputation and complaint rate
• Poor IP/domain reputation, new sending IPs, or high junk complaint rates can cause messages to be marked as spam or silently filtered.
• Confirm:
  • SPF, DKIM, and DMARC are correctly configured for each sending domain.
  • The sending IP has valid reverse DNS (PTR) and is not advertising a private/non‑routable IP.
  • The IP/domain is not on any blocklists and has a good reputation.

Relevant guidance:

• Microsoft 365 treats unauthenticated or low‑reputation mail with higher suspicion, which can lead to false positives.
• For external senders to Microsoft 365, Microsoft explicitly notes that sending IP, domain, authentication, list accuracy, complaint rates, and content all influence filtering.

2. Content and bulk classification

• Message content can trigger spam filters even when authentication passes. Examples include:
  • Many links or URL shorteners
  • HTML with scripts or form tags
  • Image‑only messages
• Messages can also be classified as bulk/marketing (gray mail) based on Bulk Complaint Level (BCL) and user behavior. These can be routed to Junk even if technically valid.
• Review the content of the messages that land in Junk and adjust any marketing/HTML patterns that resemble spam.

3. User or organization overrides on the recipient side For Outlook.com / Microsoft 365 recipients:

• A user’s Blocked Senders list, rules, or organizational policies can override normal spam decisions:
  • The recipient might have:
    • Added the domain or address to Blocked Senders.
    • A rule that moves or deletes messages.
    • An anti‑spam policy or mail flow rule (for Microsoft 365 tenants) that treats the domain as spam.
• Ask affected Outlook/Outlook.com recipients to:
  • Check their Blocked Senders list and remove the domains/addresses if present.
  • Check rules for anything that moves or deletes messages from these senders.

4. Non‑Microsoft filtering in front of Outlook.com / Microsoft 365

• If recipients’ organizations use another email security gateway before Microsoft 365, that gateway can:
  • Drop messages before they reach Microsoft 365.
  • Rewrite or hide the original source IP, causing SPF/compauth anomalies.
• In such setups, Enhanced Filtering for Connectors should be configured so Microsoft 365 can see the true source IP; otherwise, messages may be misclassified.

5. Messages not appearing at all When messages never appear and no NDR is returned:

• Common reasons include:
  • The message is being filtered or moved by a rule (server‑side or client‑side) into another folder (e.g., Archive, RSS, custom folders).
  • A non‑Microsoft gateway is dropping the message before it reaches Outlook.com/Microsoft 365.
  • The sending IP is blocked at the service level.
• For Microsoft 365 recipients:
  • If an NDR like 550 5.7.606-649 Access denied, banned sending IP [...] is received, the sender must use the delist portal to request removal.
  • If messages land in Junk instead of Inbox, recipients can submit them as false positives to Microsoft to improve future handling.

6. How to investigate specific false positives For messages that do arrive (even in Junk):
7. Examine message headers
   • Check X-Forefront-Antispam-Report for:
     • SCL (spam confidence level)
     • BCL (bulk complaint level)
     • Verdict and detection details
   • Check Authentication-Results for SPF, DKIM, DMARC, and compauth results.
8. Use Message trace / Threat Explorer (for Microsoft 365 tenants)
   • Admins can see which policy or rule acted on the message and why.
9. Submit false positives to Microsoft
   • Recipients can report messages that were incorrectly classified as spam so Microsoft can adjust filters.
10. Improving deliverability to Outlook.com / Microsoft 365 For the sending domains (dj-leo.no, osterud.name):

• Ensure:
  • SPF, DKIM, DMARC are correctly configured and aligned.
  • DNS (including MX and PTR) is correctly set up.
  • IPs are not new or, if they are, volume is ramped up gradually with clean lists and low complaint rates.
  • No namespace mining or abusive behavior is occurring from the IPs.
• If all policies are followed and issues persist specifically with Outlook.com addresses, use the Outlook.com sender support channel to request assistance and review of the sending IP/domain reputation.

For affected Outlook.com recipients:

• Verify:
  • Blocked Senders and rules do not target these domains.
  • Junk Email settings are appropriate.
  • False positives are reported via the built‑in reporting tools.

References:

• Frequently asked questions - Anti-spam protection
• Sender Support in Outlook.com
• External senders - Troubleshoot email sent to Microsoft 365
• Where are my email messages or calendar events in Mail and Calendar for Windows 10?
• Mail goes to the Junk folder by mistake