5.5.4Invalid command arguments

A mail system permanently rejected a valid protocol command because its arguments were invalid. Do not retry the same attempt without changing the arguments or conditions that caused the rejection.

The X.5.4 pattern means that a valid mail transaction protocol command was issued with invalid arguments: the arguments were out of range or represented unrecognized features. The T0 registry says this detail is useful only as a permanent error, and the concrete 5.5.4 code has the corresponding class 5.

The leading digit 5 denotes a permanent failure for the current message in this context. The code alone identifies neither the exact command nor argument, does not distinguish an out-of-range value from an unrecognized feature, and does not establish that the recipient address is invalid.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational recommendation: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after the argument or feature compatibility has demonstrably been corrected, or the relevant configuration has materially changed; first check suppression state again and use idempotency.

Operational recommendation: do not add the address to a suppression list based on 5.5.4 alone because the code describes a protocol-command argument, not mailbox status. Inspect the full response, command, arguments, system returning the code, and other permanent events, then suppress only according to the established cause and applicable policy.

• An argument to a valid mail transaction protocol command was outside the range accepted by the system that returned the code.
• An argument to a valid command represented a feature that the system returning the code did not recognize.

1. Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 5.5.4 and that the basic reply is in the 5xx class; retain the complete original response text.
2. Correlate the response with the intended message, attempt time, system that returned the code, and exact command and arguments; also retain the transaction state before the command.
3. Use the trace, logs, and documented system capabilities to determine whether an argument was out of range or represented an unrecognized feature. If the response identifies HELO/EHLO, inspect an empty or invalid domain argument and, in the context of the accepted Microsoft example, connection restrictions as well; do not generalize those practices to every 5.5.4 case.
4. Stop unchanged retries; before any new send, confirm that the established cause has been corrected and check suppression state again.

The accepted Gmail examples at the HELO stage read exactly: «501 5.5.4 HELO/EHLO argument “...” invalid, closing connection. 501 5.5.4 https://support.google.com/mail/?p=helo» and «501 5.5.4 Empty HELO/EHLO argument not allowed, closing connection. 501 5.5.4 https://support.google.com/mail/?p=helo». The accepted Microsoft Exchange Server example for EHLO validation reads exactly: «501 5.5.4 Invalid domain name». These are practices of specific products, not the standards definition of X.5.4. Only the accepted Microsoft evidence additionally describes invalid characters in the domain name or connection restrictions and recommends correcting the EHLO argument and checking destination connection restrictions.

501 5.5.4 HELO/EHLO argument “...” invalid, closing connection.
501 5.5.4 https://support.google.com/mail/?p=helo

501 5.5.4 Empty HELO/EHLO argument not allowed, closing connection.
501 5.5.4 https://support.google.com/mail/?p=helo

501 5.5.4 Invalid domain name

Compare 2.5.0 as a general protocol status in the success class; 4.5.0 for another or undefined temporary protocol problem; 4.5.1 for a temporarily invalid command; and 4.5.3 for a temporary excess of recipients. Do not assign those codes without exact evidence from the response.

• 2.5.0Other or undefined protocol status
• 4.5.0Other or undefined temporary protocol status
• 4.5.1Temporarily invalid protocol command
• 4.5.3Too many recipients

The canonical T0 meaning of X.5.4, its note about permanent-error-only use, and the assignment of code 5.5.4 to class 5 were verified against the IANA registry and RFC 2034, RFC 3463, and RFC 5248. The exact Gmail practice examples come from accepted evidence gmail-ph01-123 and gmail-ph01-124, while the Microsoft practice example and explanation come from p03-b04-microsoft-x-5-4-001. The sources were verified on July 17, 2026; retry, diagnostic, and suppression guidance is presented separately as operational advice.

• iana-smtp-enhanced-status-codesT0 source

  Enumerated Status Codes / X.5.4

• rfc5248T0 source

  Section 2.1: registry fields and non-exclusive Associated Basic Status Code

• rfc2034T0 source

  Section 4: enhanced status class agrees with SMTP reply class

• rfc3463T0 source

  IANA registry reference for X.5.4

• gmail-ph01-124T1 source

  Section 'You get a HELO/EHLO error message', second code block (rendered lines 124-125)

• gmail-ph01-123T1 source

  Section 'You get a HELO/EHLO error message', first code block (rendered lines 121-122)

• p03-b04-microsoft-x-5-4-001T1 source

  Step 4 > EHLO command: exact failure response

Last verified: 17 July 2026