SMTP 504 5.5.2: an unsupported command parameter

504 5.5.2 is a permanent failure meaning the server recognised the command itself but does not support a specific parameter or argument you supplied with it. This differs from 500 (command unrecognised entirely) and 501 (the parameters are syntactically malformed). A 504 means the syntax was fine, but the particular option requested - often an ESMTP extension parameter on MAIL FROM, or an unsupported AUTH mechanism name - is not something that server implements.

Who is at fault

This is a sending-client fault. Your SMTP library or custom code is requesting a feature or parameter the receiving server never advertised in its EHLO response, or is hardcoding an AUTH mechanism the server does not support. The fix is entirely in your outbound configuration. It is worth distinguishing this from a related but different problem: a server that advertises

no ESMTP extensions at all (a bare, minimal EHLO response) versus one that advertises some but not

the specific one your client is requesting. In the first case, your client should fall back to

plain SMTP without any extensions; in the second, it should use only the subset the server

actually listed. A short client-side check - parsing the EHLO response into a set and

intersecting it against whatever parameters your code wants to attach - is a few lines in most

languages and removes an entire category of 504s permanently, rather than fixing them one

destination at a time as each new server surfaces the same underlying assumption. A client that assumes extensions are available without checking the EHLO response

at all is the most common root cause of a 504 appearing repeatedly across many different

destinations rather than just one.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250-mx.example.com
250-SIZE 10240000
250-8BITMIME
250 AUTH LOGIN PLAIN
MAIL FROM:<sender@yourdomain.com> SMTPUTF8
504 5.5.2 Command parameter not implemented

The server's EHLO reply never advertised SMTPUTF8, yet the client requested it on MAIL FROM anyway - that is the exact mismatch 504 reports.

How Gmail, Microsoft 365 and Yahoo word the same condition

The AUTH-mechanism variant of this error is the most common real-world case: a client hardcoded to use AUTH CRAM-MD5, for instance, against a server that only advertises LOGIN and PLAIN.

Diagnostic commands

Capture the server's actual advertised capabilities and compare against what your client sends:

$ openssl s_client -starttls smtp -connect mx.example.com:587 -crlf -quiet
250-mx.example.com
250-SIZE 10240000
250-8BITMIME
250 AUTH LOGIN PLAIN

$ swaks --to recipient@example.com --from sender@yourdomain.com \
  --server mx.example.com -p 587 -tls --auth CRAM-MD5 \
  --auth-user sender@yourdomain.com --auth-password '***'
<~  504 5.5.2 Command parameter not implemented

The EHLO line listing AUTH LOGIN PLAIN with no CRAM-MD5 is the direct explanation for the 504 above it.

The ordered fix

1. Capture the server's EHLO response and list every capability and AUTH mechanism it actually advertises.
2. Compare against your client's configuration - specifically the AUTH mechanism and any MAIL FROM parameters it is hardcoded to send.
3. Switch the client to an advertised mechanism (commonly LOGIN or PLAIN over a TLS connection) rather than one the server does not list.
4. Remove any manually-added ESMTP parameters your library does not confirm are supported by every destination you send through.
5. Re-test with `swaks` using the corrected mechanism before resuming normal sending.

What not to do

• Do not retry with the same parameters. The server's capabilities will not change between attempts; the client configuration must change.
• Do not disable TLS to "simplify" authentication. Switching away from LOGIN/PLAIN over TLS to an insecure mechanism to dodge this error trades a fixable config issue for a credential-exposure risk.
• Do not assume the recipient domain or address is at fault. Nothing about the recipient was evaluated; the session failed on your own command parameters before RCPT TO.
• Do not hardcode a single AUTH mechanism across every destination. Different receiving servers advertise different sets; negotiate based on their actual EHLO response.

Why hardcoding one AUTH mechanism is a recurring mistake

Teams often copy a working SMTP configuration from one provider to another without checking that

the new destination advertises the same AUTH mechanisms. A configuration built against a server

that only offers PLAIN will fail against one that only offers CRAM-MD5, and vice versa, with

exactly this 504 response. The fix that actually survives provider changes is to read the EHLO

response at connection time and select from what is offered, rather than keeping a single

mechanism name in a configuration file and assuming it works everywhere.

MailPilot's SMTP/IMAP connections for warm-up negotiate authentication against each provider's actually advertised mechanisms rather than assuming one fixed method, which is exactly the class of mismatch that produces a 504 5.5.2.