SMTP error 552 5.3.4: message too big for the system

SMTP error 552 5.3.4 means the message exceeded a size limit enforced by the mail system

itself. The enhanced code 5.3.4 is RFC 3463's "message too big for system" - a distinct

condition from 552 5.2.2 (mailbox over quota, covered separately), which is about one

recipient's remaining storage. 5.3.4 is a hard ceiling applied by a relay, gateway, or the

receiving platform as a whole, independent of how much free space any individual mailbox has.

Fault: sender, specifically message size versus a published or implied limit on the delivery

path.

Why it happens

• The message exceeds the receiving platform's absolute size cap. Most major providers cap

total message size (commonly in the 25-50 MB range including attachments and encoding

overhead) regardless of mailbox quota.

• A relay hop in the middle of the delivery path has a lower limit than the final destination.

A message can be well under Gmail's own cap but still rejected by an intermediate gateway (a

corporate email security gateway, a mailing-list relay) with a stricter limit.

• Base64 encoding of attachments inflates the effective size by roughly a third over the raw

file size - a file that looks comfortably under a limit can push the encoded MIME message over

it.

• Embedded images or inline content add up invisibly. Several moderately sized inline images

in an HTML email body can collectively exceed a limit with no single large attachment to blame.

The transcript

$ swaks --to test@mailpilots.in --server mx.example.net --attach large-file.pdf
-> DATA
<- 354 Start mail input; end with <CRLF>.<CRLF>
-> [... MIME content, ~40MB after base64 encoding ...]
-> .
<- 552 5.3.4 Message size exceeds fixed maximum message size

The rejection happens at the end of DATA, after the full message has already been transmitted

• which is why this error wastes more sending bandwidth than almost any other on this list.

How the big three word it

Diagnose it

$ ls -la large-file.pdf
-rw-r--r-- 1 user user 28311552 large-file.pdf

$ python3 -c "print(28311552 * 4/3 / 1024 / 1024, 'MB after base64')"
35.93798828125 MB after base64

Base64 encoding adds roughly 33% to a binary attachment's footprint, which is the single most

common reason a file that "looks fine" at its raw size still triggers this error once MIME

encoding is accounted for.

The fix, in order

1. Check the raw attachment size and multiply by roughly 1.33 to estimate the actual

transmitted MIME size, not the file size on disk.

1. Compress or convert large attachments before sending - PDF recompression, image

downscaling, or switching from an uncompressed format can often bring a file comfortably under

any limit.

1. Switch to a shared-link delivery method for large files (a cloud storage link rather than

an attachment) when the content genuinely exceeds reasonable email size limits.

1. Check every hop's limit, not just the final destination's. If a corporate gateway or

mailing-list relay sits between you and the recipient, its limit may be the binding one even

when the recipient's own mailbox would accept a larger message.

1. Split a message into several smaller ones only as a last resort, and only when the content

genuinely must travel as attachments rather than a link.

What not to do

• Do not assume this is the mailbox-quota error (`552 5.2.2`). The fixes are unrelated:

quota is the recipient's problem and clears on its own; size-limit is yours and requires

changing the message.

• Do not retry the identical oversized message repeatedly. It is a permanent 5xx for this

exact content; nothing changes between attempts.

• Do not strip MIME boundaries or hand-edit encoding to "shrink" a message. This corrupts the

message for the recipient even on the rare occasion it gets past a size check.

• **Do not ignore intermediate relay limits when troubleshooting against the final provider's

published cap.** A message under Gmail's limit can still be rejected by whatever sits in front

of it.

MailPilot's monitoring distinguishes a size-based rejection from a quota-based one in its event

log, so a spike in 5.3.4-style failures after a product change (larger default attachments, new

inline images) is visible as a size problem rather than getting mixed into generic bounce

figures.