Is a 5.0.0 bounce my fault or the recipient’s?

The code cannot tell you. The text after it, plus the name of the reporting host, usually shows whether the refusal came from a policy on their side or a problem with your message.

Will resending the message help?

Not by itself. A 5.0.0 is permanent, so the same message to the same server fails the same way until the underlying rule or fault changes.

5.0.0 bounce: other undefined status

5.0.0Other undefined statusPermanent: retrying will not help

Typical wording

550 5.0.0 <user@example.com>: message rejected

What it means

RFC 3463 defines X.0.0 as "Other undefined status": the server knows the delivery failed but chose not to say which subject (address, mailbox, system, network, protocol, content, or security) the problem belongs to. A 5.0.0 is the permanent form. The code itself carries no diagnosis, so everything useful sits in the human-readable text that follows it.

You usually see 5.0.0 from older Sendmail and Exchange setups, from appliances that map every local rejection to one catch-all value, and from scripts or milters that reject with a bare 550 and let the MTA fill in a generic enhanced code. It differs from 5.7.0 (an unspecified security or policy reason) and 5.3.0 (an unspecified mail system fault) because those at least name the subject; 5.0.0 names nothing.

A 4.0.0 appears when the same unclassified failure is temporary, for example a content filter that timed out. The sending server retries a 4.0.0 until its queue lifetime runs out. A 5.0.0 is final: the message comes back to you right away and will not be retried.

Likely causes

A milter, content filter, or custom rejection script on the receiving side that returns a bare 550 without its own enhanced code.
A recipient or sender rule on an older Exchange or Sendmail server whose only mapping is the catch-all 5.0.0.
A gateway that hides the true reason on purpose (for example a reputation block) and reports nothing more specific.
A broken pipe to a local delivery agent (procmail, a ticketing system, a script) that the MTA turns into an undefined permanent error.

How to fix it

Read the full bounce, not just the code. Copy the line after 5.0.0 and the "Remote-MTA" or "Reporting-MTA" fields from the DSN; they tell you which host refused the message.
Paste the original message headers into the header analyzer to see the last hop that accepted the mail and the host that rejected it.
If the rejecting host belongs to the recipient’s organisation, ask their admin to search their logs for the time and message ID in the bounce. Only they can see which rule fired.
Rule out the common hidden causes yourself: check your sending IP against blocklists and confirm your SPF, DKIM, and DMARC pass, since some gateways report policy blocks as 5.0.0.
If you run the receiving server and your own users see 5.0.0, look at your MTA log for the matching queue ID and fix the filter or delivery agent that produced the bare rejection.

Checks that apply

Your domain or sending IP (fills in the checks below)

Email Header Analyzer Shows the hop that refused the message and any authentication results, which is the starting point when the code itself says nothing.
Blacklist Check Rules out a hidden reputation block, a frequent reason behind vague catch-all rejections.
SMTP Diagnostics Connects to the recipient’s mail server so you can see its banner and software, which hints at how it maps errors.

FAQ

Is a 5.0.0 bounce my fault or the recipient’s?: The code cannot tell you. The text after it, plus the name of the reporting host, usually shows whether the refusal came from a policy on their side or a problem with your message.
Will resending the message help?: Not by itself. A 5.0.0 is permanent, so the same message to the same server fails the same way until the underlying rule or fault changes.

All 191 bounce codes