Is 5.5.0 my problem or the recipient’s?

Usually the sending side, because protocol errors come from the client’s command stream. If a plain test from another network succeeds, look at your own software or firewall first.

Why does the code say nothing specific?

Detail 0 means the receiver chose not to classify the error. The free-text part of the reply and the receiver’s own logs are the only places with the specific reason.

5.5.0 bounce: other or undefined protocol status

5.5.0Other or undefined protocol statusPermanent: retrying will not help

Typical wording

550 5.5.0 Requested action not taken: protocol error

What it means

RFC 3463 defines the X.5 subject as “mail delivery protocol status”: problems with the SMTP conversation itself, not with the address, the mailbox or the content. The detail digit 0 is the catch-all. The server knows the dialogue went wrong but does not say which command or argument offended it.

You will usually find 5.5.0 next to a short free-text reason such as “protocol error” or “command rejected”. That text matters more than the code. Some servers also use 5.5.0 loosely for policy refusals, so read the whole line before deciding this is a client bug.

A 4.5.0 variant appears when the server considers the protocol problem transient, for example a pipelining glitch after a timeout. With 4.5.0 your MTA queues and tries again; with 5.5.0 the message comes back to you and nothing more happens until you act.

Likely causes

A mail client or script that speaks SMTP by hand and sends commands out of order, such as DATA before any RCPT TO was accepted.
A middlebox (a firewall with “SMTP fixup” or an antivirus proxy) rewriting or truncating commands between your server and the receiver.
Bare line feeds or a malformed end-of-data sequence that the receiver treats as a protocol violation rather than a content issue.
A receiving server that reuses 5.5.0 for a policy decision and puts the real reason only in the text after the code.

How to fix it

Copy the full rejection line from the bounce or from your MTA log, including the text after 5.5.0, and note which SMTP command it answered.
Repeat the session by hand with `openssl s_client -starttls smtp -connect mx.example.com:25` or the ProbeKit SMTP check to see where the dialogue breaks.
If you send from an application, switch it to a maintained SMTP library instead of hand-written socket code, and make sure every line ends in CRLF.
Disable SMTP inspection features on any firewall between you and the internet (Cisco “fixup smtp” style features are a frequent culprit) and retest.
If the text points to a policy reason rather than syntax, follow the page for that reason, and ask the recipient’s admin for their log entry if it is still unclear.

Checks that apply

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

SMTP Diagnostics Opens a real session to the receiving MX and shows the banner, EHLO extensions and STARTTLS result, so you can see whether the server behaves normally for a clean client.
MX Lookup Lists which hosts accept mail for the recipient domain, so you test the same server that rejected you.

FAQ

Is 5.5.0 my problem or the recipient’s?: Usually the sending side, because protocol errors come from the client’s command stream. If a plain test from another network succeeds, look at your own software or firewall first.
Why does the code say nothing specific?: Detail 0 means the receiver chose not to classify the error. The free-text part of the reply and the receiver’s own logs are the only places with the specific reason.

All 191 bounce codes