Provider deliverability · Outlook (Outlook.com and Microsoft 365 mailboxes)

Why does Outlook move emails to junk after they arrive?

Samuel Chenard

By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 17, 2026

Outlook moves delivered mail to Junk after arrival for four main reasons: Microsoft's zero-hour auto purge (ZAP) re-scans the last 48 hours of delivered mail against updated spam and phishing signatures; the recipient marked you as junk, so every future message is classified as spam; the Outlook desktop client's own junk filter re-files it; or a recipient rule moves it. Authentication and complaint rate decide the first two.

The 30-second check

A post-delivery move produces no bounce: your logs show a clean 250 accepted while the message quietly leaves the inbox. So start with the one thing you can test from outside. The free Microsoft compliance checker verifies SPF, DKIM, DMARC, and Microsoft's sender requirements for your domain, the exact signals that decide how much benefit of the doubt Outlook's filters extend to your mail after delivery.

Check your domain now

Enter your sending domain and the check runs instantly on the next page. Free, no signup.

Why Outlook is blocking your email

Likely causeWhat's happening
Zero-hour auto purge (ZAP) re-scored the messageOn Microsoft 365 and Exchange Online mailboxes, ZAP retroactively re-checks delivered mail against spam and malware signatures that update in real time, and its search covers the last 48 hours of delivered email. When the verdict flips to spam, the default action moves the message to the Junk Email folder; for spam verdicts ZAP only acts on unread messages, and Microsoft states users aren't notified when it moves one. This is the literal arrived-then-moved mechanism (per Microsoft's ZAP documentation, checked 2026-07-17).
The recipient blocked you or reported your mail as junkWhen a recipient blocks a sender, Outlook routes their future mail to Junk. Microsoft 365 stamps messages from senders on a mailbox's Blocked Senders list with the header X-Forefront-Antispam-Report: SFV:BLK, and "any future messages from that sender are classified as spam." One message read in the inbox followed by every later one junked, for one specific recipient, is this pattern.
Junk complaints are dragging your sender reputation downMicrosoft's postmaster tools are built around complaint feedback: SNDS shows how recipients are rating the mail from your IPs, and JMRP reports the junk complaints Outlook.com users file back to you. As complaints accumulate and your reputation slides, new messages start scoring SCL 5 or 6 and get delivered straight to Junk. From your side this looks like Outlook changed its mind about mail that used to land, when really each message is being scored worse than the one before it.
The Outlook desktop client's own junk filter re-filed itWhen Outlook's built-in Junk Email Filter is set to Low or High, the client uses its own SmartScreen definitions to move spam to Junk after delivery, and it ignores the SCL verdict Microsoft 365 already stamped (unless the message was marked to skip spam filtering, e.g. SCL -1). Microsoft stopped producing spam definition updates for these client-side filters in November 2016 and says their effectiveness will likely degrade over time, so its verdicts get increasingly arbitrary. Even at the default "No automatic filtering", the client still moves mail from blocked senders after delivery.
A recipient inbox rule or Sweep rule moves your mailInbox rules run as soon as mail arrives and are what actually move messages from a sender to another folder. Sweep rules in Outlook.com and Outlook on the web are blunter: they automatically delete all incoming email from a particular sender (or keep only the latest, or delete mail older than 10 days), and Microsoft documents that Sweep rules run once per day while inbox rules run as mail arrives. So a swept message can sit in the inbox for hours and then vanish on schedule, deleted rather than junked. Nothing about your sending is wrong here; only that recipient can undo it.
The recipient organization tightened its anti-spam policyMicrosoft 365 tenants on the Standard or Strict preset security policies quarantine high confidence spam instead of junking it, and domain-level Safe Senders entries are not honored for quarantine actions. Mail that previously survived on a safe-sender domain entry can start disappearing entirely after a policy change on the recipient side, which gets reported back to you as "it arrived, then it was gone".
Triage flowchart for why Outlook moved an email to Junk after delivery: a silent move within 48 hours points to zero-hour auto purge, an SFV:BLK header means the recipient blocked the sender, SCL 5 or 6 with worsening sends means complaint-driven reputation decline, moves seen only in the Outlook desktop client point to its own junk filter, and scheduled disappearance points to a recipient inbox or Sweep rule.

How to fix it, step by step

  1. Run the Microsoft compliance check on your sending domain

    Use the free checker above (or at /tools/microsoft-compliance-checker). It verifies SPF, DKIM, and DMARC exactly as Microsoft's sender requirements define them. Weak or misaligned authentication is the cheapest signal for a re-scoring filter to act on, so rule it out first.

  2. Get the full headers from a moved message

    Ask one affected recipient to open the Junk copy and send you the internet headers. X-Forefront-Antispam-Report containing SFV:BLK means you're on that mailbox's Blocked Senders list; the SCL value shows the filter's verdict (5 or 6 is the spam range); Authentication-Results shows which of SPF, DKIM, or DMARC failed. There is no bounce for a post-delivery move, so headers are your only evidence.

  3. Fix SPF, DKIM, and DMARC alignment for every sending service

    Add each platform that sends as your domain to SPF, enable DKIM signing with your own domain rather than the provider's default, and publish a DMARC policy. Verify with the free checkers at /tools/spf, /tools/dkim, and /tools/dmarc; Microsoft requires the passing domain to align with your From address.

  4. Enroll in SNDS and JMRP, then cut what draws complaints

    SNDS shows how Microsoft rates your IP space and JMRP reports every junk complaint from Outlook.com recipients back to you. Complaints are the feedback loop behind post-delivery junking, so use JMRP data to identify and stop the specific streams recipients are reporting: stale lists, over-frequent sends, mail nobody opted into.

  5. Remove the content signals that re-scoring acts on

    ZAP fires when updated signatures match already-delivered mail, so avoid looking like the phish it hunts: no URL shorteners or open redirects, link domains that match your sending domain, a display name that matches your From address, and steady volume instead of bursts.

  6. Re-test over 48 hours and keep DMARC reports flowing

    Send a test to an Outlook.com mailbox you control, confirm spf=pass, dkim=pass, and dmarc=pass in the received headers, and check it is still in the inbox two days later (ZAP's window is the last 48 hours). Then monitor DMARC aggregate reports so the next failing sender shows up in a report, not in a recipient's Junk folder.

Related free tools: DMARC checker · SPF checker · DKIM checker · Domain reputation · Email security score

If you send in volume: Outlook's published rules

Microsoft's sender requirements are directly relevant to this symptom. Since May 5, 2025, domains sending more than 5,000 messages a day to Outlook.com consumer addresses (outlook.com, hotmail.com, live.com) must pass SPF, DKIM, and aligned DMARC, and Microsoft's rollout routed non-compliant mail to the Junk folder first, with outright rejection (the 550 5.7.515 bounce) to follow (per Microsoft's postmaster site, checked 2026-07-17). If your mail began sliding to Junk in mid-2025, rule this out before anything else; below 5,000 a day the same checks still steer filtering.

Check your standing with Outlook

Bounce codes you may be seeing

Blocks in this cluster surface as specific SMTP codes. Match yours below; the linked guides cover each code's verbatim provider messages and full fix.

The real root cause: unenforced authentication

Almost every mechanism above keys off the same underlying question: can Outlook prove this mail is really you? Unauthenticated or misaligned mail is the easiest thing for a re-scoring pass to reclassify, junk complaints land hardest on domains Microsoft's filters already distrust, and a spoofer sending as your unprotected domain generates complaints you pay for. The way out is to make authentication a settled fact: correct SPF and DKIM for every sending service, DMARC alignment on the From domain, and a policy enforced at p=reject so nobody else can spend your reputation. Monitoring tells you which senders are failing; enforcement is what makes the silent Junk moves stop.

Enforce it — don't just monitor it

Palisade's AI agent takes domains all the way to enforcement: hosted SPF, DKIM, DMARC, and MTA-STS records, DMARC reports monitored continuously, and policies advanced to p=reject automatically. Your first domain is free, and the full product is open for 15 days, no card.

Free 15-day trial · No credit card · Your own domain free forever (NFR)

Fixing this across every client domain

Post-delivery junking is the worst ticket type an MSP inherits: there is no bounce to attach, the client insists the mail "was there and then disappeared", and the evidence lives in a recipient's Junk folder that empties itself after 14 days. Multiply that across a fleet where every tenant domain has its own SPF, DKIM, DMARC, complaint rate, and safe-sender politics. Palisade does the root-cause work once per fleet: it hosts and manages SPF, DKIM, DMARC, and MTA-STS records for every client domain, surfaces failing senders from DMARC reports before recipients start reporting junk, and walks each domain to p=reject automatically. Tickets land in ConnectWise, HaloPSA, or Autotask through native PSA integrations, pricing is per domain ($9, dropping to $7 at 100+ and $5 at 1,000+), and your own MSP domain is a free NFR domain to prove it on.

Frequently asked questions

Per mailbox, effectively yes. Blocking a sender routes their future mail to Junk, and Microsoft 365 classifies "any future messages from that sender" as spam once you're on a Blocked Senders list. In aggregate it's worse: junk reports flow back to Microsoft as complaints against your IPs and domain, so enough of them junk your mail for everyone.

Zero-hour auto purge is the usual suspect on Microsoft 365 mailboxes. It re-checks delivered mail against updated spam and phishing signatures for 48 hours after delivery and moves re-classified messages to Junk or quarantine, and Microsoft states users aren't notified. Mail that lands and then vanishes within two days fits ZAP exactly.

ZAP is Microsoft's retroactive filter for cloud mailboxes: when spam, phishing, or malware signatures update after a message was delivered, ZAP finds the already-delivered copy, applies the new verdict, and moves spam to Junk by default. It's enabled by default, acts silently, and senders can't opt out; only authentication and content keep you clear.

Safe Senders entries make matching mail skip filtering (SCL -1), but they only fully protect against move-to-junk verdicts. When the recipient organization's policy quarantines instead, Microsoft honors email-address entries but not domain entries, and tenant-level block entries and mail flow rules override the list entirely. Ask whether the recipient org runs Standard or Strict presets.

No. Microsoft states users aren't notified when ZAP moves a message, and junked mail doesn't linger: "Email is automatically removed from the Junk Email folder after 14 days and can't be recovered after that." Treat post-delivery junking as silent mail loss on a two-week fuse, not a cosmetic placement issue.

That's a reputation slide, not a rule. Microsoft's filters score senders on history, and junk complaints from recipients are the feedback its postmaster tools are built around, so as complaints or authentication failures accumulate, later messages score SCL 5 or 6 and deliver straight to Junk. Register in SNDS to see when Microsoft's view of your IPs turned.

Get the internet headers from the Junk copy. X-Forefront-Antispam-Report showing SFV:BLK means that specific recipient blocked you; the SCL value shows the filter verdict (5 or 6 is spam); Authentication-Results shows which of SPF, DKIM, or DMARC failed. Post-delivery moves produce no bounce, so headers are the only evidence trail.

Not from the sending side. ZAP is enabled by default on Exchange Online mailboxes and only recipient admins can override it, via allowlists or Exchange mail flow rules in their own tenant. What you control is being a poor match for updated signatures: aligned SPF, DKIM, and DMARC, clean link domains, and a low complaint rate.

Related guides

Email deliverability, fixed: the full guide