# 503 5.5.1 Bad sequence of commands: what the SMTP client did wrong

> A 503 5.5.1 means the SMTP server got a valid command at the wrong moment, usually AUTH, STARTTLS, MAIL or DATA out of order. Here is how to find which one.

- Published: 2026-11-09
- Author: Koltrix Team
- Category: Guides
- Source: https://koltrix.com/blog/503-5-5-1-bad-sequence-of-commands-what-the-smtp-client-did-wrong

A 503 5.5.1 reply means the SMTP server understood the command it received but will not accept it at this point in the conversation. The fault is almost always on the client side: something sent AUTH, STARTTLS, MAIL, RCPT or DATA in the wrong order, or kept going after the server had already said no.

Unlike a 550 user-unknown bounce, nothing is wrong with the recipient, the domain or your reputation. The session itself broke. That makes it one of the fastest errors to fix once you can see the conversation.

## What does 503 5.5.1 actually mean?

The two numbers come from different standards. The 503 is the basic SMTP reply code for "bad sequence of commands" defined in [RFC 5321](https://www.rfc-editor.org/rfc/rfc5321). The 5.5.1 is an enhanced status code from [RFC 3463](https://www.rfc-editor.org/rfc/rfc3463), where the X.5.X class covers protocol problems and 5.5.1 means "invalid command". Together: a permanent error, because repeating the same command in the same state will fail the same way. Our guide to [SMTP enhanced status codes](/blog/smtp-enhanced-status-codes) explains how to read the rest of the family.

Some servers add their own text after the code, such as "EHLO/HELO first" or "Error: need MAIL command". That text is the best clue you have, so keep the whole line when you copy it into a ticket.

## What order should an SMTP conversation follow?

An SMTP session is a small state machine, and each command is only valid in certain states. RFC 5321 defines the order for sending a message: the client introduces itself with EHLO, then sends MAIL FROM, one or more RCPT TO, then DATA, then the message body ended by a lone dot. The usual sequence on a submission port looks like this:

| Step | Command | Valid only after |
|---|---|---|
| 1 | `EHLO your.host.name` | The connection opens (the server's 220 greeting) |
| 2 | `STARTTLS` | EHLO, if the server advertised it |
| 3 | `EHLO your.host.name` again | A successful STARTTLS |
| 4 | `AUTH ...` | EHLO (and TLS, on most servers) |
| 5 | `MAIL FROM:<sender>` | EHLO, and AUTH if the server requires it |
| 6 | `RCPT TO:<recipient>` | MAIL FROM accepted |
| 7 | `DATA` | At least one RCPT TO accepted |
| 8 | message, then `.` | A 354 reply to DATA |

Ports and TLS modes are covered in [SMTP ports 25, 465, 587 and 2525](/blog/smtp-ports-25-465-587-2525). The short version: on 465 TLS starts immediately, so the STARTTLS rows do not apply.

## Which mistakes cause a 503 5.5.1?

Most 503 replies come from a small set of causes. Find the command that drew the 503 first; it tells you which row below applies.

| The 503 answers this command | Usual cause | Fix |
|---|---|---|
| `MAIL FROM` | No EHLO or HELO yet, or a second MAIL in the same transaction | Send EHLO first; send `RSET` between messages |
| `MAIL FROM` | Server requires AUTH (sometimes reported as "authentication required") | Authenticate before MAIL, on the right port |
| `AUTH` | AUTH sent twice, sent mid-transaction, or before a required STARTTLS | Authenticate once, before MAIL, after TLS |
| `STARTTLS` | TLS is already active, or a transaction is in progress | Do not repeat STARTTLS; start TLS right after EHLO |
| `RCPT TO` | No MAIL FROM accepted first | Check the MAIL FROM reply before sending RCPT |
| `DATA` | Every RCPT TO was refused (or none was sent) | Handle recipient errors before DATA |

### Why does DATA fail after the recipients were rejected?

RFC 5321 says that if there was no MAIL command, no RCPT command, or all such commands were rejected, the server may answer DATA with 503 (or with 554 "no valid recipients"). A client that sends all its commands in one burst, without reading the replies, will walk straight into this. It is the classic cause when one bad address in a batch makes the whole message fail with 503 instead of the real error, which was a 550 on RCPT earlier in the log.

### Why does it fail after STARTTLS?

Once STARTTLS succeeds, [RFC 3207](https://www.rfc-editor.org/rfc/rfc3207) requires the client to discard what it learned and send EHLO again, because the server's list of capabilities can change over an encrypted connection (AUTH is often offered only after TLS). A client that skips the second EHLO and goes straight to AUTH or MAIL can get a 503 saying EHLO is required.

### Why does AUTH return 503?

[RFC 4954](https://www.rfc-editor.org/rfc/rfc4954) says a server must reject AUTH once authentication has already succeeded, and must not accept AUTH in the middle of a mail transaction. Libraries that reuse a connection and re-authenticate for each message hit this. Authenticate once per connection, and send RSET, not AUTH, to start the next message.

## How can you see which command failed?

Run the same session by hand and read every reply. Our guide to [testing SMTP with swaks and openssl](/blog/swaks-openssl-smtp-testing) shows the tools. For a quick transcript with swaks:

```bash
swaks --to you@example.com --from sender@yourdomain.com \
  --server smtp.example.com --port 587 --tls \
  --auth LOGIN --auth-user USERNAME --auth-password 'PASSWORD' \
  --protocol ESMTP
```

The output shows each command (`->`) and each reply (`<-`). The 503 will sit directly under the command it answers. If swaks succeeds and your application fails, the difference is in how the application drives the session, not in the server.

For a real application, turn on the SMTP debug log of your library (most have one) and look for these patterns:

- A command sent before the previous reply arrived, when the server did not advertise pipelining.
- A second EHLO missing after STARTTLS.
- A second AUTH on a reused connection.
- A DATA that follows a rejected RCPT.

## Could it be something other than your client?

Yes, though less often. If the exact same session succeeds against another server, suspect something sitting between you and the mail server:

- **A security appliance or antivirus scanning port 25.** Some inspect SMTP and rewrite or drop commands, which makes the server see a broken sequence. Disable the inspection for the test, then configure it properly rather than leaving it off.
- **A load balancer or proxy that moves a session between servers.** If it sends the EHLO to one backend and the MAIL FROM to another, the second never saw the greeting.
- **A relay that expects authentication on one port but not another.** The same message can sail through on 587 and draw a 503 on 25. See [554 5.7.1 Relay access denied](/blog/554-5-7-1-relay-access-denied-whats-refusing-you-and-how-to-fix-it) for the policy side of that.

The reliable test is a plain, hand-driven session from the same machine and network as the failing application.

## What should an app do when it sees a 503?

Treat it as a bug to fix, not a delivery failure to retry. A 5xx will not heal on its own, so retrying the same sequence just repeats it. A good sending integration:

1. Reads every reply before sending the next command, unless the server advertised pipelining.
2. Sends EHLO again after STARTTLS.
3. Authenticates once per connection, and uses RSET between messages.
4. Checks each RCPT reply, and only sends DATA when at least one recipient was accepted.
5. Logs the full command and reply pair on failure, so the 503 can be traced to a step.

If you would rather not manage SMTP sessions at all, the [HTTP API](/blog/smtp-relay-vs-http-api) removes this whole class of error: you send one request, and the sequencing happens on the provider's side. [Koltrix](https://koltrix.com) offers both an SMTP relay and an API; the [docs](https://docs.koltrix.com) cover credentials and connection settings.

## Bottom line

A 503 5.5.1 is the server telling you the conversation went out of order. Find the command that got the 503, then check it against the sequence: EHLO, optional STARTTLS and a second EHLO, AUTH once, MAIL, RCPT, DATA. Fix the client so it reads every reply before moving on and stops when recipients are refused. If a hand-driven session works and your application does not, the bug is in how the application drives SMTP, or in a device between you and the server.