SMTP "552 5.3.4 Message size exceeds fixed limit"

What’s actually happening

A message with attachments bounces right after the DATA command or during transfer. The bounce names a size limit, often 10, 25, or 35 MB. The trap is encoding: Base64 inflates attachments by about 33%, so a 20 MB file rides as roughly 27 MB on the wire, and a folder of files that "looks" under the cap still trips it. Smaller messages from the same sender go through fine.

Common causes

• Total encoded message size exceeds the receiving server's max — the limit applies after Base64, not to the raw file size
• Base64 overhead (~33%) plus MIME boundaries and headers pushing a near-limit message over the edge
• The send-side limit being larger than the receive-side limit, so your server accepts it but the destination refuses it
• An Exchange/Microsoft 365 connector or mailbox `MaxReceiveSize` set lower than the organization default
• Several embedded images or a long forwarded thread quietly accumulating size beyond what the visible attachment suggests

How to fix it

1. Send a link instead of the fileUpload to OneDrive, Google Drive, Dropbox, or a signed S3 URL and paste the link. This sidesteps the size cap entirely and is the most reliable fix for large files.
2. Compress or shrink the attachmentZip documents, downsample images, or export the PDF at a smaller size. Remember the cap is on the encoded size, so target roughly 25% under the stated limit to leave room for Base64 overhead.
3. Confirm the receiving limit, not just yoursThe bounce comes from the destination, so check the recipient's limit. For Microsoft 365 the org default is 25-35 MB; the recipient admin can check `Get-Mailbox | fl MaxReceiveSize` and connector limits in PowerShell.
4. Raise the limit on the receiving side if you control itOn Exchange Online adjust the transport config or connector `MaxReceiveSize`; in Postfix raise `message_size_limit` (bytes) and bounce/reload. Note Postfix `mailbox_size_limit` must be >= `message_size_limit`.
5. Split the contentSend attachments across multiple messages so each stays under the cap, or move large items to shared storage and reference them.