Sending, receiving, and organizing email in Outlook.com
Because the same valid Outlook.com address succeeded on the next attempt, preserve the failed NDR and report this as an intermittent Outlook.com SMTP recipient-lookup failure through Outlook.com’s in-product support.
Microsoft documents 550 5.5.0 Requested action not taken: mailbox unavailable for an @outlook.com or @hotmail.com recipient as meaning that the address was not found during the SMTP address lookup. The accompanying 550 5.1.1 User unknown is consistent with that lookup failure.^1^
This is an SMTP-time rejection, before Outlook.com accepted the message. Consequently, Inbox filtering, blocked senders, and available storage do not explain this particular failed attempt. You have also already excluded rules and forwarding, so there is no value in repeating those checks.
Open a new Outlook.com support request
Since request 7111550408 was closed without assistance:
- Sign in to Outlook.com on the web.
- Select Help on the top menu.
- Search for intermittent 550 5.5.0 mailbox unavailable S2017062302.
- If the suggestions do not resolve it, scroll to Still need help? and select Yes.
- Include:
- Full recipient address privately in the ticket—not in a public forum.
- Complete original NDR, including all headers if available.
- UTC failure time:
2026-11-10T23:01:27.296Z. - Responding server:
BN2PEPF000055DF.namprd21.prod.outlook.com. - Diagnostic identifier:
08DF3D8F9EFA1566. - The fact that an immediate resend of the same message succeeded.
- The closed request number, so support can correlate the previous contact.
- Additional failed examples from unrelated providers, each with its UTC timestamp and diagnostic identifier.
Microsoft documents this in-product path as the way to obtain Outlook.com email support when self-help does not resolve the issue.^2^
Also check the public Microsoft service-status page at the time of the next failure. It currently does not establish a published Outlook.com-wide incident specifically for S2017062302, so the server, timestamp, and diagnostic identifier are important for support correlation.^3^
Run one targeted address test
For the next test, have the sender create a new message, delete any suggested AutoComplete recipient, and manually type the complete Outlook.com address. Do not merely resend the existing message.
Microsoft’s recipient-not-found guidance recommends removing a possibly stale AutoComplete entry and entering the entire address again.^4^
Interpret the result as follows:
- Only one sender fails after doing this: that sender’s administrator should investigate its outbound routing and submission.
- Independent providers intermittently receive the same
S2017062302response for the exact same Outlook.com address: add those NDRs to the Outlook.com support case. That pattern points away from one sender’s cached address. - The address shown in an NDR differs from your real address: investigate an obsolete alias or sender-side cached destination. Do not remove any working Outlook.com alias while troubleshooting.
Sender-admin escalation
If your workplace can reproduce the rejection after manually entering the address, ask its mail administrator to retain the message trace and complete SMTP transcript. They can submit an Outlook.com deliverability issue through Microsoft’s Sender Support channel when messages comply with Microsoft’s policies but delivery problems continue.^5^
The work administrator should submit the failed transaction—not the successful retry—and include:
- Sending server/IP
- Envelope sender and recipient
- Exact UTC timestamp
- Outlook.com responding host
- Entire SMTP response
- Diagnostic identifier
The bare 503 5.5.2 Need rcpt command at the end is likely a follow-on protocol response after Outlook.com rejected the recipient; the actionable response remains the earlier 550 5.5.0/5.1.1 recipient rejection.
References