SMTP error 555 5.5.2: unrecognized command parameter syntax

555 is defined by RFC 3030 (and referenced in RFC 5321's later clarifications) as a specific

reply for malformed MAIL FROM or RCPT TO parameters, distinct from the more general 500

syntax-error code. Paired with 5.5.2 ("invalid command parameters"), it tells you precisely where

to look: the command verb was fine, but something in its parameter string was not — most often the

address itself or an SMTP service extension parameter appended to it.

A real transcript

EHLO yourdomain.com
250-mx.example.com
250 SIZE 35882577
MAIL FROM:<you@yourdomain.com SIZE=notanumber>
555 5.5.2 Syntax error in parameters

The example above shows a malformed SIZE extension parameter (not a valid integer) — a common

automated-cause when a client library miscalculates or mis-serialises the message size extension.

Basic SMTP command flow

MAIL FROM:<address> [extension-parameters] and RCPT TO:<address> [extension-parameters] both

require the address in angle brackets, followed by optional space-separated KEY=VALUE extension

parameters the server advertised support for in its EHLO response. A 555 means one of these

parameters — the address itself, or an extension value — does not match the expected grammar.

How the big three actually handle this

Few consumer mailbox providers return the literal 555 5.5.2 combination to typical sending

clients, since well-formed SMTP libraries rarely produce malformed parameters against them — but

their servers do still enforce the same grammar, and will return it if triggered.

Common causes of SMTP 555 5.5.2 – syntax error

1. Malformed email addresses — missing angle brackets, stray whitespace inside the brackets, or

invalid characters in the local part.

1. Missing angle brackets in SMTP commands — MAIL FROM:you@yourdomain.com instead of

MAIL FROM:<you@yourdomain.com> is rejected by strict servers.

1. Misconfigured email clients or scripts that construct the command string through naive

concatenation rather than a proper SMTP library.

1. Improper use of SMTP extensions — sending an extension parameter (SIZE=, BODY=, AUTH=)

the server did not advertise in EHLO, or formatting its value incorrectly.

Diagnose it yourself

1. Capture the exact command string sent, character for character, via your client's debug

logging or a raw network capture — this error is specifically about parameter formatting, so

approximate logging is not enough.

1. Check for angle brackets explicitly. Confirm both MAIL FROM and RCPT TO wrap the address

in < and > with no extra whitespace inside.

1. Cross-reference any extension parameters against the server's `EHLO` response — if your

client sends SIZE= but the server's capability list did not advertise SIZE, that mismatch

alone can trigger this.

1. Validate the address syntax independently against RFC 5321's address grammar before it ever

reaches the SMTP layer, to catch malformed input earlier in your pipeline.

How to fix SMTP Error 555 5.5.2

1. Validate email syntax before sending — reject or fix malformed addresses in your application

layer, before they ever reach the SMTP command construction step.

1. Correct your SMTP command formatting — ensure angle brackets are always present and no

extra whitespace or control characters creep into the parameter string.

1. Check your email client or framework configuration — update to a current, well-tested SMTP

library rather than constructing commands through manual string concatenation.

1. Review server logs and SMTP debug output on both sides where available, to confirm the exact

byte sequence that triggered the rejection.

What not to do

• Do not assume this is the same as 502 5.5.1 ("command not implemented") — that error means the

server does not support the command at all; 555 5.5.2 means it supports the command but

rejected this specific instance of its parameters. The fixes are different.

• Do not retry the identical malformed command — it will fail identically every time until the

parameter construction itself changes.

• Do not strip extension parameters entirely as a workaround without checking whether the server

actually requires them — some extensions (like SIZE on servers enforcing message-size limits)

exist for good reason, and removing them can shift the failure elsewhere rather than resolve it.

MailPilot's integrations rely on standard, well-tested SMTP client libraries for the providers it

connects to, so malformed command-parameter bugs of this kind are not something warm-up traffic

through MailPilot produces — worth checking first in any custom sending code running alongside it.