You are not receiving emails in Outlook because messages are being stopped somewhere between the sender's server and your inbox, and the stoppage is usually one of six things: server-side filtering, a full mailbox, a broken client sync, a misrouted rule, an authentication failure, or a network/connection block. Outlook has no single "receive" switch. Delivery is a relay: sender's mail server to your provider's inbound gateways, through spam and malware screening, into your mailbox store, then synced by the client on your device. Each link fails differently. Finding your failure point matters more than trying random fixes.
The single most common cause for personal accounts is a filter or sync problem, not a server outage. For Microsoft 365 work accounts, the most common cause is quarantine or transport rules applied before the message reaches your mailbox. The distinction is testable in under two minutes, and this explainer shows you how.
How inbound delivery actually works
Every email passes through at least four stages before Outlook displays it.
Stage one is the SMTP handshake. The sender's server looks up your domain's DNS records and opens a connection to the IP address listed in your MX records (mail exchanger records). If that IP address is unreachable or your DNS records are misconfigured, the sender gets an immediate or delayed bounce. You never see the message at all.
Stage two is inbound filtering at your provider's edge. For Microsoft 365 and Outlook.com, this is Exchange Online Protection (EOP), which runs connection filtering, anti-spam, anti-malware, and spoofing checks before a message touches your mailbox. Messages judged malicious are dropped silently; messages judged suspicious are quarantined. Neither generates a notification in Outlook itself by default.
Stage three is mailbox-level rules and storage. Transport rules, inbox rules, blocked-sender lists, and mailbox-full conditions act here. A rule that moves a message to a folder you never open looks identical to non-delivery. A mailbox over its quota rejects new mail with a specific NDR (non-delivery report) to the sender.
Stage four is client sync. The Outlook desktop, mobile, and web clients each pull from the mailbox independently. If one device shows nothing and another shows everything, the problem is sync, not delivery.
The critical insight: only stage four can be fixed by reinstalling Outlook or clearing a cache. Stages one through three live in DNS, the provider's cloud, or your mailbox configuration, and no amount of local troubleshooting touches them.
A plain-language version: email has a front door (DNS), a security checkpoint (filters), a mailbox (storage and rules), and a delivery driver (sync). You have to find out which one is failing.
The six failure points, ranked by frequency
These are ordered by how often each cause produces the actual symptom "I'm not receiving emails."
Blocked sender or domain filter. If a specific correspondent's messages never arrive, their address or domain is almost certainly on your blocked list or caught by a provider filter. Rate: extremely common, and the most common cause of selective non-receipt.
Inbox rule misrouting. A rule that moves, deletes, or forwards messages based on sender, subject, or keyword can silently swallow correspondence. Users often create these rules during a cleanup session and forget them.
Mailbox quota exhaustion. Microsoft 365 mailboxes commonly ship with 50 GB of storage for business plans, with Outlook.com free accounts historically capped far lower. When a mailbox hits its limit, inbound messages bounce to the sender with a "mailbox full" NDR; the recipient sees nothing.
Quarantine and spam filtering. Legitimate messages land in quarantine instead of the inbox, and the recipient is never alerted inside Outlook. This is the most common cause for Microsoft 365 work accounts and the most commonly missed cause overall.
Client sync failure. Cached mode corruption, an expired authentication token, or a stalled background sync leaves the inbox frozen at an earlier state. The mailbox has the messages; the client does not display them.
Server and connection faults. Provider outages, expired passwords, disabled accounts, and network blocks stop all inbound mail. These are the least common but the most visible, because they usually affect everything at once.
A useful test: can you receive mail from yourself? Send a message from a different account to your address. If it arrives on Outlook on the web but not on desktop, you have a sync problem. If it fails everywhere, you have a filtering, quota, or server problem. If it fails only from one sender, you have a rule or block.
Delivery timelines: what to expect and when to escalate
The time course of email delivery and failure is well defined, and knowing it tells you when a delay is normal.
| Elapsed time | What is happening | What to check |
|---|---|---|
| 0-30 seconds | SMTP handshake, DNS lookup, connection to MX host | Sender gets immediate bounce if DNS is wrong |
| 30 seconds-2 minutes | Inbound filtering, spam scoring, malware scan | Usually invisible to recipient |
| 2-10 minutes | Delivery to mailbox store; client sync poll | Refresh Outlook; check webmail |
| 10 minutes-24 hours | Greylisting or throttling delay at sender or receiver | Sender may get a "delayed" notice, not a failure |
| 24-48 hours | Retry queue; transient failures may still resolve | Ask sender for the raw bounce message |
| 48-72 hours | Retry window typically exhausted | Sender gets a permanent NDR; investigate now |
| Beyond 72 hours | No message will arrive from that send attempt | Treat as blocked or lost; escalate to provider |
The counterintuitive detail: many "undelivered" email complaints involve messages that were actually delivered on time and then moved by a rule or filter. In those cases, no retry occurs and no bounce is sent, because delivery succeeded. The message is sitting in a folder, a quarantine, or a deleted-items recovery area, not lost in transit.
Reconciling thresholds: a one-hour delay is normal and not a fault. A 24-hour delay with no bounce from the sender points to greylisting or throttling. A 48-72 hour dead end with a bounce means the message was rejected permanently. Use these windows to decide whether to wait, ask the sender for the bounce text, or escalate.
Why filters catch legitimate mail
Spam filtering is probabilistic, and it errs toward blocking. That design choice protects you from phishing and malware at the cost of an occasional false positive.
Microsoft's inbound protection layers connection filtering (IP reputation), content filtering (message scoring), and impersonation detection (spoofed sender and lookalike domain checks). A message accumulates a spam confidence level (SCL) score, and a threshold decision determines whether it reaches the inbox, the junk folder, or quarantine. A legitimate newsletter with heavy links, a new sending domain with no reputation, or a message with an attachment type that matches known threats can all cross the threshold.
For work accounts, quarantine is the critical failure point. Messages held in quarantine are visible only in the security portal or through a quarantine notification email, and default quarantine policies may not notify anyone promptly. The recipient's Outlook inbox shows silence; the administrator's console shows the message.
Another caveat professionals know well: a rule or filter that applies to one mailbox can be replicated across an entire tenant. Organizations sometimes tighten spam policies globally to reduce noise, and a single change blocks a category of legitimate mail for every user at once.
The practical implication: if multiple colleagues stop receiving mail from the same sender on the same day, suspect a tenant-wide policy change, not individual mailbox problems.
Misconceptions that waste troubleshooting time
Reinstalling Outlook fixes delivery problems. It does not. Reinstalling affects the client, which is stage four. A faulty filter, rule, or quota is unaffected.
Clearing the cache restores missing mail. It only forces a resync from the mailbox. If the message is not in the mailbox, clearing the cache delivers nothing.
A spam folder check is enough. Junk mail filtering and quarantine are separate systems. Quarantine is not the junk folder, and many users never look at it.
If the sender didn't get a bounce, the message was delivered. A silent drop by filtering happens with no user-visible signal at either end.
Turning off spam filtering is a reasonable fix. It is not. Disabling filtering to solve one missed message exposes the mailbox to phishing, malware, and spoofing at scale.
The professional caveat: distinguish between "not receiving" and "not seeing." A message in a hidden folder, an archive, or a second account in the same Outlook profile is technically received. Users frequently have multiple accounts, and Outlook shows the wrong one at any given moment.
Comparison: where to look first, by symptom
| Symptom | Most likely stage | First action | Escalation |
|---|---|---|---|
| All mail stops at once | Server or connection | Verify account status and password | Provider support |
| Only one sender is missing | Blocked sender or rule | Check blocked lists and inbox rules | Ask sender for NDR |
| Some mail arrives, some does not | Spam filter or quarantine | Check junk folder and quarantine | Admin quarantine review |
| Webmail shows mail, desktop does not | Client sync | Refresh sync or rebuild profile | IT support |
| Mailbox storage warning appears | Quota | Delete or archive items | Increase quota |
| Mail stops after a password change | Authentication | Sign in and re-authenticate | Account recovery |
| Delay of one to a few hours, then arrival | Throttling or greylisting | Wait and monitor | Sender's provider |
This table is ordered by diagnostic yield, not by severity. Start at the top row that matches your symptom and work down.
Practical actions you can take today
Verify with a second client. Open Outlook on the web or the mobile app. If messages appear there but not in the desktop client, the problem is sync, and you can skip every server-side check.
Send a controlled test. From an unrelated account, send one message and watch for a bounce at the sender. A bounce names the failing stage (DNS, quota, filtering, or authentication).
Audit rules and blocked lists. In Outlook settings, review every inbox rule, blocked sender, and safe sender entry. Delete rules you did not intentionally create.
Check storage and quarantine. Confirm you are under your mailbox quota. For work accounts, open the security and compliance portal or your organization's quarantine page and release anything legitimate.
Re-authenticate. Sign out and back in, or remove and re-add the account. Expired tokens are a frequent cause of stalled sync and silent authentication failures.
The red flags that mean stop troubleshooting and escalate: The sender's bounce mentions a permanent rejection code or "mailbox unavailable." Messages disappear from the inbox after appearing briefly, suggesting a forwarding rule. Multiple colleagues report the same missing sender, pointing to a tenant-wide policy. Your account shows a storage warning or a suspended state. A rule or forwarder exists that you did not create, which may indicate account compromise.
Limits of self-diagnosis
Some causes sit outside your control. Provider outages, DNS misconfiguration at the sending domain, aggressive policies set by your organization's administrator, and account suspensions all require someone else's intervention. Self-diagnosis reliably identifies the stage; it does not always fix the stage.
The hard boundary is this: you can confirm delivery, reconfigure your client, and audit your own rules. You cannot override a quarantine policy set by an administrator or reset a sending domain's reputation. Those require the administrator, the sender's provider, or time.
For work accounts, the fastest resolution path is usually your IT administrator, not Microsoft support. Administrators can search the message trace, which shows the exact disposition of any inbound message and eliminates guessing entirely.
This article is general educational information about email delivery and troubleshooting, not a diagnosis or a technical support commitment. It describes common mechanisms and fixes but cannot guarantee resolution for your specific account, organization, or provider configuration. For account-specific problems, contact your email administrator or provider.