Recipient's Mailbox Is Quarantined? What It Means and What to Do

Short answer: "The recipient's mailbox is quarantined" is Exchange protecting its own database from one unstable mailbox - it has nothing to do with your sending reputation, your content, or your list. It clears itself automatically, and there is no delisting request, no authentication fix, and no reputation repair that speeds it up.

• If this is the only bounce you are seeing, to one recipient: it is almost certainly not you. Wait and try again later, or reach the person another way in the meantime.
• If you manage the recipient's mailbox yourself: jump to the section on checking and clearing it directly.
• If the same recipient keeps hitting this repeatedly: that is a sign their mailbox has a real, ongoing health problem, worth telling them about.
• If you are also seeing other bounce codes, or many other recipients failing: this guide will not explain those - see our full delivery diagnostic guide instead.

The Exact Bounce, and What It Actually Says About You

You sent one message, and what came back was a non-delivery report reading, word for word, something close to: "Your message wasn't delivered because the recipient's mailbox is quarantined." Nothing about your domain, your IP, your authentication, or your content is mentioned, because none of those caused it.

This bounce comes from Microsoft Exchange - either an organization's own on-premises Exchange server or a mailbox hosted on Microsoft 365 - and it describes a state of the recipient's individual mailbox, not a judgment about the message you sent or the sender who sent it. That distinction is the entire point of this guide: this is one of a small number of bounce messages that tells you almost nothing about your own sending, and a great deal about a completely unrelated server-side event happening on the other end.

If you run cold outreach at any real volume, you will eventually see this exact wording, usually against a small number of recipients rather than your whole list, and usually without it repeating for that same person again for a long time afterward. That pattern - rare, isolated, then gone - is itself part of the diagnosis.

It also helps to know how rare this actually is relative to the bounces you deal with every day. Hard bounces from bad addresses, soft bounces from full mailboxes, and policy rejections from filtering are the bulk of what any real sending volume produces. This specific wording is a small slice of that pile, precisely because it requires a fairly unusual internal condition on the recipient's server rather than anything about the message itself. Treat it as the exception that proves the rule: most bounces do need your attention, and this particular one is the case that genuinely does not.

What "the Recipient's Mailbox Is Quarantined" Actually Means

Exchange runs many mailboxes on top of a shared database, called the Information Store. Occasionally, one individual mailbox starts behaving in a way that threatens the stability of that shared database - not by being malicious, but by getting stuck. When that happens, Exchange isolates the problem mailbox rather than letting it risk everyone else sharing the same store. That isolation is what quarantined means here: a self-protection mechanism, applied automatically, to one mailbox, by the mail system that hosts it.

While a mailbox is in this state, nobody can deliver new mail to it, and the owner typically cannot access it either. Nothing was deleted, and nothing about your message content matters - the mailbox is temporarily set aside, the way a single overloaded checkout gets closed at a store while every other one keeps serving customers normally.

The store analogy is worth extending slightly, because it also explains why you cannot simply route around the problem. Closing one checkout does not mean the store is closed, and it does not mean the item you wanted to buy has disappeared - it means that one specific point of service is temporarily out of action while the rest of the store operates normally. In the same way, the rest of Exchange keeps running, other mailboxes on the same server keep sending and receiving without issue, and the only thing genuinely unavailable is the one mailbox that tripped the protection.

This is also why the failure is so specific in scope. Exchange is not making a decision about your message, your domain, or even about the recipient's mailbox contents. It is reacting to a technical condition tied to that one mailbox's processing, and the only thing waiting on the other side of it is time.

The Technical Cause: a "Poison Mailbox" Event

Microsoft's own documentation calls this a poison mailbox issue, and it is triggered by one of two specific conditions inside Exchange's processing of that mailbox:

• A background thread doing work for the mailbox crashes outright, or
• More than five threads working on that mailbox stall and make no progress for an extended period.

Either condition tells Exchange that continuing to process that mailbox normally risks the health of the database serving potentially thousands of other mailboxes, so it quarantines the one causing trouble rather than letting the problem spread. The underlying reasons a mailbox reaches that state are things like corrupted items sitting in a folder, a folder with a broken index, a stuck synchronization process, or an in-progress repair or migration - all server-side and item-level issues that belong entirely to the recipient's mailbox, with no connection to anything a sender did.

This mechanism is old and well established in Exchange, going back to earlier on-premises versions, and the same protective behavior carries into Exchange Online mailboxes hosted on Microsoft 365. What differs is who can act on it: an on-premises Exchange admin has direct server access to investigate the specific corruption behind it, while in a Microsoft 365 environment there is no manual override available to anyone outside Microsoft's own infrastructure - it has to clear on its own.

Why This Is Not a Sender-Reputation Problem

It is worth stating plainly, because the instinct after any bounce is to start auditing your own setup: this bounce is not evaluating your domain authentication, not checking your IP against any blocklist, not scoring your content, and not reacting to your sending volume. The trigger condition - a stalled or crashed processing thread tied to one specific mailbox - happens entirely inside the recipient's mail system, before your message content is ever considered at all.

