5.5.1SMTP 5.5.1: Invalid protocol command

Mail-transaction commands issued out of order for the current state, or unsupported by the peer, land under registry pattern X.5.1 as code 5.5.1. The enhanced status places this attempt in permanent class 5. The status alone does not show which command failed, whether ordering or support was the issue, or which side owns the defect. Parse the transaction trace and the system's advertised capabilities before assigning cause. The accepted examples on this page all come from one product's documentation and show how that product words the condition.

Out-of-sequence or unsupported mail transaction protocol commands are what X.5.1 covers. The registry description says this detail is useful only as a permanent error, and the concrete 5.5.1 variant carries the matching class 5.

The leading digit 5 denotes a permanent failure for this message in the current context. The code alone does not determine whether the command was out of sequence or unsupported, or which side has the implementation or configuration defect. The basic reply it arrives with points at a branch without proving one: RFC 5248 records the associated basic status code as non-exclusive, and the accepted examples for 5.5.1 arrive with 502 and with 503.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational recommendation: stop automatic and manual retries while the client, the middleware, and the shape of the transaction are unchanged, because the same command sent at the same point of the same exchange produces the same permanent rejection. The unlock condition is a demonstrated change in the protocol exchange: the sequence corrected, the unsupported command removed, or the receiving system's supported command set changed. A send to a different destination is a new route and a new capability negotiation, not a retry of this attempt; treat it as a first attempt and apply idempotency so the message is not delivered twice.

Operational recommendation: do not add the address to a suppression list on the strength of 5.5.1. The code reports a condition of the protocol exchange between two systems and evaluates nothing about the recipient address: it does not state that the mailbox is missing, full, disabled, or refusing mail, and the same rejection would have followed for any recipient in that transaction. Suppress only on evidence that addresses the mailbox itself, read from the full response, the wider event history for that address, and the applicable policy.

• A mail-transaction command was issued out of sequence for the current transaction state, for example RCPT TO before MAIL FROM, or DATA before any recipient had been accepted. Gmail's SMTP error messages documentation reports this branch as “503 5.5.1 Bad sequence of commands.”
• The verb the client sent is not implemented or not recognized by the receiving system, so it is refused wherever it appears rather than at one stage of the transaction. Gmail's documentation reports this branch as “502 5.5.1 Unimplemented command.” and “502 5.5.1 Unrecognized command.”, with a further row, “502 5.5.1 Too many unrecognized commands, goodbye.”, for repeated unrecognized commands inside one session.
• The client mixed two mutually exclusive ways of submitting message content, issuing DATA in a transaction that had already begun sending chunks with BDAT. Gmail's documentation reports this branch as “503 5.5.1 No DATA after BDAT. An email transaction protocol command was issued out of sequence.” and refers to RFC 3030, the specification for the CHUNKING extension that defines BDAT and that a server advertises in its EHLO reply.

1. Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 5.5.1, then record the basic reply that carried it. The accepted examples for this code arrive with 502 and with 503, and RFC 5248 records the associated basic status code as non-exclusive, so the basic reply narrows the branch without settling it.
2. Identify the system that answered and retain the evidence packet: attempt time, message identifier, the exact command line the client sent, the transaction trace from the greeting onward, and the server's EHLO reply with the capability list it advertised.
3. Separate the branches from that evidence. Compare the rejected verb with the core commands of RFC 5321 and with the extensions the server advertised in its EHLO reply, then note where in the transaction it was sent. The criterion is this: a verb that appears in neither the core command set nor the advertised capabilities, and that the system refuses wherever it is sent, is an unsupported command; a verb that is core or advertised, and that the same system accepts at a different point of a session, is supported but out of sequence for the state it was sent in. DATA issued in a transaction that already used BDAT falls on the ordering side even though both verbs are supported.
4. Stop unchanged retries. A new send is authorized by one condition only: the client no longer issues that command at that point in the transaction, whether because the sequence was corrected, the unsupported command was removed, or the transaction now uses a single content-transfer method. Check suppression state again before that send.