TL;DR
4.5.4 indicates invalid command arguments in this transaction. Capture the command and state, correct a confirmed range or unsupported-feature issue, use bounded retries, and do not suppress the recipient from this code alone.
What this code means
X.5.4 covers invalid arguments on an otherwise valid mail-transaction command: the value may be out of range or represent an unrecognized feature. The concrete accepted variant is class 4 despite a registry note about permanent-error use.
Technical meaning
The command was valid, but an argument fell outside the reporting system's accepted range or requested a feature it did not recognize. The code alone cannot choose between those explanations or show that an unchanged retry will work.
Delivery status
The leading 4 marks the current outcome as temporary, not permanent rejection. The registry-note tension means the full command and transaction context must control interpretation.
- Class
- Temporary failure
- Retry
- Controlled retry
- Suppression
- Check the full context
Retry decision
Check recipient eligibility and inspect the exact command, arguments, and transaction state. Correct a confirmed argument defect, then retry with idempotency, backoff, jitter, and a limit; stop recurring unchanged failures for diagnosis.
Suppression decision
Do not suppress from 4.5.4 alone. Use an independent permanent, address-specific signal or policy before changing recipient state.
Common causes
- A command argument was outside the range accepted by the reporting system.
- A valid command argument requested an unrecognized feature.
Diagnostic steps
- Confirm exactly 4.5.4 with a 4xx reply and retain the complete response.
- Record the command, arguments, preceding transaction state, reporting system, and time.
- Determine whether the argument was out of range or represented an unrecognized feature from the trace and logs.
- Correct the confirmed issue, retry in a bounded way, and stop after success, permanent result, or limit exhaustion.
Actions by owner
Sender administrator
- Preserve command/argument evidence and correct confirmed client or transaction-state issues before retrying.
- Avoid repeated sends with unchanged rejected arguments.
Provider
- Retain precise command and argument telemetry for diagnosis.
- Correct a confirmed managed capability or validation issue while preserving accurate status reporting.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
Last verified:
