SMTP error 5.3.4 Message too big for system
The message is larger than the whole system will carry, not just larger than one mailbox is allowed. It comes back as 552 or 554 with wording about exceeding the maximum message size, and no recipient at that organisation will take it, because the ceiling belongs to the platform rather than to a person. Exchange Online caps messages at a hundred and fifty megabytes for everyone. Whichever system in the chain has the smallest limit decides.
What SMTP error 5.3.4 Message too big for system actually means
Think of the difference this way. A per-recipient limit is a rule somebody wrote about one mailbox and can rewrite this afternoon. This is the building's ceiling: the maximum the mail system itself is built to handle, which no administrator can raise beyond the platform's own hard limit. That is why sending the same message to a colleague of the recipient fails identically, and why asking their IT team for an exception gets a polite no. Well-behaved servers advertise their maximum during the SMTP greeting, so an attentive sender can refuse the message before transferring a hundred megabytes it knows will be rejected.
The message is larger than per-message size limit. This limit may either be for physical or administrative reasons. This is useful only as a permanent error.
— RFC 3463
How 5.3.4 appears in a bounce
A server reporting this condition sends it alongside a three-digit reply code, and a bounce prints the two together. The registry lists these pairings for this status: 552 5.3.4, 554 5.3.4. Which one you get depends on the point in the conversation at which the server refused.
The leading 5 is the server's verdict rather than part of the code's identity: it marks this as a permanent failure, which means the sending server has given up and returned the message.
What causes SMTP error 5.3.4 on a business phone system
- A genuinely oversized messageVideo files, CAD drawings, uncompressed photographs from a site visit and full database exports. Email was never designed to move files of that size and every system in the path has a view about it.
- A relay or gateway with a lower ceiling than the destinationThe smallest limit anywhere along the route wins. A smart host, a filtering gateway or a partner's on-premise server can sit well below the destination's maximum, so a message Exchange Online would accept never reaches it.
- Encoding overhead on a message that was close to the lineBase64 encoding adds around a third, and inline images, a rich signature and any encryption wrapper add more on top. The message on the wire is always larger than the files you attached.
- A forwarded chain that has accumulated attachmentsA thread forwarded a dozen times can carry every attachment ever added to it, several times over where people replied with attachments included. Nobody notices until the total crosses a limit somewhere.
- An application sending an oversized report or exportScheduled reports, log bundles and backup summaries that grow month on month. They send perfectly well for a year and then start failing, which looks mysterious until you compare against last quarter's file size.
How to fix SMTP error 5.3.4
- Share a link rather than attaching the fileFor anything substantial this is the answer, not a workaround. Upload to SharePoint or OneDrive, share the link and set an expiry. The recipient gets the file, no mailbox stores a copy, and no size limit applies.
- Find out which system rejected itThe bounce names the host that refused the message and normally states its maximum. If that host is a gateway rather than the destination platform, the limit to change is on the gateway and the destination's settings are irrelevant.
- Compress or split the content, with realistic expectationsZipping helps with documents and hardly at all with video or images that are already compressed. Splitting across several messages works but is fragile, because a reply quoting everything reassembles the problem.
- Check every hop's limit, not just the endpointsWhere large messages must work reliably, list the limit on the sending platform, on any connector, on the gateway and on the destination, and set them consistently. One low value in the middle makes the other three meaningless.
- Move recurring large transfers off email entirelyIf a report regularly bumps against the ceiling, put it somewhere the recipient collects it from — a shared library, SFTP or a secure transfer service — and email a notification instead. That removes the failure permanently.
Fixing the underlying problem
This page explains the code. These guides walk through the fix in detail.
Questions about SMTP error 5.3.4
How is this different from a message length limit on the mailbox?
Can our provider raise the limit for us?
Why did the message fail after several minutes rather than immediately?
Related SMTP status codes
- SMTP error 5.2.3Message length exceeds administrative limit
- SMTP error 5.3.0Other or undefined mail system status
- SMTP error 5.7.16Message is too big for the specified priority
Source. SMTP error 5.3.4 Message too big for system is defined in RFC 3463 and registered in the IANA SMTP Enhanced Status Codes registry. The causes and fixes above are drawn from our own experience supporting UK business email systems.