5.3.4Message exceeds the system size limit

The message was permanently rejected because it is larger than the system's per-message size limit. Do not retry the same unchanged send.

The X.3.4 pattern means that the message is larger than a per-message size limit imposed for physical or administrative reasons. The standard specifies this status as useful only for permanent errors; code 5.3.4 combines that meaning with class 5.

The leading digit 5 denotes a permanent failure of the current delivery request. The unchanged message should not be resubmitted to a system with the same limit; the code does not, however, mean that the recipient address is invalid.

Class

Permanent failure

Retry

Do not retry unchanged

Suppression

Check the full context

Operational guidance: stop automatic and manual retries of the unchanged message. Consider a new send only after the message or its headers have been confirmed smaller, or after a confirmed change to the system limit.

Operational guidance: do not automatically add the recipient address to a suppression list solely because of 5.3.4. Inspect the full response, message, applied limit, and event history; suppress only when the applicable policy or an independent permanent signal justifies it.

• The message size exceeds a physical or administrative per-message limit in the system processing it.
• In the accepted Microsoft example, the message header size exceeds that product's fixed maximum.

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.
2. Correlate the response with the intended message, attempt time, and system that returned it; retain the full response text and determine the size of the message actually presented in that attempt.
3. Use the response and logs to determine whether a general per-message limit or a header-specific limit was exceeded, as in the accepted Microsoft example; do not infer a specific limit value from the code alone.
4. Before a new send, confirm that the message or its headers were actually reduced or that the applied system limit was changed.

Verified provider examples for 5.3.4 appear below, from Microsoft 365 / Exchange Online and Rackspace Email. They show real provider practice for this response and do not redefine the standard 5.3.4 meaning or cover every occurrence.

552 5.3.4 Header size exceeds fixed maximum size.

550 5.3.4 Message too large (G17)

Compare 4.3.0 for a temporary other or undefined mail-system problem and 4.3.1 for temporarily exhausted mail-system storage. These distinctions help separate a permanent per-message limit failure from other system conditions.

• 4.3.0Other or undefined temporary mail-system status
• 4.3.1Temporarily full mail system

The standard X.3.4 meaning, its permanent-only use, and concrete class assignment were verified against the IANA registry and RFC 2034, RFC 3463, and RFC 5248; the exact Microsoft example comes from accepted evidence p03-b03-microsoft-x-3-4-001. The sources were verified on July 17, 2026. Retry, diagnostic, and suppression recommendations are presented separately as operational guidance.

• iana-smtp-enhanced-status-codesT0 source

  Enumerated Status Codes / X.3.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.3.4

• p03-b03-microsoft-x-3-4-001T1 source

  Message limits section, message header size limit: quoted rejection error

• ext-src-rackspace-5-3-4-01T1 source

  docs.rackspace.com/docs/common-email-bounces > 'SMTP error' table, row 'Message too large (G17)'

Last verified: 17 July 2026