Provider deliverability · Outlook (Outlook.com and Microsoft 365 mailboxes)
Why does Outlook move emails to junk after they arrive?

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 cause | What's happening |
|---|---|
| Zero-hour auto purge (ZAP) re-scored the message | On 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 junk | When 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 down | Microsoft'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 it | When 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 mail | Inbox 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 policy | Microsoft 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". |

How to fix it, step by step
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.
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.
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.
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.
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.
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
- Smart Network Data Services (SNDS)
Microsoft's own view of your IP space: filter results, complaint rates, and trap hits per sending IP. Free; register the IPs you send from.
- Junk Email Reporting Program (JMRP)
Reports the junk email issues Outlook.com users flag back to you, which is exactly the complaint stream that precedes post-delivery junking.
- Outlook.com postmaster site
Microsoft's sender documentation hub: requirements, reputation factors, and troubleshooting for junked or blocked mail.
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.
- None at first: a post-delivery move to Junk generates no bounce, so your logs show a clean 250 accepted
- 550 SC-004 "A block has been placed against your IP address because we have received complaints concerning mail coming from that IP address": the bounce that follows when complaint-driven junking escalates to an outright IP block; Microsoft's stated remedy is JMRP enrollment
- 550 5.7.1: the generic policy rejection senders often see once a block is in place Full guide →
- 550 5.7.509: the sending domain fails DMARC verification; junk placement is often the stage before this bounce Full guide →
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
Related guides
550 5.7.1550 5.7.509p=rejectp=quarantineadkim / aspf