Two practical consequences follow. First, nothing you change about SPF, DKIM, DMARC, subject lines, links, or sending pace will make this particular bounce happen less often, because none of those are inputs to the decision. Second, seeing this bounce once, against one recipient, is not a signal to audit your reputation the way a genuine policy rejection would be. Treat it as noise from a system you have no visibility into and no control over, and move on with the rest of your list.

Where this stops being reassuring is if the same wording is showing up against many different recipients across different domains at the same time. That pattern points away from an isolated mailbox event and toward something else entirely - possibly a widespread issue at a specific Exchange host, or more likely, a different bounce that only superficially resembles this one. Confirm the exact wording carefully before assuming every failure this week has the same explanation.

Two Different Things Both Called "Quarantine"

Microsoft uses the word quarantine for at least two unrelated concepts, and mixing them up sends people down the wrong path entirely.

The bounce this guide is about is the first row, and it is the rarest and most misunderstood of the three. If what actually happened is that your message was accepted and then held by security filtering, that is message quarantine, and the fix runs through the recipient's own IT team checking the Microsoft Defender quarantine page for their organization - a different diagnostic path from anything covered here. If nothing bounced at all and the recipient simply cannot find your message, work through Emails Not Being Delivered? Diagnostic Guide, which covers exactly that branch in detail.

Bounces That Get Confused With This One

A handful of other common Exchange bounces get lumped together with mailbox quarantine in people's memory, because they all sound roughly like "something is wrong with the recipient's mailbox." They are not the same problem, they are not caused the same way, and they do not share a fix.

If you are unsure which of these you actually received, go back to the exact wording rather than your memory of it. The difference between a mailbox being quarantined and a mailbox being full is a single word in the bounce text, and it is the difference between a problem that fixes itself by tomorrow and one that keeps bouncing indefinitely until the recipient personally acts on it.

What You, the Sender, Can and Cannot Do

Start with what is off the table, because it saves time. You cannot request removal from this the way you would request delisting from a blocklist - there is no form, no portal, and no third party who administers it on the recipient's behalf. You cannot fix it by changing your SPF, DKIM or DMARC setup, because authentication is not part of what triggered it. You cannot fix it with better content, fewer links, or a cleaner list, because none of those are inputs to a poison mailbox event. And you cannot speed up the clearing process from outside the recipient's own mail system - there is nothing to poll and nothing to escalate to.

What is actually available to you:

• Wait, then resend later. Most cases clear well within a day, and a plain resend after that window succeeds without you having changed anything about your setup.
• Reach the person a different way in the meantime if the message is time-sensitive - a phone call, a message on another platform, or a colleague at the same company.
• Tell the recipient directly if you have any other way to reach them. A one-line heads-up that their mailbox may be having a delivery issue is useful information for them, and something only their own IT team can actually act on.
• Do not remove the address from your list on the strength of one bounce like this. It is not evidence of a bad or invalid address, and it says nothing about whether the address is real or reachable long-term.

It is worth being explicit about one thing people often try anyway: switching your own sending IP, rotating to a different mailbox, or changing your authentication setup in response to this bounce accomplishes nothing. None of those change how Exchange evaluates the recipient's mailbox, because the recipient's mailbox is not evaluating you at all in this scenario. Save that kind of change for bounces that are actually about your sending - a policy rejection, an authentication failure, or a blocklist listing - where it genuinely helps.

When It Self-Resolves, and When It Does Not

In the ordinary case, this is genuinely temporary. Sources describing this exact error consistently frame the quarantine window as an automatic, self-clearing state measured in hours rather than days - accounts of the specific default vary from a few hours up to about a day depending on the version and configuration involved, and Microsoft has not published one current, universal figure to point to for Exchange Online specifically. The practical takeaway is the same regardless of the exact number: treat "well under a day, usually much less" as the expectation, not a firm promise, and let a routine retry confirm it rather than watching a clock.

It stops being a simple wait-it-out situation in two cases. First, if the same recipient's mailbox triggers this repeatedly over days or weeks, the underlying corruption or stuck process is not clearing on its own - that mailbox needs actual attention from whoever administers it, and no amount of waiting on your end changes that. Second, if what looks like this bounce is not actually clearing after a generous margin - several days, not several hours - it is worth confirming you are reading the bounce correctly rather than assuming the described mechanism simply failed. A different, unrelated block can produce superficially similar wording.

Reaching the Recipient Another Way While You Wait

If the message matters and you cannot simply wait, work outward from what you already have:

• A phone number, if the outreach context makes a call reasonable.
• A LinkedIn message, particularly for business-to-business outreach where a LinkedIn presence is expected anyway.
• A colleague or general company address, such as a published contact or info address, with a note asking them to pass the message along.
• A secondary personal address, if you have one on file from a previous interaction.

What not to do: do not read one blocked delivery as a sign to escalate your sending effort toward that recipient specifically. Sending the same message repeatedly in quick succession while their mailbox is in this state does not help it clear any faster, and once it does clear, several near-identical attempts landing in a queue at once looks worse to any spam filtering layered on top than one clean, well-timed message would.

