5.5.1

Enhanced Status Code 5.5.1: Invalid Command

Permanent failure Medium severity Protocol RFC 3463
What it means

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.

At a glance
Code5.5.1
Bounce typeHard (permanent)
SeverityMedium
CategoryProtocol
What to doSuppress the address; do not retry
StandardRFC 3463
What it looks like in your mail logs
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

Your server attempts delivery
The recipient server returns a permanent 5.5.1 rejection
This is a hard bounce: the message will not be accepted as sent
Suppress the address and fix the root cause before resending

Where 5.5.1 sits: soft vs hard bounce

Soft bounce (4xx) Hard bounce (5xx)
NatureTemporaryPermanent
SMTP class4xx5xx
What to doLet it retrySuppress the address
Recoverable?OftenNo
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

Frequently asked questions

What does SMTP error 5.5.1 mean?
It means the server received a command it does not implement, or received a valid command at the wrong point in the conversation. You will see it as 502 5.5.1 for an unimplemented command and 503 5.5.1 for one that arrived out of sequence. In both cases the sending client is not following the protocol correctly.
Why do I get "503 5.5.1 EHLO/HELO first"?
Because your client began the transaction without greeting the server. SMTP requires EHLO, or the older HELO, as the first command after connecting, and the server refuses everything else until it arrives. This is the single most common cause of 5.5.1 in hand-written sending code, where the greeting is easy to forget.
What causes "503 5.5.1 RCPT first"?
Sending DATA before naming at least one recipient. The order is MAIL FROM to declare the sender, then one RCPT TO per recipient, then DATA to begin the message body. Skipping straight to DATA leaves the server with nowhere to deliver, so it refuses.
Can pipelining cause 5.5.1?
Yes. If your client sends several commands without waiting for each reply, and the server has not advertised PIPELINING in its EHLO response, the server processes them one at a time and sees later commands as arriving out of order. Only pipeline when the capability is advertised.
Is 5.5.1 ever the receiving server's fault?
Rarely, but it happens when a security appliance or proxy sits in front of the server and rewrites or reorders the conversation. If your client is well-behaved and the same code works against other destinations, test directly against the destination MX to establish whether something in the path is interfering.
Reviewed by Jennifer Jackson, Email Deliverability Analyst · June 2026 ← All bounce codes