5.2.3: your message is too large for the recipient's mailbox
This is the per-recipient size rejection: one mailbox refused the message for its length. Here is how it differs from the system-wide 5.3.4, why the limit is smaller than it looks, and the practical ways around a large attachment.
What the bounce means
5.2.3 is the enhanced status code RFC 3463 defines for a message whose length exceeds an administrative limit on the recipient's side. The receiving server accepted your connection, looked at the size of the message, compared it against what this particular mailbox is allowed to receive, and refused it. Because it is a generic code rather than one provider's invention, the three-digit SMTP reply in front of it varies by server; it often appears as 552 5.2.3 or 554 5.2.3, and the enhanced code is the part you can rely on.
The leading 5 makes it a permanent failure. Your server will not retry, and resending the identical message will produce the identical bounce. Nothing about your domain, your IP, or your authentication is in question here: the message itself is the problem, and the fix is to send something smaller.
How 5.2.3 differs from 5.3.4
RFC 3463 defines two size rejections, and the difference is scope. 5.2.3 lives in the mailbox family: this recipient's mailbox, or a per-recipient policy an administrator set for them, refused the size. 5.3.4 lives in the mail-system family: the receiving system as a whole will not take a message that large, no matter who it is addressed to.
The practical tell: send the same message to several people at the same domain. If it bounces with 5.2.3 for one recipient and delivers to the rest, you have hit an individual mailbox limit, often one set deliberately for a shared or restricted mailbox. If it would bounce for everyone, the system-wide ceiling is the one in play.
Why the limit is smaller than it looks
Receivers count the size of the message after encoding, not the size of the file you attached. Attachments travel base64-encoded, which inflates them by roughly a third, and the message headers and body add a little on top. So a mailbox advertising a 20 MB limit fits an attachment of roughly 14 to 15 MB, and an attachment that looks comfortably under the line on disk can still bounce. If a bounce surprises you, this inflation is usually why.
How to handle it
- Send a link instead of the file. Upload the file to a file-sharing service or shared drive and mail the link. This is the durable fix: it removes the size question entirely and survives whatever limit the next recipient has.
- Shrink the attachment. Compress it, export the document at a lower resolution, or trim it to the pages or sheets the recipient actually needs. Remember the encoding overhead: aim well under the limit, not just barely under it.
- Split the content. Several smaller messages each clear a per-recipient limit that one large one does not. Clumsy, but sometimes the fastest path when the recipient cannot receive links.
- Ask about the mailbox limit. Since
5.2.3is per-recipient, the recipient's administrator may be able to raise the limit for that mailbox if large files from you are routine.
Frequently asked
What does 5.2.3 mean?
The message exceeds the size that this specific recipient's mailbox accepts. It is a permanent rejection: the receiving server looked at the message length, compared it against a per-recipient limit, and refused it. Resending the same message unchanged will bounce again.
How is 5.2.3 different from 5.3.4?
Both are size rejections, but 5.2.3 is scoped to one recipient's mailbox while 5.3.4 means the whole receiving system refused the size. In practice: if a message to several people at the same domain bounces for only one of them, that points at 5.2.3; if the server would refuse it for everyone, that is 5.3.4 territory.
Why did my attachment bounce when it was under the stated limit?
Receivers measure the encoded message, not the file on your disk. Email attachments travel base64-encoded, which makes them roughly a third larger, and headers and body text add a little more. A mailbox with a 20 MB limit therefore fits an attachment of roughly 14 to 15 MB, not 20.
Will the message go through if I just resend it?
No. 5.2.3 is a 5.x.x permanent failure, so the receiver will keep refusing the same message at the same size. Either make the message smaller (compress or trim the attachment, or replace it with a download link) or ask the recipient whether their mailbox limit can be raised.
Forward the bounce to your workspace's private diagnose address and trustyourinbox reads it for you: the cause in plain English, the evidence from up to eight sources, what was ruled out, and a one-click DNS fix when one exists. Then a recovery watch confirms from the receivers' own reports once your mail passes again.
Keep reading
5.3.4 message size limit
The sibling code: the whole receiving system, not one mailbox, refused the size.
5.2.2 mailbox full
The other per-mailbox limit: the recipient is over quota rather than your message being too big.
SMTP error codes, explained
How reply codes and enhanced status codes fit together, and which part to trust.
Why email bounces or lands in spam
The wider map of delivery failures, from size limits to authentication.
Forward a bounce as an attachment
How to preserve the full bounce so a person or a tool can read the real code.
Last verified 2026-07-16 against RFC 3463 (Enhanced Mail System Status Codes).
Free for one domain. Set up in five minutes. We parse the reports; you read plain-English summaries.