If You Manage the Recipient's Mailbox

If you administer the Exchange environment on the receiving end, this section is for you rather than someone chasing a single cold-outreach bounce.

On an on-premises Exchange server, you can check a mailbox's quarantine status directly with PowerShell, using Get-MailboxStatistics UserName | fl *Quarantine*. This returns fields including IsQuarantined and QuarantineEnd, which tell you whether the flag is currently active and when it is due to clear. If a mailbox is quarantined repeatedly, the next step is investigating the mailbox itself for corrupted items or folder-level issues rather than the quarantine flag, since the flag is a symptom rather than the underlying problem.

On Microsoft 365, there is no equivalent manual override available to a tenant admin - the multi-tenant infrastructure that hosts Exchange Online mailboxes does not expose this level of control, and the state has to clear through Microsoft's own automatic process. If it is happening often enough to be a real problem for one user, opening a support case with Microsoft, with specific timestamps of when it recurred, is the only path beyond simply waiting it out.

Two things are worth checking in parallel with any support case. First, a message trace for the affected mailbox shows exactly when messages were rejected with this reason, which turns a vague "it keeps happening" into a dated pattern Microsoft's support team can actually investigate. Second, if the mailbox is large, heavily used by a connected app, or in the middle of a migration between platforms, note that in the case as well - all three are common background conditions that make a mailbox more prone to tripping this protection repeatedly.

When the Same Mailbox Keeps Getting Quarantined

One occurrence is background noise. A pattern is a real signal, just not one aimed at you.

If you notice the same recipient's address producing this exact bounce more than once over a period of weeks, the most useful thing you can do - if you have any relationship with that person - is simply tell them. A mailbox that keeps tripping this protection usually has an accumulating problem: a folder with a large number of corrupted items, an oversized or unindexed folder, a connected sync tool hammering it with requests, or a stuck migration. None of that is visible to the recipient from inside their own inbox, and it often takes an outside observer - someone whose messages keep failing - to notice the pattern before their own IT team does.

From your side, the only practical adjustment is patience: expect this recipient's replies, and your outreach to them, to be somewhat less reliable than normal until whatever is actually wrong with their mailbox gets addressed on their end.

Spotting the Pattern in Your Own Sending Reports

If you send at any real volume, the practical question is not what does this mean the first time you see it - it is knowing how to recognize it quickly inside a much larger pile of bounces, so it does not get lumped in with problems that actually need action.

When you are reviewing a batch of bounces after a send, this one is easy to separate out if you know what to look for: the wording is specifically about the recipient's mailbox and the word quarantined, it does not mention your domain, your IP, a spam score, or an authentication failure, and it is nearly always isolated to one or two addresses rather than a meaningful share of the batch. Tag or filter these separately from genuine hard bounces and policy rejections, because mixing them into the same bucket inflates your apparent bounce rate with something that was never actually a bad address in the first place.

The one pattern actually worth tracking over time is repetition against the same recipient across multiple sends, weeks apart, which is covered above - because that is the one version of this that reflects a real, ongoing problem rather than a one-off server hiccup you can safely ignore.

Ruling Out a Problem on Your Own Side

Before you file this away as entirely someone else's issue, do a quick sanity check, because a handful of unrelated problems produce bounce text that people remember imprecisely as something about quarantine.

• Re-read the exact wording. A rejection mentioning your sending IP, your domain, a spam score, or a policy reason is not this bounce - it is a reputation-based rejection, and the fix path is completely different. Start with Outlook Blocking Your Emails? Complete Fix if the wording sounds like that instead.
• Check whether it is isolated to one recipient or spread across many. This bounce, by its nature, affects one mailbox at a time. If a meaningful share of a whole list is failing the same way, you are looking at a different, sender-side problem, and Emails Not Being Delivered? Diagnostic Guide is the right starting point.
• Check whether your own account is the one restricted, not theirs. If sending itself is failing before it ever reaches a recipient's server, see Outlook or Microsoft 365 Account Suspended? instead - that is an entirely different situation from this one.

If none of those match and the wording genuinely is about the recipient's mailbox being quarantined, you have the right diagnosis, and the right response really is patience rather than troubleshooting.

What WarmySender Does and Does Not Do Here

Being direct about this one: nothing about WarmySender, or any sending tool, changes whether a recipient's mailbox gets quarantined by their own Exchange server, and nothing speeds up how quickly it clears. This is a receiving-side, server-level event, and it sits entirely outside what any sender - or anything a sender uses to send - can influence.

Where WarmySender is genuinely useful is everywhere else in your outreach: cold email campaigns with per-mailbox daily sending caps and paced delivery, peer-to-peer email warmup that builds a real sending history for new and recovered mailboxes, LinkedIn outreach and multichannel sequences that combine email and LinkedIn so one bounced recipient does not mean the relationship stalls entirely, and mailbox health monitoring that separates a genuine sender-side reputation problem from noise like the one this guide describes. Knowing the difference is most of the value - it stops you from spending a day rebuilding DNS records over something that was never about your DNS records.

See how WarmySender works.