What causes Hotmail 550 5.5.0 mailbox unavailable bounce errors?
Published 3 Jul 2025
Updated 14 Oct 2026
12 min read
Summarize with
Updated on 14 Oct 2026: We clarified how to distinguish Hotmail recipient lookup failures from full mailboxes and temporary bounces, and when to hold or suppress an address.
A Hotmail 550 5.5.0 "Requested action not taken: mailbox unavailable" bounce means Microsoft did not find the @hotmail.com or @outlook.com recipient during SMTP address lookup. Microsoft documents it as similar to 550 5.1.10, "Recipient not found." The usual causes are a mistyped address, a deleted or inactive mailbox, an alias that no longer receives mail, or a Microsoft-side recipient state problem.
This exact response is not a documented sender reputation or authentication code. Those problems normally produce policy-oriented responses, often in the 5.7.x family. If the same send produces other codes, group each non-delivery report (NDR) by its full response before investigating.
The right response is to verify the rejected envelope address before suppressing it. If the address is wrong or no longer active, suppress it as a hard bounce. If the recipient can sign in and confirms that the exact address should receive external mail, place the address on hold while the recipient checks its alias and mailbox status with Microsoft.
What the bounce code means
The SMTP reply 550 and enhanced status code 5.5.0 describe a permanent failure for that delivery attempt. In Microsoft's current Exchange Online NDR table, this Hotmail and Outlook.com response means SMTP address lookup did not find the recipient. The generic 5.5.0 label alone is less useful than the full SMTP response and the command that triggered it.
Typical Hotmail bouncetext
Action: failed Status: 5.5.0 Diagnostic-Code: smtp; 550 5.5.0 Requested action not taken: mailbox unavailable
Microsoft's NDR guidance says an NDR identifies the rejected recipient, remote server, enhanced status code, SMTP response, and original message headers. Use those fields together. A protection.outlook.com host shows where Microsoft rejected the message, but the host name does not turn a recipient lookup failure into a spam verdict.
Microsoft Exchange admin center message trace showing a Hotmail 550 5.5.0 mailbox unavailable failure.
Treat 550 as permanent
Do not automatically retry an unchanged 550 rejection. Send one controlled test after the address is corrected or the recipient confirms that inbound delivery has been restored.
- Confirmed bad address: suppress it immediately.
- Recipient disputes it: hold the address while they check Microsoft account status.
- Address or account changed: send one controlled test.
Where the rejection happens
Many NDRs for this error say the remote server rejected the message "in reply to RCPT TO command." RCPT TO carries the SMTP envelope recipient. At that point, Microsoft is deciding whether it can accept mail for that address. If Microsoft returns 550 there, it has not accepted the message body for delivery to that recipient.
Recipient-stage rejectiontext
RCPT TO:<recipient@outlook.com> 550 5.5.0 Requested action not taken: mailbox unavailable (S2017062302)
The envelope recipient can differ from the visible To header after forwarding, alias expansion, or application-side address handling. Check the rejected recipient field in the NDR, not only the address displayed in the original message. If the intended recipient received the message but the bounce names another Hotmail address, check their automatic forwarding rules for that failed destination. Content edits, subject-line changes, and link removal do not correct an address that Microsoft cannot resolve.
What to save from the NDR
- Rejected recipient: the exact envelope address Microsoft looked up.
- Remote server: the host that returned the rejection.
- Full response: the code, text, suffix, timestamp, and SMTP command.
- Original headers: the message path and original addressing data.
Main causes of Hotmail 550 5.5.0 bounces
Start with causes that make the exact envelope recipient unavailable to Microsoft's SMTP lookup. The wording is generic, but Microsoft's code table gives this Hotmail and Outlook.com response a recipient-not-found meaning.
|
|
|
|---|---|---|
Typo or stale address | One recipient fails | Retype and verify |
Deleted or inactive mailbox | Recipient confirms closure or inactivity | Suppress the confirmed invalid address |
Invalid or removed alias | User can sign in elsewhere | Confirm receiving alias |
Unroutable account identifier | Login name is not a mailbox | Use a valid mail alias |
Microsoft recipient state issue | Known active address fails | Recipient contacts support |
Common causes and first actions
A Microsoft account sign-in name is not always a routable Outlook.com mailbox address. A user can also sign in successfully while a particular Hotmail or Outlook.com alias is missing, removed, inactive, or not recognized for inbound mail. Confirm the exact address that should receive external mail.
If the NDR contains a different code or explicit policy text, compare it with other SMTP 550 causes. Do not transfer the cause of a 5.7.x policy rejection to this 5.5.0 recipient lookup response.
Mailbox unavailable versus mailbox full
A hard bounce is a permanent SMTP rejection for that delivery attempt. It does not prove that a mailbox can never receive mail again. Microsoft's NDR guidance distinguishes 5.x.x permanent failures from 4.x.x temporary failures.
|
|
|
|---|---|---|
550 5.5.0 mailbox unavailable | Microsoft did not resolve the recipient address | Verify the exact address and stop automatic retries |
Explicit mailbox full or quota exceeded text | The response reports a storage or quota problem | Follow the stated quota error; the mailbox owner clears space for a full inbox |
4xx with a 4.x.x status | Temporary delivery failure, commonly called a soft bounce | Let the sending server follow its normal retry schedule |
5.7.x with explicit policy text | A security or policy rejection | Investigate the named policy before classifying the recipient as invalid |
Classify the full response before choosing a remedy
Microsoft's general bounce troubleshooting includes full mailboxes and temporary server problems. Those are causes of bounces generally, not the documented meaning of this exact 550 5.5.0 response. Follow the code and diagnostic text rather than assuming that "mailbox unavailable" means "mailbox full".
Mailbox issue or sender issue
The exact code and response text should lead the classification. A Hotmail or Outlook.com 550 5.5.0 mailbox unavailable response points to recipient resolution. Sender reputation and authentication problems need their own evidence, such as an explicit access-denied, authentication, IP, domain, or policy response.
Recipient lookup pattern
- Response: 550 5.5.0 mailbox unavailable.
- Stage: often returned after RCPT TO.
- Action: verify the mailbox or alias.
Sender policy pattern
- Response: explicit policy or access denial.
- Scope: failures correlate with a sender source.
- Action: follow that policy code.
Volume is context, not a replacement for the code. If many known active Microsoft addresses return the same 5.5.0 response, preserve the NDRs and test the addresses independently. A broad event can indicate a Microsoft-side recipient directory problem, but it does not prove a sender reputation problem.
Check blocklist (blacklist) status only when the response mentions the sending IP, a block, access denial, or another reputation-specific reason. An unrelated blocklist listing does not change the meaning of this recipient lookup code.
Hotmail bounce investigation flowchart with recipient retesting and sender reputation checks.
How to investigate the Hotmail bounce
Start with the raw NDR and the diagnostic fields listed above. Group exact or closely matching responses together, then compare whether the failures affect one recipient or multiple recipients across unrelated sending sources.
- Verify the envelope address: compare the NDR's rejected recipient with the intended address.
- Retype it manually: remove stale autocomplete entries and copied whitespace.
- Ask the recipient to confirm it: verify the exact Hotmail or Outlook.com alias accepts external mail.
- Read the rejection stage: look for RCPT TO and the Microsoft host that rejected it.
- Retest only after a change: send one normal message after correction or account remediation.
If the recipient cannot receive mail from multiple unrelated external senders, the recipient should sign in through Outlook.com, confirm that the exact address remains an active receiving alias, and contact Microsoft support with full NDR samples. The sender cannot repair a recipient directory or alias state inside Microsoft's consumer service.
If only your mail fails
Confirm that the comparison message used the same exact recipient address. Then inspect your full NDR for an additional or different policy response. Do not infer a content or reputation cause from 5.5.0 alone.
When authentication checks matter
SPF, DKIM, and DMARC do not make an unavailable Hotmail recipient exist. Check authentication when the same campaign also receives explicit authentication or policy failures, or when a general delivery review is needed. Keep those findings separate from the 550 5.5.0 diagnosis.
Use our Suped domain health check when the bounce set includes sender-policy evidence. Review the sending IP and reverse DNS alongside the SPF and DKIM configuration. Inspect Authentication-Results headers on a message delivered to a Microsoft mailbox to check the visible From domain against the authenticated domains. A recipient-stage rejection does not provide a delivered message with those headers.
Keep the diagnoses separate
- 550 5.5.0 mailbox unavailable: verify the recipient address and account state.
- Explicit SPF, DKIM, or DMARC failure: repair the failing sender and domain match.
- Explicit IP or policy block: follow the named policy response.
A recent authentication change still deserves review if other Microsoft bounces appeared at the same time. It does not override the documented recipient-lookup meaning of this exact response.
How Suped supports authentication investigations
Suped is our DMARC and email authentication platform. It does not determine whether Microsoft recognizes a specific Hotmail mailbox. It helps when the same delivery incident also contains authentication failures, unknown sending sources, or a separate blocklist (blacklist) signal that needs verification.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped's DMARC monitoring shows which sending sources pass SPF or DKIM with DMARC domain matching. DMARC aggregate reports summarize authentication results by sending source; the raw NDR provides the recipient-specific delivery error. Compare reporting intervals with policy-related bounce patterns. Keep 550 5.5.0 recipients in the address-verification workflow unless their NDR contains a different sender-policy response.
A practical workflow is to tag bounces by exact response, route recipient-not-found responses to list operations, and route explicit authentication failures to the domain owner. This prevents an SPF or DKIM dashboard result from becoming an unsupported explanation for a mailbox lookup failure.
Recipient workflow
- Input: rejected address and full NDR.
- Owner: list team or recipient.
- Outcome: correct, suppress, or hold.
Suped workflow
- Input: DMARC reports and source data.
- Owner: domain or mail administrator.
- Outcome: fix a separately proven sender issue.
How to fix the bounce
Fix or retire the recipient address that Microsoft could not resolve. Sender-side DNS, content, and throttling changes do not create a missing mailbox. The sender's job is to stop repeated delivery attempts, verify the data, and preserve evidence for the recipient when the address should be active.
- Stop automatic retries: treat the unchanged 550 response as permanent.
- Correct address errors: retype the recipient and remove stale saved entries.
- Confirm the receiving alias: ask the recipient which exact address accepts external mail.
- Suppress invalid recipients: suppress confirmed invalid or inactive addresses; keep disputed addresses on hold with sending disabled.
- Escalate active-mailbox cases: give the recipient complete NDR samples for Microsoft support.
Investigate Hotmail server blocking only when Microsoft returns an IP, access-denied, or policy-specific response. That is a different failure path from a recipient that SMTP address lookup did not find.
Practical suppression rule
Suppress confirmed bad recipients. Place a disputed address on hold, with sending disabled, while the recipient checks the issue with Microsoft. Retry once after a correction or confirmation that inbound delivery has been restored.
- Suppress: the recipient confirms the address is wrong or closed.
- Hold: the recipient confirms an unresolved Microsoft account issue.
- Retest: a correction or account change has been completed.
For a mailing list, retain the bounce category, first and last failure timestamps, exact diagnostic response, and suppression reason. That record prevents a later import from silently reactivating a known unavailable recipient.
Views from the trenches
Best practices
Use the rejected envelope address, not only the visible To header, when checking the NDR.
Treat the unchanged 550 response as permanent and retest only after a verified change.
Keep recipient lookup failures separate from explicit authentication and policy rejects.
Common pitfalls
Blaming reputation from this code alone sends the investigation toward the wrong system.
Repeatedly retrying a permanent 550 wastes capacity and damages list hygiene records.
Assuming a successful sign-in proves every Hotmail alias can receive external email.
Expert tips
Save the remote host, RCPT TO response, timestamp, message ID, and rejected recipient.
Ask the mailbox owner to confirm the exact receiving alias before any controlled retest.
Escalate multiple known-active failures with complete NDR samples and matching timestamps.
Marketer view
A marketer from Email Geeks reported that some active Hotmail users received this response, so the team compared user confirmation with repeated bounce evidence before suppressing addresses.
2020-08-25 - Email Geeks
Marketer view
A marketer from Email Geeks noted that reputation problems usually produced other signals first. Those signals need separate evidence and should not be inferred from 550 5.5.0 alone.
2020-08-25 - Email Geeks
