5.0.350: Generic error from the recipient’s server (Microsoft 365 report)

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code: varies; the enhanced code is the part that identifies the problem.
• Enhanced code 5.0.350: not in the IANA registry; the group is other or undefined status (RFC 3463 §3.1).
• Who uses it: Microsoft (Exchange Online): a generic code for nonspecific errors from the recipient’s email organization.

A 5.0.350 in a Microsoft 365 bounce means the recipient's mail server refused your message, and Microsoft is passing on that refusal under a general code. The real reason is in the text that follows it.

What it means

This is Microsoft's code, not one from the IANA registry. Microsoft's Exchange Online NDR reference describes it as a catch-all for nonspecific errors returned by the recipient's email organization. The 5 class makes it permanent, and the 0 in the middle is the "other or undefined" subject of RFC 3463 §3.1, so the code itself tells you nothing more.

In practice, Microsoft 365 delivered, or tried to deliver, to the recipient's server. That server said no for its own reasons, and Microsoft reports the answer under 5.0.350 with the remote server's words attached.

How to read it

Look in the bounce for the remote server's reply, usually shown under the diagnostic information with its own code and text. Then match that to the right page:

• A policy or spam refusal (words like "policy", "blocked", "spam"): see 550 5.7.1.
• A relay or forwarding refusal: see 5.7.367.
• A malformed message: see 554 5.6.0.
• A mailbox that does not exist: see 550 5.1.1.

Microsoft's own examples for 5.0.350 include an x-dg-ref header that is too long, and a policy violation at the recipient.

Common causes

• The recipient's filter or gateway rejected the message for policy reasons.
• A header was too long or badly formed for the remote server.
• The recipient's server rejected the sender, the attachment or the size.
• A third-party filtering service in front of the recipient refused it.

How to fix it

1. Find the remote server's own reply and code in the bounce. That is the error to fix.
2. If the reply names a header (such as x-dg-ref), find out what adds that header (your mail app, an add-in or a gateway), and test with a new, simple message.
3. If it mentions policy, contact the recipient by another route and ask their admin what their server refused.
4. If the text is empty or unclear, send a plain test message with no attachments. If that goes through, the content of the original is the trigger.

What to do with the address

Only remove it if the remote reply says the mailbox does not exist. Otherwise keep it and fix the cause above.

Related codes

• 550 5.7.1: Delivery not authorized: refused for policy reasons
• 5.7.367: Remote server says not permitted to relay (Microsoft 365)
• 554 5.6.0: The message is malformed

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.