SMTP 555: MAIL FROM or RCPT TO parameters not recognized

555 is a permanent failure defined specifically for MAIL FROM and RCPT TO parameters that the server does not recognise or implement. RFC 5321 carved this code out explicitly because ESMTP allows extensible parameters on these two commands (things like SIZE, BODY=8BITMIME, SMTPUTF8), and a server needs a precise way to say "I understood the command, but not this specific extension parameter you attached to it." That is different from 504 (an unimplemented parameter on other commands) and from 501 (a syntax error within the parameters themselves).

Who is at fault

This is a sending-client fault. Your SMTP library or custom integration is attaching an ESMTP parameter the destination server's EHLO response never advertised as supported. Fix the client configuration, not the recipient. Worth noting: some SMTP client libraries silently drop unsupported ESMTP parameters rather than

raising this error, which means the absence of a 555 does not necessarily mean every parameter

you think you are sending is actually arriving at the server. If you need certainty that a

specific extension is genuinely active on a given send - SIZE declarations for very large

messages, for instance - check your library's documentation for whether it validates against the

server's advertised capabilities or simply attempts the parameter regardless and lets the server

decide. The two behaviours produce very different failure visibility.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250-mx.example.com
250-SIZE 20971520
250 8BITMIME
MAIL FROM:<sender@yourdomain.com> BODY=BINARYMIME
555 5.5.4 MAIL FROM parameters not recognized or not implemented

The server advertised 8BITMIME but not BINARYMIME/CHUNKING, and the client requested BODY=BINARYMIME anyway.

How Gmail, Microsoft 365 and Yahoo word the same condition

Yahoo's divergence to 501 instead of 555 for the same underlying condition is a reminder that RFC-defined codes are not applied with perfect consistency across every implementation - treat the enhanced status and the wording, not just the base number, as the real signal.

Diagnostic commands

Compare the server's advertised extensions against the parameters your client sends:

$ openssl s_client -starttls smtp -connect mx.example.com:25 -crlf -quiet
250-mx.example.com
250-SIZE 20971520
250 8BITMIME

$ swaks --to recipient@example.com --from sender@yourdomain.com \
  --server mx.example.com --body-encoding 8bit
<~  250 2.1.0 Ok

Confirming the connection succeeds once you drop the unsupported BODY=BINARYMIME parameter and fall back to the advertised 8BITMIME isolates the exact parameter at fault.

The ordered fix

1. Capture the destination's EHLO response and list every extension it actually advertises.
2. Diff that list against your client's configured MAIL FROM and RCPT TO parameters.
3. Remove or conditionally disable any parameter not advertised by that specific destination - this often means per-destination negotiation rather than one fixed parameter set for every send.
4. Re-test with `swaks` using only advertised parameters.
5. Check your SMTP library's defaults - some libraries attach optional parameters (like SMTPUTF8) automatically based on content, and need an explicit override to suppress them against servers that do not support them.

What not to do

• Do not retry unchanged. The destination's EHLO capabilities will not change between attempts; your parameter list must.
• Do not globally disable ESMTP extensions for every destination just because one server rejected one parameter - that sacrifices legitimate functionality (8BITMIME, SIZE) against every other destination that does support it.
• Do not assume this is a reputation or content issue. The session fails before DATA is even reached, so content and reputation were never evaluated.
• Do not confuse this with 504. 555 is specific to MAIL FROM/RCPT TO parameters; if the unsupported parameter is on a different command, you are looking at a 504, and the fix target differs slightly.

Checking your library's defaults before you deploy

Many SMTP libraries enable optional extensions like SMTPUTF8 or BODY=8BITMIME automatically

based on message content, without exposing that decision clearly in your application code. Before

rolling a fix out everywhere, read your library's changelog and configuration options specifically

for which ESMTP parameters it attaches by default, and whether that default can be scoped per

destination rather than globally. A global override that disables a useful extension for every

destination just to fix one picky server trades a narrow problem for a broader loss of functionality.

When Yahoo's divergence to 501 matters

If your own bounce-handling code branches on the base reply code to decide what to do next, Yahoo's

choice to use 501 instead of 555 for what is functionally the same MAIL FROM/RCPT TO parameter

rejection means code that only checks for 555 will silently miss it. The more reliable check is

on the enhanced status code (5.5.2 or 5.5.4) combined with the command context, rather than

the bare three-digit reply alone, specifically because this kind of cross-provider inconsistency

is common enough that relying on the base code by itself will eventually miss a real case.

MailPilot negotiates ESMTP extensions per destination during warm-up and live sending rather than assuming a fixed parameter set, which avoids exactly this class of mismatch against servers with a narrower advertised extension list.