SMTP Error 500

SMTP reply code 500 is defined in RFC 5321 §4.2.3 as:

500 Syntax error, command unrecognized (This may include errors such as command line too long)

It is a permanent negative completion reply. Per RFC 5321 §4.2.1, the leading 5 means the command was not accepted and the requested action did not occur, and the second digit 0 means the reply refers to syntax problems with the SMTP protocol itself. Because the failure is permanent, RFC 5321 §4.2.1 says the SMTP client SHOULD NOT repeat the exact request without modification — so blindly resending will not help; something about how the command was sent must change.

In enhanced-status-code terms (RFC 3463) this maps to 5.5.2 (Syntax error): "a mail transaction protocol command was issued which could not be interpreted, either because the syntax was wrong or the command is unrecognized."

What causes SMTP error 500?

The server received bytes where it expected a valid SMTP verb (EHLO, MAIL FROM, RCPT TO, DATA, STARTTLS, AUTH, etc.) and could not parse them. Real-world triggers, roughly in order of frequency:

• Protocol/port mismatch (most common). Sending plaintext SMTP commands into an implicit-TLS socket (port 465), or attempting a TLS handshake against a plaintext/STARTTLS port (25/587). The server reads the raw TLS bytes — or your client reads the TLS records — as gibberish "commands" and answers 500. Per RFC 8314, which governs mail submission from a Mail User Agent to a submission server, 465 (implicit TLS) and 587 (STARTTLS) are both valid; the rule is that the port and the encryption mode must match. Port 25 is used for MTA-to-MTA relay (governed by RFC 5321 and general operational practice, not RFC 8314) and commonly uses opportunistic STARTTLS.
• Malformed or non-conformant command syntax. Bad CRLF line endings (bare \n instead of \r\n), an unrecognized verb, raw 8-bit/UTF-8 bytes in a command line where the server expects ASCII (RFC 5321 §2.4 notes servers SHOULD reject such input, "normally using '500 syntax error - invalid character' replies"), or a hand-rolled SMTP client emitting an invalid command.
• Command line too long. RFC 5321 caps the command line at 512 octets including CRLF; an over-long line (for example an enormous address list crammed onto one line) returns 500.
• A middlebox mangling the session. Antivirus "mail shields," SMTP proxies, or firewalls that intercept port 25/587 can rewrite or truncate the handshake so the upstream server sees an invalid command. This is the legitimate kernel behind the old "disable antivirus" advice.

This is distinct from 502 (command not implemented — the verb is recognized syntax but unsupported), 501 (syntax error in parameters/arguments), and 503 (bad command sequence). A 500 means the server couldn't even classify what you sent as a known command.

How do I fix SMTP error 500?

1. Match the port to the encryption mode. Use 465 with implicit TLS (SSL on connect), or 587 (or 25 for MTA-to-MTA) with STARTTLS. Do not start TLS on 465, and do not send plaintext commands on 465. In Nodemailer this is secure: true for 465 and secure: false (with STARTTLS auto-negotiated) for 587; in Python smtplib, use SMTP_SSL for 465 and SMTP
   • .starttls() for 587.
2. Capture the exact failing command. Enable protocol-level logging (Nodemailer logger: true, debug: true; Python smtp.set_debuglevel(1)) and read which verb drew the 500. The line immediately before the 500 in the transcript is the culprit.
3. Validate command formatting. Ensure every command line ends in CRLF (\r\n), is ASCII (use SMTPUTF8/8BITMIME only if the server advertised it in the EHLO response), and stays under 512 octets. If you author SMTP by hand, switch to a maintained library.
4. Send EHLO first, fall back to HELO. If the server returns "command not recognized" to EHLO, RFC 5321 §3.2 says the client should fall back to HELO. Reputable libraries do this automatically.
5. Bypass interfering middleware to isolate it. Temporarily test from a host without an SMTP-scanning antivirus/proxy, or exempt the mail port, to confirm whether a security appliance is rewriting the session. Re-enable it afterward and add a proper exception rather than leaving protection off.
6. Use the provider's documented host/port/auth. If you relay through a service (SendGrid, Amazon SES, Mailgun, etc.), copy their exact SMTP endpoint, port, and credentials. For Gmail/Google Workspace use smtp.gmail.com on 465 (SSL) or 587 (STARTTLS) with an App Password (2-Step Verification required) or OAuth2 — Google removed "Less Secure Apps," so basic password auth will fail.

If you send through Courier, you don't construct SMTP commands directly — Courier's API or a configured email provider handles the protocol — so a raw 500 typically points at a custom SMTP integration or a misconfigured upstream provider; check the provider's connection settings and Courier's message logs for the underlying response.