Most SMTP errors are about the world: a mailbox that does not exist, a sender that is blocked, a policy that says no. Errors 501 and 503 are different. They are about your client. A 501 says that the server could not parse what you sent; a 503 says that what you sent was valid but arrived at the wrong time. They are the replies you get from hand-written SMTP code, from old devices with fixed firmware, from scripts that talk to a server on a raw socket and from libraries used in unusual ways. They are also the most mechanical errors to fix, because the SMTP protocol is a strict, text-based dialogue with a defined order, and once you see the exact command that triggered the reply, the cause is usually obvious. This guide explains the dialogue, lists the common triggers for each code with the command that causes it, covers the subtle issues of line endings and pipelining and shows how to debug a client in a few minutes.
The SMTP dialogue in order
A mail transaction follows a fixed order. The server sends a 220 greeting. The client sends EHLO name. The server lists its extensions. If required, the client sends STARTTLS, and then EHLO again, and then AUTH to log in. Then the transaction begins: MAIL FROM:<sender>, one or more RCPT TO:<recipient>, then DATA, then the message ending with a line that contains only a period, then QUIT. Each step must succeed before the next one is valid. RSET cancels a transaction and NOOP does nothing. The order is defined in RFC 5321, and servers enforce it. When you send a command out of order, the answer is 503. When you send a command in the right order but with malformed arguments, the answer is 501.
Error 503: bad sequence of commands
The server explains in the text which command it expected. The table lists the usual messages.
| Reply text | What happened | Fix |
|---|---|---|
503 5.5.1 Error: send HELO/EHLO first | A command was sent before EHLO | Send EHLO immediately after the greeting, and again after STARTTLS |
503 5.5.1 Error: need MAIL command | RCPT TO or DATA came before MAIL FROM | Send MAIL FROM first |
503 5.5.1 Error: need RCPT command / 503 valid RCPT command must precede DATA | DATA came before any recipient was accepted | Check that RCPT TO returned 250 before sending DATA; if every recipient was refused, stop |
503 5.5.1 Error: nested MAIL command | A second MAIL FROM was sent in the same transaction | Send RSET, or finish the first message before the next MAIL FROM |
503 5.5.1 Error: authentication not enabled or "already authenticated" | AUTH was sent when not offered, or twice | Authenticate once, after STARTTLS, and only if AUTH is advertised |
503 5.5.2 Send hello first | The server lost the session state after STARTTLS | Repeat EHLO after STARTTLS succeeds |
503 Bad sequence of commands after a long wait | The connection was idle and the server reset state | Send commands without long delays, or reconnect |
The frequent real-world cause is a client that ignores a failure reply and continues. For example, the server answers 550 to RCPT TO because the address is bad, the client does not check, sends DATA anyway, and the server answers 503 valid RCPT command must precede DATA. The 503 is the second error; the first one, the 550, is the real problem. Always read replies in order and find the first non-2xx or non-3xx reply. In most 503 cases, the earlier failure explains everything.
Error 501: syntax error
A 501 means that the command was recognised but the arguments were not acceptable. The text often includes the example the server expected, such as 501 Syntax: MAIL FROM:<address>. Common causes follow.
- Missing angle brackets, or a space in the wrong place. The standard form is
MAIL FROM:<[email protected]>andRCPT TO:<[email protected]>. Some servers accept spaces after the colon, but strict servers do not. Do not put a display name inside the angle brackets. - A display name in the envelope.
RCPT TO:<Alex Smith <[email protected]>>is invalid. The envelope takes only the address. Display names belong in the message headers. - An invalid host name in EHLO.
501 5.5.4 Invalid domain namemeans the name has illegal characters or is not a valid host name or bracketed address. See HELO and EHLO errors. - An address with illegal characters. Spaces, quotes, non-ASCII characters (without SMTPUTF8), or a missing @. The reply may be
501 5.1.7 Bad sender address syntaxor501 5.1.3 Bad recipient address syntax. - Unsupported or malformed parameters. Extra parameters after the address, such as
SIZE=orBODY=8BITMIME, that the server did not advertise or that were written incorrectly. - Bad AUTH data. A base64 string with the wrong padding or characters, or an AUTH PLAIN string built incorrectly. See SMTP AUTH methods.
- Commands sent in lower case with odd spacing, or with trailing garbage. Commands are case-insensitive, but extra tokens may be rejected.
Line endings: a quiet source of both errors
SMTP lines end with CRLF (carriage return plus line feed, \r\n). A client that ends lines with a bare LF, as many Unix tools and programming languages do by default, violates the standard. Lenient servers accepted this for years, but it became a security issue: differences in how servers treat a bare LF in the message body allowed attackers to "smuggle" extra messages through a connection, a class of attack that came to wide attention in late 2023. As a result, many servers now reject or sanitise bare line feeds. Postfix introduced the setting smtpd_forbid_bare_newline for this purpose, and other servers have similar controls. A client that sends bare LF can see strange 5xx or 4xx replies, 501 5.5.2 Syntax error style errors or a failure that appears only after DATA. Make your client convert every line ending to CRLF, in the commands and in the message, and make sure the end of data is \r\n.\r\n. If you use a mature library, this is done for you; the problem appears in hand-built sockets and in message bodies read from files with Unix line endings and passed to a low-level API.
Dot-stuffing and the end of the message
The message ends when the server sees a line containing only a period. If a line in the body begins with a period, the client must add an extra period (dot-stuffing), and the server removes it. A client that does not do this ends the message early, and the rest of the body is read as commands, which produces a flood of 500, 501 or 503 replies. Libraries handle this; hand-written code often does not.
Pipelining and out-of-order replies
If the server advertises PIPELINING, the client may send several commands without waiting for each reply. That is valid, but the client must then read the replies in order and match them. A client that assumes the replies arrive one at a time can get out of step: it treats the reply to RCPT TO as the reply to MAIL FROM and continues incorrectly, producing 503 replies. If you are unsure, disable pipelining in your client or write code that counts the replies. Also note that DATA should not be pipelined before the recipient replies have been read, since the server may refuse every recipient.
Debug it in five minutes
- Turn on session logging in the client, or run the dialogue by hand with
openssl s_client -starttls smtp -crlf -connect host:587and type the commands. - Find the first reply that is not 2xx or 3xx. Ignore the later errors; they are usually consequences.
- Look at the exact command before that reply. Compare it with the form in RFC 5321 character by character: brackets, colons, spaces.
- Check that the order is right: EHLO, STARTTLS, EHLO, AUTH, MAIL, RCPT, DATA, message, QUIT.
- Verify the line endings with a hex dump or a log that shows
\r\n. - Test with swaks, a mature test tool, using the same server and addresses. If swaks works and your code fails, the difference is in your commands.
- Fix the code or the configuration, retest and keep the session log of the successful run as a reference.
The steps and sample commands for the manual test are in how to test an SMTP connection. If the first failure turns out to be a 5xx about the recipient or sender, continue with SMTP 550 or SMTP 553. If it is an authentication reply, see SMTP 530 5.7.0.
Devices, printers and old software
Printers, scanners, alarm panels and legacy applications often have a fixed SMTP client that was written against permissive servers. When a provider tightens its checks, these devices start to fail with 501 or 503 replies, and you cannot change their code. Options are to use a local relay that accepts the device's simple dialogue and re-sends the message correctly to the real server (see sending email from the Linux command line and configuring a Postfix relay), to update the device firmware, or to set the device's options (SSL mode, port, authentication) to the form its client handles best.
A friendly endpoint for strict clients Send through a well-behaved SMTP endpoint with clear error replies and session logs that show exactly what happened.
References and further reading
Frequently asked questions
What does SMTP 503 bad sequence of commands mean?
The client sent a valid command at the wrong time, such as DATA before an accepted RCPT TO or MAIL FROM before EHLO. Find the first failed reply earlier in the session.
What does SMTP 501 syntax error mean?
The server could not parse the command or its parameters, for example a missing angle bracket, a display name in the envelope or an invalid host name in EHLO.
Why do I get 503 after STARTTLS?
The server resets its state after TLS starts. The client must send EHLO again before authenticating or sending mail.
Can bare line feeds cause SMTP errors?
Yes. SMTP requires CRLF line endings. Many servers now reject or sanitise bare LF because of smuggling attacks. Convert all line endings to CRLF.
How do I debug an SMTP client quickly?
Log the session, find the first non-successful reply, compare the command before it with RFC 5321, check the order and line endings and test the same server with swaks.