SMTP Error 503

SMTP reply code 503 is defined by RFC 5321 §4.2.2 as "Bad sequence of commands." It is a protocol state-machine error, not strictly an authentication error: the receiving server got a command it cannot accept in the current state of the session, because a required earlier command was missing, rejected, or sent in the wrong order.

The text that follows the code (for example, "503 Valid RCPT command must precede DATA" or "503 Must authenticate first") tells you exactly which step was skipped.

What causes SMTP Error 503?

A valid SMTP transaction must follow a fixed order (RFC 5321 §3.3):

EHLO (or HELO)  ->  MAIL FROM:<sender>  ->  RCPT TO:<recipient>  ->  DATA  ->  message body  ->  .

A 503 is returned when that order is broken. The most common variants:

• "Valid RCPT command must precede DATA." The client issued DATA but no RCPT TO was ever accepted. Per RFC 5321 §3.3, if there was no MAIL, no RCPT, or all such commands were rejected, the server MAY answer DATA with 503 (or 554 no valid recipients). This often means every recipient was actually rejected upstream (bad address, relaying denied, blocklist) and your code proceeded to DATA anyway.
• RCPT TO sent before MAIL FROM. RFC 5321 §3.3 requires the server to return 503 if RCPT arrives with no prior accepted MAIL command.
• Commands sent before EHLO/HELO. Issuing MAIL FROM on a fresh connection without greeting the server first.
• Authentication required but not performed. Many servers (and submission on port 587) require AUTH before MAIL FROM. If you skip it, the server replies 503 (often "503 Must authenticate first" / 5.7.0) or 530 5.7.0 Authentication required. This is the authentication case — real, but only one of several triggers, not the definition of 503.
• Pipelining without the PIPELINING extension, or sending a second MAIL FROM mid-transaction without RSET, can produce protocol errors, sometimes surfaced as 503 — actual behavior is server-dependent rather than guaranteed by RFC 5321.

How do I fix SMTP Error 503?

1. Confirm the command order. Make sure your client (or library) sends EHLO -> MAIL FROM -> RCPT TO -> DATA. With a well-maintained library (Nodemailer, Python smtplib, SES/SendGrid SDKs) this is automatic — a 503 usually points to a hand-rolled SMTP conversation or a misconfigured relay.
2. Verify a recipient was accepted before DATA. If the message is "valid RCPT command must precede DATA," read the server's 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.
3. Authenticate when required. On the submission service, run AUTH (LOGIN/PLAIN over a TLS connection) before MAIL FROM. For Gmail, use an App Password (with 2-Step Verification enabled) or OAuth2 — Google disabled "Less Secure Apps" for personal Gmail accounts in May 2022; Google Workspace accounts followed a separate, later phase-out that concluded May 1, 2025. Ports 465 (implicit TLS) and 587 (STARTTLS) are both valid per RFC 8314.
4. Reset between messages. Issue RSET before starting a new MAIL FROM if you reuse a connection.
5. Test the raw exchange to watch exactly which command draws the 503: use openssl s_client -starttls smtp -connect host:587 for STARTTLS submission, or openssl s_client -connect host:465 (no -starttls flag) for implicit TLS.

If you send through Courier, you generally never construct SMTP commands yourself — Courier's provider integrations and SDKs sequence them. A 503 surfaced in your logs almost always originates from a downstream SMTP provider rejecting all recipients or requiring auth; check the recipient address and the provider's credentials in your Courier provider configuration.