Email Not Arriving on Your Microsoft-Hosted Domain? Complete Fix Guide

Short answer: When a custom domain is hosted on Microsoft and only some inbound mail goes missing, the message almost always exists somewhere inside your own tenant - held in quarantine, filed to a Junk folder nobody checked, or removed by a mail flow rule or an inbox rule someone set up and forgot about. Genuine silent loss, with nothing recorded anywhere, is rare. Work through the tenant in order rather than guessing.

• If you have never looked at Quarantine: start there. It is the single most common place mail hides on a Microsoft-hosted domain, and by default it does not always tell you it is holding something.
• If it is affecting one person and not others: check that person's own inbox rules, forwarding, and blocked-senders list before touching anything tenant-wide.
• If it is affecting everyone, from certain senders only: check the tenant-wide allow/block list and your anti-spam policy thresholds.
• If you migrated to Microsoft recently, or use a security product in front of it: check your MX records and connector configuration before assuming this is a filtering problem at all.

Where Missing Mail Actually Goes

A custom domain hosted on Microsoft puts several independent, stacked checks between the internet and your inbox. When a message you were expecting does not show up, it has almost always landed in one of a small number of specific places inside your own tenant - discoverable once you know where to look. The large majority of "some of our email is disappearing" reports resolve to one of a handful of ordinary causes, not to anything exotic or unfixable.

This guide is written for the person who owns or administers a Microsoft-hosted domain - a small business owner, a founder, or whoever set the domain's mail records to point at Microsoft - working through the tenant methodically, rather than for a large enterprise security team. Work through the sections in order; most cases resolve well before the end of the list.

One clarification worth making up front: this guide is about a custom business domain hosted on Microsoft 365 or Exchange Online, where the mailbox owner also has - or can get - access to an administrator portal. A plain personal address ending in outlook.com, hotmail.com, or live.com is a different situation, since there is no tenant, no admin console, and no organization-wide policy to check - the causes and the exact steps differ, even though some of the underlying filtering concepts are related. If your address is a personal one rather than a company domain, the practical troubleshooting available to you is much narrower than what is described below.

Confirm Microsoft Is Actually Handling Your Mail

Before troubleshooting filtering, confirm mail is actually routed to Microsoft's filtering system in the first place. Your domain's MX records should point at a hostname ending in mail.protection.outlook.com. A domain migrated from another host, or one with a third-party security product sitting in front of Microsoft, can end up with DNS or routing configuration that sends some mail around Microsoft's own filtering path entirely - and that path behaves very differently, sometimes genuinely lossier, than the standard one described in the rest of this guide.

If a third-party filtering product does sit in front of Microsoft - a security gateway, an anti-spam appliance, a hybrid setup left over from a migration - Microsoft needs to be told about this explicitly. The relevant setting is usually called Enhanced Filtering for Connectors: without it, Microsoft evaluates the gateway's own IP address as if it were the true source of every message, rather than looking past it to the real originating sender, which can cause legitimate mail to be misjudged in ways that look identical to ordinary filtering from where you sit. If this applies to you, confirming it is configured correctly with whoever set it up is worth doing before anything else in this guide.

The Inbound Filtering Chain, in Order

Inbound mail to a Microsoft-hosted domain passes through several stages in sequence. Knowing the order tells you where to look first.

Notice that an outright rejection at stage one comes back as a bounce - it is loud, not silent. Everything past that point can disappear quietly, which is why the rest of this guide focuses on stages two through five.

When Only Some Senders Are Affected

Before working through every stage individually, answer one question: is this happening with mail from one sender, a handful of senders, or genuinely everyone? The answer points you at a different layer immediately, and skipping this step is the most common reason people spend an afternoon in the wrong settings screen.

The one-sender and one-recipient rows are by far the most common in practice, and both are narrow, fast checks compared to auditing an entire tenant's policy configuration from scratch. Establishing which row you are in before opening any settings screen saves real time.

Checking Quarantine First

This is the highest-value single check on this page. Sign in to the Microsoft Defender portal with an account that has administrator access, and go to the email and collaboration section, then Review, then Quarantine. Search by recipient, sender, or date range to find a specific missing message.

Two things about quarantine are easy to miss. First, malware and high-confidence phishing verdicts are always quarantined, even if the rest of your policy is configured to send other categories of spam to the Junk folder instead - so a real, wanted email that a filter badly misjudged as phishing lands specifically here and cannot appear in Junk no matter how the rest of your policy is set. Second, many tenants have end-user quarantine notification digests turned off, either deliberately or by inheriting a default nobody revisited, which means nobody is ever told mail is being held there at all. It is worth confirming, deliberately, whether yours are on.

