Blazalek.com

5.2.3Message exceeds the mailbox limit

The message was permanently rejected because its length exceeds the administrative limit for the recipient's specific mailbox. Do not retry the unchanged send.

Category
Recipient mailbox
Class
Permanent failure
Retry
Do not retry unchanged
Suppression
Check the full context

What this code means

The message was permanently rejected because its length exceeds the administrative limit for the recipient's specific mailbox. Do not retry the unchanged send.

Technical meaning

The X.2.3 pattern means that an administrative message-length limit set for a specific mailbox has been exceeded. The standard identifies this code for a mailbox limit lower than the general system limit and says it should be used as a permanent failure. Code 5.2.3 combines that meaning with class 5.

Delivery status

The leading digit 5 denotes a permanent failure of the current delivery request. Retrying the same message to the same mailbox without changing the message length or the limit should not be expected to succeed.

Class
Permanent failure
Retry
Do not retry unchanged
Suppression
Check the full context

Retry decision

Operational guidance: stop automatic and manual retries of the unchanged message. Consider a new send only after the message has been confirmed smaller or the mailbox limit has been confirmed changed.

Suppression decision

Operational guidance: do not automatically add the recipient address to a suppression list solely because of code 5.2.3. The code describes the relationship between message length and a mailbox limit, not address validity; decide only after inspecting the full response, address, message, and applicable policy.

Common causes

  • The message length exceeds the administrative limit set for the recipient mailbox; that mailbox's limit may be lower than the general system limit.

Diagnostic steps

  1. Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 5.2.3 and that the basic reply is in the 5xx class.
  2. Correlate the response with the intended message, recipient address, and attempt time, then determine the length of the message actually transferred in that attempt.
  3. Ask the recipient or recipient-system administrator to confirm the limit applied to that mailbox and compare it with the message length; do not infer a specific limit value from the code alone.
  4. Before a new send, confirm that the message was actually reduced or that the mailbox limit was changed.

Actions by owner

Sender

  • Stop retries of the unchanged message and retain the full response and failed-attempt context.
  • Agree with the recipient on a safe way to reduce the message, and send again only after a confirmed change.

Recipient

  • Confirm to the sender that the mailbox address used is correct, and give the code and attempt time to the administrator if the limit is unknown.
  • Agree with the sender on an acceptable way to deliver a smaller message, or wait for a confirmed limit change.

Recipient administrator

  • Inspect configuration and logs for the specified mailbox and attempt time to confirm the applicable limit and how it applied to this message.
  • If policy permits, adjust the limit or communicate the confirmed restriction to the sender and recipient; verify the change before another attempt.

Sources and verification

The standard meaning of X.2.3, its permanent use, and concrete class assignment were verified against the IANA registry and RFC 2034, RFC 3463, and RFC 5248 on July 17, 2026. Diagnostic, retry, and suppression recommendations are presented separately as operational guidance.

  • Enumerated Status Codes / X.2.3

  • 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.2.3

Last verified:

Wojtek Blazalek

Email deliverability expert

Stuck on this error code? I help teams clear the root cause of rejections and fix authentication and reputation — so email lands in the inbox.

Hands-on deliverability work for teams that send at scale.