5.3.4SMTP 5.3.4: Message exceeds the system size limit

Oversize relative to a per-message size cap on the processing mail system is what code 5.3.4 records under registry pattern X.3.4 at class 5. The registry allows this subcode only for permanent errors and covers limits set for physical or administrative reasons; it does not fix which part of the message is measured. Across the accepted provider examples for this code, four different scopes appear under the same digits: the whole message, the number of attachments, all header fields taken together, and one individual header field. The limit belongs to the mail system that applied it, not to the recipient address, so the status describes system policy rather than address validity.

A message larger than a per-message size limit imposed for physical or administrative reasons falls under X.3.4. The standard specifies this status as useful only for permanent errors; code 5.3.4 combines that meaning with class 5. The registry entry names the limit but not its value, not the element it measures, and not the system that holds it, so those three facts have to come from the response text and from the system that returned it. The basic reply paired with the enhanced code is not fixed either: the registry treats the associated basic status code as non-exclusive, the accepted examples pair 5.3.4 with both 552 and 550, and in each of them the enhanced class agrees with the reply class.

The leading digit 5 denotes a permanent failure of the current delivery request. The unchanged message should not be resubmitted to a system that applies the same limit; the permanence attaches to the message as submitted measured against that limit, not to the recipient address, which the code does not evaluate.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational guidance: stop automatic and manual retries of the unchanged message, because the same message measured against the same limit produces the same response. A new send is justified only after the element named in the response has been confirmed below the stated limit, or after the operator of the system that applied the limit has confirmed a change to it. A different destination system may hold a different limit; sending through it is a new send on a changed route, not a retry of the failed attempt.

Operational guidance: do not automatically add the recipient address to a suppression list solely because of 5.3.4. The code reports a limit held by a mail system and does not evaluate the recipient address or the state of the mailbox, so it is not evidence that the address is undeliverable. Inspect the full response, the message, the applied limit, and the event history for that address; suppress only when the applicable policy or an independent permanent signal justifies it.

• The message as submitted is larger than the total per-message size limit of the system processing it; the Gmail documentation table and the Rackspace Email example both reject on that scope.
• The number of attachments exceeds a limit on attachment count that the system states separately from total size; the Gmail documentation table has a distinct response for that case.
• A header limit is exceeded even when the body is small: the accepted examples enforce a ceiling on all header fields taken together, in Microsoft 365 / Exchange Online and in Gmail, and a ceiling on one individual header field, in Gmail.

1. Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 5.3.4 and that the basic reply is in the 5xx class; the accepted examples pair this code with both 552 and 550, so the basic digits alone do not identify the case.
2. Identify which system applied the limit: read the host named in the response or delivery report and match it to the hop in your own logs at the attempt time, because the limit belongs to the system that returned the response, which is not always the recipient's final mail system. Retain the full response text, the attempt time, the destination system, and the attempt identifier.
3. Read the response text to determine which element was measured, the whole message, the number of attachments, all header fields together, or one individual header field, then measure that same element on the message as it was submitted. Where the response reports the measured value and the applied limit, use those figures rather than inferring a limit value from the code.
4. Before a new send, confirm that the measured element is below the stated limit, or that the operator of the identified system has confirmed a change to the limit; a message that still receives 5.3.4 after a confirmed reduction is an escalation case, not a retry case.