SMTP Error 504

SMTP reply code 504 is a permanent ("5") failure defined in RFC 5321 §4.2.3 as "Command parameter not implemented." The server understood the command verb (HELO, EHLO, MAIL, AUTH, etc.) but rejected an argument or option you supplied with it. The accompanying enhanced status code (RFC 3463) varies by server and case: you'll commonly see 5.5.2 ("Syntax Error") on HELO problems and 5.7.4 ("Security features not supported") on unsupported authentication.

How is 504 different from 502?

This is the distinction the generic "similar to a 502" description gets wrong. They are not interchangeable:

• 502 ("Command not implemented") = the server does not support the command at all (e.g., it never implemented VRFY).
• 504 ("Command parameter not implemented") = the command is supported, but the specific parameter you passed is not recognized or allowed.

So a 504 almost always points at what you sent with a command, not the command itself.

What causes SMTP error 504?

In practice, 504 shows up in two concrete situations:

1. A bad HELO/EHLO argument — 504 5.5.2 RFC 5321 requires the client to identify itself in HELO/EHLO with a fully-qualified domain name (or an address literal like [203.0.113.10]). If your client sends an empty argument, a bare hostname, localhost, or something with illegal characters (spaces, underscores), strict servers reject it. Postfix's reject_non_fqdn_helo_hostname restriction (documented in Postfix's own postconf(5) reference, default reject code 504) is what produces the canonical message 504 5.5.2 <...>: Helo command rejected: need fully-qualified hostname. This is the most common cause and it is a sender-side misconfiguration.

2. An unsupported AUTH mechanism — usually 504 5.7.4 If you issue AUTH with a SASL mechanism the server didn't advertise in its EHLO response (e.g., requesting AUTH CRAM-MD5 or AUTH GSSAPI when the server only offers AUTH LOGIN PLAIN), it rejects it. In the wild this most often arrives as 504 5.7.4 Unrecognized authentication type (the form used by Microsoft 365/Exchange and many others); some servers instead emit 504 5.5.4 — RFC 3463's generic "Invalid command arguments" code, repurposed by those implementations for an auth-mechanism mismatch rather than a purpose-built auth code like 5.7.4. Google Workspace uses its own non-standard 504 5.7.40 code for the same condition (and for "XOAUTH is no longer supported") — note that 5.7.40 is a Google-specific extension and isn't part of the IANA/RFC 3463 registry, so you won't find it defined in the RFC itself.

How do I fix SMTP error 504?

If it's a HELO/EHLO problem (5.5.2):

1. Set a real fully-qualified hostname on the sending machine. Check it with hostname -f; it must resolve to a domain, not localhost.
2. Configure your mail client/library to send that FQDN in the EHLO greeting. In Nodemailer, set the name transport option to your FQDN. In Python's smtplib, pass a valid local_hostname to SMTP().
3. If you operate the receiving Postfix server and the rejection is a false positive, whitelist the specific HELO name in /etc/postfix/helo_access rather than removing the restriction outright.

If it's an AUTH problem (5.7.4 / 5.5.4):

1. Send EHLO first and read the advertised 250-AUTH ... line to see which mechanisms the server actually supports.
2. Choose one of those mechanisms (commonly PLAIN or LOGIN over TLS).
3. For Gmail / Google Workspace specifically, modern auth requires an App Password (with 2-Step Verification enabled) or OAuth2 — Google removed "Less Secure Apps," and Google's own error for a bad auth mechanism is 504 5.7.40, not 5.5.4. The 5.5.4 form is seen on other servers, such as AWS SES's SMTP relay. Use port 587 (STARTTLS) or 465 (implicit TLS); both are valid per RFC 8314.

To capture the exact failing command, run a verbose SMTP session (openssl s_client -connect host:587 -starttls smtp, or your library's debug flag) — the line immediately before the 504 tells you which parameter the server refused.