SMTP syntax error command unrecognized

SMTP reply code 500 "Syntax error, command unrecognized" is a permanent (5xx) error defined in RFC 5321 §4.2.3. The receiving mail server returns it when it cannot parse the command line your client sent — the verb isn't one it recognizes, or the line is too long. RFC 5321 spells the full text out as "Syntax error, command unrecognized (This may include errors such as command line too long)." It is a protocol/syntax problem on the SMTP conversation, not an authentication-credential or recipient-policy rejection.

Note: The previous version of this page blamed Gmail's "Less Secure Apps" setting. That is incorrect — that setting (removed by Google in 2022) governs authentication, not command syntax, and produces 535-class errors (e.g. 535 5.7.8 Username and Password not accepted), not 500. The guidance below replaces it.

What causes "SMTP syntax error, command unrecognized"?

Per RFC 5321, a server issues 500 when the command line is unrecognizable. In practice that maps to a few concrete causes:

• An unknown or misspelled verb. SMTP accepts a fixed set of commands — HELO, EHLO, MAIL, RCPT, DATA, RSET, VRFY, EXPN, HELP, NOOP, QUIT (plus extensions advertised in the EHLO response). A typo like HLEO or MIAL FROM is unrecognized. (Note: a recognized command the server simply doesn't support returns 502 "Command not implemented", not 500 — the distinction is can't parse vs won't perform.)
• A line longer than 512 octets. RFC 5321 §4.5.3.1.4 sets the maximum command line at 512 octets including the terminating CRLF. Overlong lines — often from a very long address list jammed onto one line — fall under 500, whose definition explicitly covers "command line too long."
• Malformed arguments. Missing angle brackets in MAIL FROM:<a@b.com> / RCPT TO:<c@d.com>, stray spaces, missing CRLF terminators, or non-ASCII bytes in an envelope command all break parsing. (Note: a syntax error specifically in the parameters/arguments of an otherwise-recognized command is often reported as 501 "Syntax error in parameters or arguments" rather than 500.)
• Talking SMTP to the wrong port/service. Pointing an SMTP client at a non-SMTP port (or an implicit-TLS port 465 endpoint while speaking plaintext) makes the peer reply with bytes your client may surface as a 500-class parse failure.

A note on AUTH / STARTTLS timing

Sending AUTH or STARTTLS before EHLO, or AUTH before the server has advertised it, is a real and common app-code mistake — but the spec-correct reply for these is not 500. Out-of-sequence commands return 503 "Bad sequence of commands"; an AUTH whose mechanism is unsupported or not advertised returns 504 (enhanced code 5.5.4), and AUTH issued after a completed authentication or during a mail transaction returns 503 (per RFC 4954). That said, some non-conformant servers treat an unadvertised verb as simply unknown and answer 500 5.5.1 ... command unrecognized. RFC 4954 does define one spec-legitimate use of 500 inside the AUTH flow — 500 5.5.6, for a base64 challenge/response line that exceeds the SASL mechanism's buffer size — but that's a distinct oversized-line case, not the unadvertised-verb scenario. So if you hit a 500 right after issuing AUTH, check your handshake ordering and line length — but expect a well-behaved server to use 503/504 for ordering problems.

How do I fix SMTP error 500?

1. Enable SMTP debug/transcript logging so you can see the exact bytes on the wire. In Nodemailer set logger: true, debug: true on the transport; in Python smtplib call server.set_debuglevel(1). Find the command line that drew the 500 — the offending verb is right before it.
2. Check command formatting. Wrap addresses in angle brackets (MAIL FROM:<sender@example.com>), terminate every command with \r\n, and strip stray spaces or control/non-ASCII characters. Watch for typos in the verb itself.
3. Keep command lines within 512 octets (including CRLF). Send recipients as separate RCPT TO commands rather than one giant line.
4. Issue the handshake in order: EHLO → STARTTLS → EHLO again → AUTH. Don't send AUTH until the server's EHLO response actually lists it. This prevents the related 503/504 (and the occasional non-standard 500 5.5.1). Most libraries do this automatically — if you're hand-rolling SMTP, fix the ordering.
5. Confirm host, port, and TLS mode. Use 587 with STARTTLS or 465 with implicit TLS (both are valid submission ports per RFC 8314; 465 is not deprecated) — and make sure your client's TLS mode matches the port.
6. Test the raw conversation with openssl s_client -starttls smtp -connect host:587 (or -connect host:465 for implicit TLS) and type the commands manually to see exactly which one the server rejects.

If you send through Courier's SMTP integration or a provider API, the SDK builds the protocol commands for you, which removes nearly all of these hand-rolled-syntax causes; a lingering 500 then points at a malformed header or address you supplied.