550 5.5.0 Requested Action Not Taken: Mailbox Unavailable

A 550 5.5.0 "Requested action not taken: mailbox unavailable" reply means the receiving server refused your message permanently because it will not deliver to that mailbox. Treat the address as dead and remove it, unless the local part has an obvious typo you can fix. If the address ends in outlook.com, hotmail.com or live.com, Microsoft documents this reply as the address not being found by its SMTP address lookup. The cheapest way to stop seeing it is to run your list through a mailbox check before you send. SimpleVerifier Pro does that for $39 a month: the first 100,000 checks a month run at full speed, then slower, never cut off, with 100 free checks to start.

What each part of the reply means

An SMTP bounce has two codes. The three-digit code, 550, is the basic reply from the server. The first digit is the part that matters for your decision: 4 means try again later, 5 means do not retry. 550 is the standard "requested action not taken" refusal, used when a mailbox is unavailable.

The second code, 5.5.0, is an enhanced status code. The class is 5 (permanent), the subject is 5 (protocol status) and the detail is 0, which RFC 3463 defines as "other or undefined protocol status". Put plainly, the server is saying something went wrong with the delivery conversation and it has no more specific code to give. That is why 5.5.0 shows up on its own so rarely and nearly always comes with human-readable text after it. The text is the real clue.

A typical line looks like this:

550 5.5.0 Requested action not taken: mailbox unavailable

What it means from Outlook.com and Hotmail

Microsoft's Exchange Online nondelivery report documentation lists this exact reply. It says the cause is that the recipient's SMTP address, at a hotmail.com or outlook.com domain, was not found by the SMTP address lookup, and it points to the guidance for 550 5.1.10, a very similar error. We checked that page on 10 November 2026.

In practice that gives you three common situations:

1. A typo. Consumer Outlook addresses are often typed from memory into a form, and one wrong character gives an address that does not exist.
2. A closed account. The address was real once. The account was closed or retired, and the server now treats it as unknown.
3. An address that never existed. Someone typed something plausible to get past a signup form, or a data provider guessed a pattern.

You cannot tell these apart from the bounce alone, and you do not need to. All three end the same way: stop sending to that address.

What it can mean from other servers

The code is not exclusive to Microsoft. Because 5.5.0 is "other or undefined", some servers use it for refusals that are not about the mailbox at all, such as a malformed command or a policy refusal. If the text after the code says something about the mailbox being unavailable, not found or not existing, treat it as a dead address. If it mentions blocking, policy, spam, reputation or your IP, the problem is on your side, and our guide to reading provider bounce messages and the bounce message analyzer will help you sort it. Paste a raw bounce into the analyzer and it points at the likely cause.

There is also a reference page for this one code at /smtp/550-5-5-0.

Step by step: what to do when you see it

1. Read the whole reply. Look at the text after 5.5.0. Mailbox unavailable, user unknown and recipient not found all point to the address. Anything about policy or blocking points to you.
2. Check the domain. If it is a Microsoft consumer domain, expect the lookup explanation above. If it is a company domain, check whether the domain still has working mail servers with the bulk MX lookup.
3. Look for a typo. Compare the address against the source form. Common slips are a missing letter, a swapped letter in the domain, or a trailing dot. Fix it only when you are sure of the intended address.
4. Suppress the address. Add it to your do-not-send list in your sending tool and your CRM. See removing bounced emails from a list for the mechanics.
5. Count it. Each of these is a hard bounce against your sending domain. If you are seeing many, your list has a quality problem, not a one-off. The bounce-rate calculator shows what share of a send they were.
6. Find the source. If the bad addresses cluster in one import or one data vendor, that is where the fix belongs. The bounce rate by source tool helps you compare.

Do not retry. A 5xx is the server telling you it is final, and repeated attempts to a refused mailbox only add more bounces to your record. For the difference between permanent and temporary replies, see hard bounce vs soft bounce.

Why a retry will not help

Some tools retry any failed send a few times. That is sensible for 4xx replies, which are temporary. For a 5xx like this one, the server has said the mailbox is not there. If an address truly was mistyped, retrying the same typo returns the same reply. If the account has been closed, it stays closed. If your tool keeps retrying 5xx replies, change the setting so permanent failures are suppressed after the first one.

How to prevent it with verification

The reason this bounce exists is that you sent to an address nobody checked. A mailbox check does the check first. SimpleVerifier looks up the domain's mail servers, connects, asks whether the server would accept mail for the address, and disconnects before any message is sent. Addresses that would have returned a mailbox-unavailable reply come back as invalid, so you can drop them before they touch your sending domain.

Be realistic about the limits. Some providers will not answer that question honestly. Microsoft consumer addresses and catch-all company domains can come back as risky instead of valid or invalid, because the server will not give a definite answer. Risky is not the same as bad: it means "send with care, in a small test batch". Our post on verified emails that still bounce explains why no check can promise zero bounces, and accept-all vs unknown results explains what to do with risky rows.

A good routine:

• Verify every list the first time you import it.
• Verify again before a big send if the list is more than a few months old, because mailboxes close over time.
• Verify at the point of capture for forms, so typos are caught while the person is still there to fix them.
• Send risky rows in a small batch first and watch for bounces.

You can check one address with the free email checker, or paste a block into /verify.

How SimpleVerifier fits

SimpleVerifier Pro is $39 a month. The first 100,000 checks a month run at full speed. After that they run slower, and you are never cut off. If you have a list you are nervous about, start with the 100 free checks, no card, and see how many rows would have bounced. See pricing for the plan details.

Common mistakes

• Deleting the whole domain after one bounce. A single 550 5.5.0 is about one address. Only act on the domain if many addresses at it bounce.
• Assuming a bounce means the person left the company. At a Microsoft consumer domain it is an account that does not exist, which is not the same thing.
• Re-importing the same file later. If you export bounces and then upload the original list again, the dead addresses go straight back in. Keep your suppression list as the source of truth.
• Ignoring the pattern. One bounce is noise. A cluster is a list-quality signal.

Bottom line

550 5.5.0 "mailbox unavailable" means do not deliver here, and nothing about retrying changes that. Remove the address, check for a typo, work out which list it came from, and check lists before sending in future. The bounce doctor is a quick next step if the bounces keep arriving, and the 100 free checks on /verify show how clean your next file really is.