503 5.5.1: Commands sent in the wrong order

At a glance

• Type: permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
• Basic code 503: “Bad sequence of commands” (RFC 5321 §4.2.3).
• Enhanced code 5.5.1: “Invalid command” in the IANA registry (RFC 3463), in the group mail delivery protocol status (RFC 3463 §3.6).

The sending software spoke SMTP in the wrong order, for example sending a recipient before a sender, or mail before saying hello. This is a bug or misconfiguration in the client, not a problem with the address or the content.

What it means

RFC 3463 §3.6 defines X.5.1 as "invalid command": a command was out of sequence or not supported, and the code is only useful as a permanent error. The basic code 503 is "bad sequence of commands" (RFC 5321 §4.2.3).

RFC 5321 §4.1.4 sets the order:

1. A session that sends mail must start with EHLO (or the older HELO).
2. A mail transaction is MAIL, then one or more RCPT, then DATA, in that order.
3. MAIL must not be sent while a transaction is still open; finish it or reset it with RSET first.
4. If commands are so far out of order that the server cannot process them, it must reply 503 and stay in the same state.

Authentication has its own rules. RFC 4954 §4 says AUTH is not allowed during a mail transaction, and that a second AUTH after a successful one must be rejected with 503. A server that requires sign-in before MAIL normally answers with 530 5.7.0 instead.

Common causes

• A hand-written SMTP client or script that skips EHLO, or sends DATA before any RCPT was accepted.
• A client that keeps going after a RCPT was refused, then sends DATA with no valid recipients.
• Reusing a connection for a second message without finishing or resetting the first.
• Sending AUTH in the middle of a transaction, or twice.
• Pipelining commands without waiting for the replies the server requires.

How providers use it

Gmail returns 503 5.5.1 for a bad sequence of commands and spells out the cases: EHLO or HELO must come first, RCPT must come before DATA, and DATA must not follow BDAT. Its 502 5.5.1 means a command is not implemented or not recognized (Google's SMTP error reference).

How to fix it

1. Turn on SMTP logging in your client and compare the command order with the list above.
2. Check the reply to every RCPT. Send DATA only if at least one RCPT got a success reply (250 or 251).
3. Send RSET before starting a new message on the same connection.
4. Authenticate once, after EHLO and before MAIL.
5. If you wrote your own SMTP code, switch to a maintained mail library, which handles ordering and replies for you.

Related codes

• 501 5.5.4: Invalid HELO/EHLO or command arguments
• 530 5.7.0: Authentication or STARTTLS required
• 535 5.7.8: Username and password not accepted

See every bounce code in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our free email checker, or clean a whole list before you send.

How we wrote this: drafted by the email-validation.org team with the help of AI writing tools, from our product documentation and the sources linked in the text.