By default, Microsoft holds quarantined messages for a period - commonly around 30 days, though admins can adjust this in policy - before deleting them automatically, so check on a regular cadence rather than only after a complaint arrives weeks later. From quarantine you can preview a held message, release it to the recipient, and report it as not junk, which also helps the filter learn that sender is wanted going forward.

Checking the Junk Folder and Inbox Rules

If quarantine is clean, check the specific mailbox's own Junk Email folder next - this is a filtering decision rather than a hold, meaning it is visible the whole time, just easy to overlook if nobody checks it regularly.

Inbox rules are the next most common culprit, especially after a mailbox has been reassigned to a new person, restored from someone who left, or configured once for a specific reason that nobody currently at the company remembers. A forwarding rule set up years ago for a temporary situation, or a rule built to auto-file mail from one sender that now happens to match something wanted, can silently redirect or delete mail with no visible trace in the mailbox at all. Forwarding configured at the mailbox level rather than as a rule behaves the same way and is worth checking separately - if the second hop after forwarding fails, the message can simply vanish from the sender and recipient's point of view alike. Also check the mailbox's own blocked-senders list, which is narrower in scope than the tenant-wide list covered further down but just as capable of silently discarding one sender's mail.

A specific pattern worth naming: a mailbox that changes hands. A support address, a sales inbox, or a role-based mailbox that gets reassigned when someone leaves often keeps every rule the previous owner ever configured, since reassigning a mailbox does not clear its rule set. A forwarding rule the previous person set up to send copies to their personal address, a filter that archived a specific vendor's mail because it used to be noise, or a rule that auto-replied and deleted anything matching an old project's name can all keep running for the new owner with no indication anything unusual is happening - the mail simply never shows up, and there is no error to search for because nothing failed, the rule did exactly what it was told to do.

Tenant Anti-Spam and Anti-Phishing Policies

Beyond Microsoft's defaults, your tenant can have a custom anti-spam or anti-phishing policy in place - possibly set up by a predecessor, an IT consultant during initial setup, or a template applied without adjustment. A policy configured to quarantine anything above a certain bulk-complaint threshold, for instance, can hold newsletters, receipts, or automated notifications that most businesses would consider wanted mail.

Check the Threat policies section of the admin portal for any anti-spam and anti-phishing policies beyond the built-in default, and look specifically at the action configured for each verdict category - spam, high-confidence spam, phishing, high-confidence phishing, and bulk mail. The common trap is a policy copied from a generic recommended baseline or another organization's configuration without adjusting it for how your own business actually receives mail day to day.

A realistic example: a policy set up during onboarding with the bulk-complaint threshold turned down aggressively, on the reasonable assumption that a small business does not want marketing mail cluttering the inbox. Months later, that same threshold quietly catches a supplier's automated order confirmations, a SaaS tool's usage-summary emails, or a webhook-style notification from a system the business actually depends on - none of which anyone would call "spam" in the ordinary sense, but all of which score as bulk mail to an automated system with no context for what your business actually needs to receive. The fix is not turning the whole policy off; it is checking what specifically the current thresholds catch and deciding deliberately whether that is still the right setting.

A Mail Flow Rule You Forgot About

Mail flow rules matching keywords, sender domains, or patterns in the subject or body can reject, redirect, delete, or hold mail that meets their conditions - the same mechanism covered from the sending side in our guide to code and JSON content triggering filters, just viewed here from the receiving admin's side. These accumulate over time: a rule built to handle one specific incident, or a rule meant to catch a spam wave that also happens to catch a legitimate sender using similar wording, can keep quietly acting long after anyone remembers why it exists.

Check the mail flow rules section of the admin center for anything with a broad matching condition paired with a silent action - deleting or redirecting without any visible notice - rather than a visible action like adding a warning banner. A rule with a silent action is exactly the kind that produces a "where did that email go" report months or years after it was created.

A Blocked Sender, Blocked Domain, or Connector Issue

Entries on your tenant's block list get added deliberately most of the time, but also sometimes by accident - someone clicking a "block this sender" option on a message that later turns out to be wanted, or an automated response to a past incident that nobody revisited once the incident passed. Check that list for the specific sender or domain in question.

If mail is routed through any third-party gateway or hybrid configuration before reaching Microsoft, a connector misconfiguration can cause otherwise legitimate mail to be misclassified or dropped in a way that looks, from where you sit, identical to ordinary filtering. Confirming this is set up correctly - the same check covered in the section on confirming Microsoft actually handles your mail - rules out an entire category of causes in one pass rather than chasing individual symptoms.

How to Allow-List a Sender Correctly

