SMTP error 555 5.5.4: unrecognized MAIL FROM or RCPT TO parameter

SMTP error 555 is defined in RFC 5321 specifically for one narrow situation: a parameter

attached to a MAIL FROM or RCPT TO command that the server does not recognise or has not

implemented. Paired with enhanced code `5.5.4` ("invalid command arguments"), it means the

base envelope command itself was understood, but a specific ESMTP parameter riding along with it

caused the entire command to be rejected, since the server has no way to safely process a

parameter it does not understand.

Fault: sender, specifically attaching an ESMTP parameter the destination has not advertised

support for.

Why it happens

• A rarely used or newer ESMTP parameter (beyond the common SIZE, 8BITMIME, SMTPUTF8)

sent to a server that implements only the common set, or implements none of the less common

extensions at all.

• A vendor-specific parameter intended for a specific mail platform, mistakenly sent to a

different platform's server that has no knowledge of it.

• A malformed parameter value on an otherwise-recognised parameter - the server recognises

the parameter name but rejects the specific value as invalid, which RFC 5321 also permits under

this same code.

• A library or integration defaulting to sending every parameter it knows how to construct,

without first checking which ones the specific destination's EHLO response actually

advertised.

• A DSN (delivery status notification) request attached by default - many mail-sending

frameworks add RET= and NOTIFY= parameters automatically when a developer enables read

receipts or bounce tracking, without checking whether the specific destination server

implements DSN extensions at all.

• **A transfer-agent upgrade on the sending side that enables a previously unused parameter by

default**, changing outbound behaviour against every destination simultaneously even though

nothing about the sending configuration was deliberately changed.

The transcript

$ swaks --to test@mailpilots.in --server mx.example.net
-> EHLO sender.example.com
<- 250-mx.example.net
<- 250 SIZE 35882577
-> MAIL FROM:<sender@yourdomain.com> RET=HDRS ENVID=abc123
<- 555 5.5.4 MAIL FROM/RCPT TO parameters not recognized or not implemented

The server advertised only SIZE in its EHLO response - RET and ENVID are DSN

(delivery-status-notification) extension parameters that this particular server does not

implement, and the whole MAIL FROM command is rejected as a result.

How the big three word it

Diagnose it

$ swaks --to test@mailpilots.in --server mx.example.net --quit-after EHLO
-> EHLO sender.example.com
<- 250-mx.example.net
<- 250 SIZE 35882577

Compare the parameters your application sends against exactly what this list contains - anything

not listed here is at risk of producing a 555 on this specific destination.

The fix, in order

1. Check the destination's `EHLO` response before attaching any ESMTP parameter to `MAIL

FROM or RCPT TO`.

1. Drop parameters the destination does not advertise, rather than sending them speculatively

and relying on the server to ignore what it cannot process - RFC 5321 requires outright

rejection of the whole command, not silent ignoring of the unsupported parameter.

1. Check parameter values, not just names, if the parameter itself is commonly supported -

some servers reject a recognised parameter with an invalid or malformed value using this same

code.

1. Update or configure your sending library to negotiate parameters per destination from the

live EHLO response rather than sending a fixed, hard-coded set.

1. Fall back to the plain command with no parameters for destinations that do not support any

extensions beyond the base verb, confirming the retry succeeds without them.

What not to do

• Do not assume every destination supports the same ESMTP parameter set. EHLO responses

genuinely vary, and a parameter common on one platform can be entirely absent on another.

• Do not keep sending the same unsupported parameter expecting it to eventually work. The

destination's advertised capabilities will not change between attempts.

• Do not confuse this with `504 5.5.4`. Both concern unsupported parameters, but 504 applies

more broadly to command parameters in general; 555 is specifically reserved by RFC 5321 for

MAIL/RCPT parameters.

• Do not treat this as a content or authentication issue. It is purely about envelope-command

parameter support, unrelated to message body or credentials.

MailPilot checks each destination's advertised ESMTP capabilities before attaching any optional

parameter to an envelope command, avoiding this exact class of rejection on connections it

manages.