SMTP Error 555

SMTP Error 555 is a permanent (5xx) reply defined in RFC 5321 §4.1.1.11 with the exact wording: "If the server SMTP does not recognize or cannot implement one or more of the parameters associated with a particular MAIL FROM or RCPT TO command, it will return code 555" (the code itself is also listed in the §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 SMTP conversation, not about the message body or the visible "To:"/"From:" header fields.

This distinction matters: 555 is almost always a sender-side / client-side configuration problem, not a bad recipient mailbox (that would be 550). Editing or re-spelling the recipient address usually does nothing for a genuine 555.

What causes SMTP Error 555?

A 555 is returned when the server understood the command verb (MAIL or RCPT) but could not accept what came after the address, or the line was malformed. Common triggers:

• An ESMTP extension parameter the server doesn't implement. SMTP commands can carry service extensions, e.g. MAIL FROM:<a@b.com> SIZE=10240000, BODY=8BITMIME, AUTH=<>, or DSN parameters like RET=/ENVID= on MAIL and NOTIFY=/ORCPT= on RCPT (RET=/ENVID=/NOTIFY=/ORCPT= are defined by RFC 3461, the DSN extension, not RFC 5321 itself). If your client sends a parameter that 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 valid mail transaction protocol command was issued with invalid arguments, either because the arguments were out of range or represented unrecognized features."
• Malformed envelope syntax — 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 the enhanced code X.5.2 "Syntax error" — for example, a MAIL FROM:<user@example.com missing its closing angle bracket is a documented, reproducible way to make Gmail's servers return 555 5.5.2 Syntax error, goodbye.
• A client that skips EHLO or ignores its (failed) result and sends ESMTP parameters unconditionally to a plain SMTP (RFC 821) server. A true RFC 821-only server never advertises extensions, so a spec-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 (or whether) the server advertised.

If you instead see the visible error mention a mailbox that doesn't exist or is full, you are likely looking at a 550/552, not a true 555. Likewise, a non-ASCII address rejected by a server that doesn't support SMTPUTF8 is standardly a 550 (on MAIL) or 553 (on RCPT) with enhanced code X.6.7 per RFC 6531 §3.5 — not a 555. If you're chasing a genuine 555, look for an unrecognized or unimplemented ESMTP parameter (or malformed syntax) on the envelope command, not an address-encoding issue.

How do I fix SMTP Error 555?

Because the fault is in the SMTP dialogue you (or your library/relay) generate, fix it on the sending side:

1. Capture the raw SMTP transcript. Enable protocol/debug logging in your client 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.
2. Check what the server actually supports. Connect and read the EHLO response — it lists supported extensions (e.g. SIZE, 8BITMIME, SMTPUTF8, DSN, AUTH). Only send parameters that appear there.

EHLO mail.example.com
250-mx.receiver.com
250-SIZE 26214400
250-8BITMIME
250 SMTPUTF8

3. Remove or correct the offending parameter. If you're setting a parameter (e.g. SIZE=, DSN's RET=/NOTIFY=) that the server didn't advertise or that exceeds its advertised limit, drop or lower it.
4. Fix envelope syntax. Ensure the path is wrapped in angle brackets with no extra spaces: MAIL FROM:<sender@example.com> and RCPT TO:<recipient@example.com>. Most SMTP libraries handle this for you — if you are hand-building commands, this is the usual culprit.
5. Disable unneeded extensions in your client/relay. In libraries like Nodemailer or Python's smtplib, avoid forcing DSN/8BITMIME/AUTH options unless the destination supports them; let the client negotiate from EHLO.