SMTP error 503
Bad sequence of commands.
Updated Jul 1, 2026
SMTP 503 is the "bad sequence of commands" reply (RFC 5321 section 4.2.2, with sequencing rules in section 3.3): the client sent a command out of the required EHLO, MAIL FROM, RCPT TO, DATA order. The "valid RCPT command must precede DATA" variant means DATA arrived with no accepted recipient. Fix it by sending commands in order, getting at least one RCPT TO accepted before DATA, and authenticating first if the server requires it.
Make sure your client authenticates and follows the correct SMTP handshake order.
What it means
503 is defined in RFC 5321 section 4.2.2 as "bad sequence of commands". It is a protocol state-machine error, not strictly an authentication error: the server got a command it cannot accept in the current session state because a required earlier command was missing, rejected, or sent in the wrong order. The text after the code, for example "503 Valid RCPT command must precede DATA" or "503 Must authenticate first", tells you which step was skipped. A valid transaction follows a fixed order per section 3.3: EHLO or HELO, then MAIL FROM, then RCPT TO, then DATA, then the body and a final dot.
Common causes
The client issued DATA but no RCPT TO was ever accepted. Per RFC 5321 section 3.3, with no MAIL, no RCPT, or all such commands rejected, the server may answer DATA with 503 or 554. This often means every recipient was rejected upstream (bad address, relaying denied, blocklist) and the code sent DATA anyway.
RFC 5321 section 3.3 requires the server to return 503 if RCPT arrives with no prior accepted MAIL command.
Issuing MAIL FROM on a fresh connection without greeting the server first.
Many servers, and submission on port 587, require AUTH before MAIL FROM. Skipping it draws a 503 (often "503 Must authenticate first" or 5.7.0) or 530 5.7.0. This is a real trigger, but one of several, not the definition of 503.
Pipelining without the PIPELINING extension, or a second MAIL FROM mid-transaction without RSET, can produce protocol errors sometimes surfaced as 503. Behavior here is server-dependent rather than guaranteed by RFC 5321.
How to fix it
- Confirm the command order
Make sure your client or library sends EHLO, then MAIL FROM, then RCPT TO, then DATA. A well-maintained library such as Nodemailer, Python smtplib, or the SES and SendGrid SDKs does this automatically, so a 503 usually points to a hand-rolled SMTP conversation or a misconfigured relay.
- Verify a recipient was accepted before DATA
If the message says "valid RCPT command must precede DATA", read the reply to each RCPT TO. If every recipient returned a 5xx (invalid address, relay denied, blocked), do not send DATA. Fix or drop those recipients first.
- Authenticate when required
On the submission service, run AUTH (LOGIN or PLAIN over TLS) before MAIL FROM. For Gmail use an App Password with 2-Step Verification or OAuth2. Google disabled Less Secure Apps for personal Gmail in May 2022, and Google Workspace finished a separate later phase-out on May 1, 2025. Ports 465 with implicit TLS and 587 with STARTTLS are both valid per RFC 8314.
- Reset between messages
Issue RSET before starting a new MAIL FROM if you reuse a connection.
- Test the raw exchange
Watch which command draws the 503 with "openssl s_client -starttls smtp -connect host:587" for STARTTLS submission, or "openssl s_client -connect host:465" (no -starttls flag) for implicit TLS.
Common questions
Is SMTP 503 an authentication error?
Not by definition. 503 means "bad sequence of commands" (RFC 5321 section 4.2.2), a command out of the required EHLO, MAIL FROM, RCPT TO, DATA order. "Authentication required" is one common trigger, often shown as "503 Must authenticate first" or 530 5.7.0, but a 503 is just as likely to mean DATA was sent with no accepted RCPT TO.
What does "503 Valid RCPT command must precede DATA" mean?
The client sent DATA when no recipient had been accepted. Usually every RCPT TO was rejected upstream (bad address, relay denied, blocked) and the sending code proceeded to DATA regardless. Read each RCPT reply and fix or drop the failed recipients before sending DATA.
Is SMTP 503 a permanent (5xx) failure?
The leading 5 marks it permanent, but the cause is a protocol sequencing mistake you control. Fix the command order or the recipient handling and the next attempt succeeds.