SMTP error 555
MAIL FROM / RCPT TO parameters not recognized or not implemented.
Updated Jul 1, 2026
SMTP 555 is a permanent failure defined in RFC 5321 as "MAIL FROM/RCPT TO parameters not recognized or not implemented". The server accepted your MAIL FROM or RCPT TO command but rejected an ESMTP parameter on it (SIZE, BODY, AUTH) or found the command malformed. Fix it by correcting the envelope-command syntax and dropping unsupported extension parameters, not by editing recipient addresses.
Fix the envelope syntax and drop unsupported extension parameters.
What it means
555 is a permanent 5xx reply defined in RFC 5321 section 4.1.1.11: if the server does not recognize or cannot implement one or more of the parameters on a MAIL FROM or RCPT TO command, it returns 555 (the code is also listed in the section 4.2.3 reply-code table). It is an envelope-command error. The server is complaining about the MAIL FROM or RCPT TO line of the conversation, not about the message body or the visible To and From header fields. This matters: 555 is almost always a sender-side or client-side configuration problem, not a bad recipient mailbox (that is 550), so editing or re-spelling the recipient address usually does nothing.
Common causes
Commands can carry extensions such as "MAIL FROM:<a@b.com> SIZE=10240000", BODY=8BITMIME, AUTH=<>, or DSN parameters like RET= and ENVID= on MAIL and NOTIFY= and ORCPT= on RCPT (those DSN parameters come from RFC 3461, not RFC 5321). If your client sends a parameter the receiver never advertised in its EHLO response, the server may reject it with 555. Per RFC 3463 the paired enhanced code is often X.5.4, "invalid command arguments".
A missing angle bracket around the path (MAIL FROM: a@b.com instead of MAIL FROM:<a@b.com>) or a stray space in the command. This commonly surfaces as X.5.2 "syntax error"; a MAIL FROM:<user@example.com missing its closing angle bracket is a documented, reproducible way to make Gmail return "555 5.5.2 Syntax error, goodbye".
A client that skips EHLO, or ignores a failed EHLO, and sends ESMTP parameters unconditionally to a plain RFC 821 server. A true 821-only server never advertises extensions, so a compliant client falls back to HELO and the base command set; a 555 here points to a client bug that offers extension parameters regardless of what the server advertised.
How to fix it
- Capture the raw SMTP transcript
Enable protocol or debug logging so you can see the literal MAIL FROM and RCPT TO lines and the exact 555 response. This tells you which command and which parameter was rejected.
- Check what the server actually supports
Read the EHLO response, which lists supported extensions (SIZE, 8BITMIME, SMTPUTF8, DSN, AUTH). Only send parameters that appear there, for example a server advertising "250-SIZE 26214400", "250-8BITMIME", and "250 SMTPUTF8".
- Remove or correct the offending parameter
If you set a parameter such as SIZE= or a DSN RET= or NOTIFY= that the server did not advertise or that exceeds its advertised limit, drop or lower it.
- Fix envelope syntax
Wrap the path in angle brackets with no extra spaces: "MAIL FROM:<sender@example.com>" and "RCPT TO:<recipient@example.com>". Most libraries handle this; if you hand-build commands, this is the usual culprit.
- Disable unneeded extensions in your client or relay
In Nodemailer or Python smtplib, avoid forcing DSN, 8BITMIME, or AUTH options unless the destination supports them, and let the client negotiate from EHLO.
Paired code
A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:
Common questions
Is SMTP Error 555 a problem with the recipient email address?
Usually no. 555 is an envelope-command error about the MAIL FROM or RCPT TO line, typically an unsupported ESMTP parameter or malformed syntax on the sending side. A bad or nonexistent mailbox returns 550, and a non-ASCII address rejected for lack of SMTPUTF8 returns 550 or 553, not 555. Re-spelling the recipient rarely fixes a genuine 555.
What is the difference between SMTP 555 and 501?
501 is a general "syntax error in parameters or arguments" for a command. 555 is specific to unrecognized or unimplemented parameters on MAIL FROM or RCPT TO, such as an ESMTP extension the server never advertised.
What enhanced status code goes with SMTP 555?
Often X.5.4 "invalid command arguments" for an unsupported parameter, or X.5.2 "syntax error" for malformed envelope syntax, both from RFC 3463.