Enhanced Status Code 5.5.1: Invalid Command
Enhanced Status Code 5.5.1 means “Invalid Command.” A command was issued that the server does not implement, or was issued out of sequence. Gmail returns it for at least seven distinct situations, most of them a client speaking SMTP incorrectly.
503 5.5.1 EHLO/HELO first
What does 5.5.1 mean?
Enhanced status code 5.5.1 means invalid command. RFC 3463 defines it as a mail transaction protocol command that was either out of sequence or unsupported. It travels with several different reply codes depending on which of those applies: 502 for a command the server does not implement, and 503 for one that arrived in the wrong order.
Google returns it for bad sequence of commands, an unimplemented command, an unrecognised command, too many unrecognised commands in one session, DATA sent with no preceding BDAT, EHLO or HELO not being sent first, and RCPT being required before the command that was issued. Every one of those is a client that is not following the protocol, which is why this code shows up far more often in homegrown sending code than in established MTAs.
The most frequent single cause is skipping EHLO. A client that connects and immediately issues MAIL FROM without greeting the server will be refused, and developers writing directly against a socket hit this constantly. The second most frequent is pipelining commands at a server that has not advertised PIPELINING, which looks like commands arriving out of order because the server has not read them yet.
How 5.5.1 plays out
5.5.1 rejectionWhere 5.5.1 sits: soft vs hard bounce
| Soft bounce (4xx) | Hard bounce (5xx) | |
|---|---|---|
| Nature | Temporary | Permanent |
| SMTP class | 4xx | 5xx |
| What to do | Let it retry | Suppress the address |
| Recoverable? | Often | No |
| 5.5.1 is | ✓ this code |
Common causes of 5.5.1
- EHLO or HELO was not sent before the transaction began
- Commands were issued out of sequence, such as DATA before RCPT TO
- The client used a command the server does not implement
- Commands were pipelined at a server that does not advertise PIPELINING
- DATA was sent following BDAT, mixing two incompatible submission styles
- Too many unrecognised commands were sent, so the server closed the session
How to fix 5.5.1
- Always send EHLO first and parse the capability list it returns
- Follow the required order: EHLO, then MAIL FROM, then RCPT TO, then DATA
- Only pipeline when the server advertises PIPELINING in its EHLO response
- Choose either DATA or BDAT for a session and do not mix them
- Use a maintained SMTP library rather than writing protocol handling by hand
- Log the full session, since the offending command is always the one just before the refusal