What 504 Command parameter not implemented Means
504 is a permanent rejection. The receiver implements the command (say, AUTH) but the specific argument or sub-option you sent (say, AUTH GSSAPI) isn't one it supports. Per RFC 5321, the distinction from 502 is granular: 502 = command not implemented at all; 504 = parameter not implemented.
Receivers that only support a subset of an extension's options. Common cases: a sending platform requesting AUTH GSSAPI when the receiver only supports AUTH LOGIN and PLAIN; or MAIL FROM with a SIZE= parameter the receiver doesn't accept.
Your sending platform is requesting an AUTH mechanism the receiver doesn't support; or you're using a MAIL FROM SIZE= parameter the receiver doesn't honor; or you're using an extension to RCPT TO (like NOTIFY=) the receiver doesn't support.
How to Fix 504 Command parameter not implemented
- 1
Identify the rejected parameter from the transcript
Find the exact command + parameter that triggered 504. Most commonly it'll be a specific AUTH mechanism. The fix is to fall back to a supported mechanism.
- 2
If AUTH-related — fall back to AUTH LOGIN or PLAIN
AUTH LOGIN and AUTH PLAIN are universally supported. AUTH CRAM-MD5 is common. AUTH GSSAPI / NTLM / DIGEST-MD5 are not universally supported. Configure your sending platform to use only LOGIN or PLAIN over a TLS connection.
- 3
If MAIL FROM SIZE= related — drop the parameter
The SIZE extension lets a sender pre-declare message size so the receiver can pre-reject if too large. Some receivers don't support SIZE; remove the parameter and the receiver will accept the MAIL FROM, then 552 the message if it's actually too large.
- 4
If using an exotic extension — remove it
Some SMTP extensions (CHUNKING, RRVS, MT-PRIORITY) aren't universally supported. If your sending platform is using one and 504 results, switch the platform's config to not advertise the extension. Most platforms have a setting for this.
References
- ◇
- ◇RFC 4954 — SMTP Service Extension for Authentication
Defines AUTH mechanisms — LOGIN, PLAIN, CRAM-MD5, etc.
504 Command parameter not implemented in the Cold Email Context
504 is rare in cold email because mainstream sending platforms default to AUTH LOGIN over TLS, which every receiver supports. The case where 504 does appear: legacy on-prem Exchange or self-hosted MTAs that expect NTLM-style auth. Cold email doesn't typically authenticate to recipient servers anyway — sending platforms authenticate to your own ColdRelay-provisioned mail server (which they do via standard AUTH LOGIN over TLS). ColdRelay's mail servers support the standard AUTH mechanisms, so sending-platform-side 504 errors don't occur in normal cold email flow.
Frequently Asked Questions
Is 504 the same as 502?
No. 502 = the command itself isn't implemented (e.g. VRFY). 504 = the command is implemented but the specific parameter you used isn't (e.g. AUTH NTLM).
Will retrying help?
Not on its own. The parameter you sent will be rejected on retry just like the first time. Change to a supported parameter, then resend.
Does 504 affect deliverability?
Indirectly. If 504 prevents authentication, the entire message never goes through, so no — it's a complete blocker not a reputation event. Fix the underlying parameter and your delivery resumes.