Use the right tool for this job. A tenant-wide allow/block list, managed by an administrator, overrides the filtering system's own verdict for a specific sender or domain across the entire organization. A personal Safe Senders list, by contrast, is set inside one person's own mailbox, applies only to that mailbox, and - importantly - does not override a tenant-level quarantine verdict for the most serious categories like high-confidence phishing.

Two cautions worth keeping in mind. Allow entries are not necessarily permanent - Microsoft expires them automatically after a period, and the specifics have changed over time, so do not assume an entry added months ago is still active. Open the allow list directly and check its expiration rather than trusting memory. And avoid over-broad allow-listing: an allow entry removes real spam and phishing protection for that specific sender identity, so use it for a sender or domain you have an actual, ongoing reason to trust, not as a blanket fix applied out of frustration after one missing email.

What a Message Trace Actually Tells You

Everything up to this point has been about knowing where to look. A message trace is different: it is Microsoft's own record of what actually happened to a specific message, which turns guessing into reading a direct answer.

Run it from the mail flow section of the admin center, using an account with administrator access - specifically membership in the Organization Management role group, or the Global Administrator or Exchange Administrator role. Search by sender, recipient, and a date range, and the result shows whether the service received, delivered, deferred, or rejected that specific message, along with what actions - including any matching mail flow rule - were applied along the way. Traces typically cover a considerable historical window, commonly cited as up to around 180 days, which is normally more than enough to catch a message someone is asking about after the fact.

This is the tool to reach for once the checks above have not turned up an obvious answer, because it replaces every other section's "check here and see" with a direct status for one exact message. If a trace shows the message as delivered but the recipient still cannot find it, that result on its own strongly points back at the mailbox-level causes - rules, forwarding, or a full mailbox - rather than anything at the tenant or connection level, since Microsoft's own record confirms the message reached the mailbox.

Why a Message That Was There Can Later Disappear

Microsoft's filtering does not stop evaluating a message the instant it lands in an inbox. If new information later indicates that an already-delivered message is actually malicious - a link inside it gets weaponized after the fact, for example - the system can retroactively pull that specific message back out of the inbox and into quarantine. From the recipient's side, this looks exactly like "it was there, and now it is gone," which is genuinely disorienting and easy to mistake for something else being broken.

If you or a colleague specifically remember seeing a message that is no longer there, check quarantine before assuming anything else is wrong. If instead what you are chasing is a specific on-screen notice reading something like "Microsoft 365 has prevented the delivery of new emails from one of your contacts," that is a related but distinct situation, and it is covered in full in our Outlook and Microsoft 365 blocking guide.

Preventing This Going Forward

• Check quarantine on a regular cadence - weekly is reasonable for most small organizations - rather than only when someone complains that mail is missing.
• Turn on end-user quarantine notifications deliberately if you decide that having them off was not the right call for your organization.
• Document any tenant-wide rule or block-list entry with why it exists and when it was added, so a future administrator - including a future version of you - is not left guessing.
• Periodically review the tenant allow/block list for entries that are stale, expired, or no longer needed.
• Keep a second administrator account with access to the tenant, so troubleshooting a filtering problem never depends on exactly one person being reachable.
• Run a message trace on anything genuinely time-sensitive the moment it is reported missing, rather than working through every other section first - it is the fastest way to confirm whether a message even reached your tenant at all.
• Revisit tenant policy settings after any onboarding period ends, since defaults or conservative starting thresholds set up early on are exactly the kind of configuration that gets forgotten once the business is running normally.

What This Means for Replies and Warmup

To be direct about the limits here: WarmySender has no access to your Microsoft tenant and cannot check, change, or fix anything covered in this guide. That configuration belongs entirely to you or whoever administers your Microsoft hosting, and no outside product can reach into it.

Where this genuinely connects: if you run cold email or warmup through a mailbox that lives on this same Microsoft-hosted domain, a tenant-side inbound filtering problem can look exactly like "nobody is replying" or a stalled warmup, even though nothing is actually wrong with your sending. Replies and warmup mail addressed back to you can be quarantined by your own tenant before you ever see them, producing the same visible symptom as a genuine sending problem while the real cause sits entirely on the receiving side covered throughout this guide. If reply or warmup activity on a mailbox looks unexpectedly quiet, checking your own quarantine is worth doing before assuming anything is wrong with the sending side. One limit worth being clear about: mailbox health monitoring on the sending side can only see what it sends and whether the recipient's server accepted it - it has no visibility into what a recipient's own tenant does with a message after acceptance, which is exactly the layer this guide is about. Setup guidance for connected mailboxes lives in the documentation.