5.5.4 bounce: invalid command arguments

5.5.4Invalid command argumentsPermanent: retrying will not help

Typical wording
555 5.5.4 Unsupported option: SMTPUTF8

What it means

RFC 3463 defines X.5.4 as “invalid command arguments”: the verb was fine but a parameter was not acceptable. It typically comes with reply 501 (syntax error in parameters) or 555 (MAIL FROM or RCPT TO parameters not recognized, RFC 5321).

The most common trigger is an ESMTP parameter on MAIL FROM, such as SIZE=, BODY=8BITMIME or SMTPUTF8, sent to a server that never advertised that extension. Bad EHLO arguments (an empty hostname, or a name with illegal characters) also produce it on many servers.

A 4.5.4 is rare. Servers treat argument problems as permanent, so expect 5.5.4 and a bounce rather than a retry.

Likely causes

  • A client adding SMTPUTF8, REQUIRETLS or another extension to MAIL FROM without checking the EHLO list.
  • An EHLO or HELO argument that is blank, contains spaces or is not a valid hostname or address literal such as [203.0.113.10].
  • An address in MAIL FROM or RCPT TO with stray characters outside the angle brackets.
  • An AUTH command naming a mechanism the server does not support, or with a broken base64 argument.

How to fix it

  1. Look at the full reply text; servers usually name the parameter they rejected.
  2. Only send ESMTP parameters that appear in the server’s EHLO response, and leave out optional ones when in doubt.
  3. Give your server a proper fully qualified name for EHLO (for example `mail.example.com`) that also matches its PTR record.
  4. Re-test with the corrected client and confirm the receiver now answers 250 to MAIL FROM and RCPT TO.

Checks that apply

  • SMTP Diagnostics Lists the extensions the receiving server announces, so you can see which MAIL FROM parameters are allowed.
  • Reverse DNS (PTR) Shows the reverse DNS name of your sending IP, which is the name your EHLO argument should use.

The classification runs without network lookups and we never store your paste.

FAQ

How is 5.5.4 different from 5.5.2?
5.5.2 means the whole command could not be parsed. 5.5.4 means the command was recognised but one of its arguments was not accepted.
Can the recipient fix this for me?
Rarely. The receiver could enable the missing extension, but the normal fix is on the sending client, which should not use parameters the server did not offer.

All 191 bounce codes