Spam troubleshooting

Microsoft 365 emails going to junk: find the cause

Microsoft shows a sender less than Google does, but what it shows is precise: the anti-spam headers on a junked message say which verdict fired, a Message Trace says what the receiving tenant did, Quarantine says what its policy held back, and SNDS and the Junk Mail Reporting Program cover consumer Outlook.com. This page is that spine in order, each step linked to Microsoft's own documentation, then the fixes: authentication and alignment first, reputation second, and the ones Microsoft rejects outright since May 2025.

Published Updated 11 min read

Start here: five questions

Find the causestep 1

Where is the mail landing?

If you are guessing, run a placement test first; it answers this per provider in minutes.

The trace, in order

  1. 1

    Read the headers on a junked message

    Send to a mailbox you control on Microsoft 365 or Outlook.com, open the message that landed in Junk and view its source. The X-Forefront-Antispam-Report header carries the SCL (the spam verdict), the BCL (the bulk verdict), the SFV code (why: SPM for spam, BLK for a block list, SKN or SKI for a policy skip) and the SPF, DKIM and DMARC results as Microsoft saw them. This one header usually names the cause.

  2. 2

    Run a Message Trace

    In the Exchange admin center of the receiving tenant, trace the message by sender and date: delivered, delivered to Junk, quarantined, or failed, with the reason. For your own tenant's inbound mail you run it; for a customer's tenant, their admin does.

  3. 3

    Check Quarantine

    A message that never reached Junk may be in the tenant's quarantine under a policy stricter than the default: high-confidence spam, a DMARC failure the tenant rejects, or bulk above the tenant's BCL threshold. Quarantine shows the policy that held it.

  4. 4

    Compare inboxes

    The same message to a consumer Outlook.com address and to a Microsoft 365 tenant. Junk at both is the sender; junk at one tenant is that tenant's policy or a block list entry there; junk at Outlook.com only is the consumer filter and the place to read SNDS.

  5. 5

    Rule out the service and the sending side

    Microsoft 365 service health for an incident at the receiving end, and your own tenant's sending limits (the recipient rate limit, the 30-messages-a-minute throttle, the tenant-wide external cap that returns 550 5.7.233) on the sending end.

Microsoft's pages for each step: the anti-spam headers, the SCL, the BCL, Message Trace and Quarantine. The sending-side limits are on the Microsoft 365 sending limits page.

What each verdict means

  • Rejected with 550 5.7.515 or 5.7.509. Authentication: since 2025-05-05 Microsoft refuses high-volume mail to consumer addresses that fails SPF, DKIM or aligned DMARC, and a tenant can reject a DMARC failure at any volume. A records fix; the Microsoft bulk sender page has the rules.
  • Rejected with 5.7.511 or 5.7.606. Reputation: banned sender, banned sending IP. On Microsoft 365 the IP is Microsoft's own and the block is the domain's; on a relay it is the relay's. The decoder has the page for each.
  • Delivered to Junk, SCL 5 or 6. The spam verdict on content and reputation together; SFV:SPM in the header. The message and the domain's record are both in play.
  • Delivered to Junk on BCL. The bulk verdict: mail that looks like a campaign from a sender whose recipients complain. A list and consent problem before it is a content one.
  • Junk at one tenant only. That tenant's policy, block list or a user's own blocked-senders entry; nothing on the sending side changes it except asking.

Outlook.com: SNDS and JMRP

For consumer Outlook.com, Hotmail and Live, Microsoft gives senders two consoles. SNDS reports filter results and complaint data for the IPs you register (on Microsoft 365 the IPs are Microsoft's and shared, so the domain's standing is read from placement instead); the Junk Mail Reporting Program sends you every complaint an Outlook.com user files, so the address comes off the list the same day. Neither shows where a given message landed; a placement test does.

The fix, in order

  1. 1

    Authentication and alignment

    SPF and DKIM passing, DMARC aligned to the From domain, on the sending domain and on every service that sends for it. Confirm on a real message's headers, because a platform signing with its own domain passes DKIM and fails alignment.

  2. 2

    The list and the volume

    Remove every hard bounce, send to addresses that engaged recently, keep volume on a curve. BCL is a complaint forecast, and the forecast is made from your list.

  3. 3

    The message

    One message for one person, on your own tracking domain. Content is scored with reputation, and a young domain gets less benefit of the doubt.

  4. 4

    The engagement record

    Microsoft weighs domain reputation heavily, and a domain with no record at Outlook.com is filtered on caution. Warming builds that record across the network's Microsoft 365 and Outlook.com mailboxes on a 21-day ramp and keeps building it after.

  5. 5

    Test placement

    At Outlook.com and at a Microsoft 365 tenant, separately, before scaling.

Where Google's and Microsoft's verdicts diverge for the same domain, the missing piece is nearly always the engagement record at the provider that junks it. Microsoft 365 warmup covers the connect flow and the ramp against Exchange Online's limits; how warming works covers the record it builds.