SMTP Error 552: Message Size Exceeded, Storage Allocation and Blocked Attachments

A 552 reply means that the receiving side stopped the message because of size or storage. The SMTP standard calls it "requested mail action aborted: exceeded storage allocation", and servers use it in three quite different situations: the message is bigger than the server allows, the recipient has no room left, or the message contains an attachment type that the receiver refuses to accept. The three look similar in a bounce, and the first reaction, "make the file smaller", is right for only one of them. This guide explains how to tell them apart, what limits apply on the common platforms, why a 20 MB file produces a message that is far larger than 20 MB, how to check and change limits on servers you run and what to do as a sender when you do not control the receiving side. It finishes with practical alternatives to sending large files by email.

Three meanings, one code

The enhanced codes are defined in RFC 3463: in 5.3.4 the second number, 3, means "mail system status" and the third, 4, means "message too big for system", while a second number of 2 refers to the mailbox. Servers do not always use the codes consistently, so read the text, not only the number.

Why the message is bigger than the file

Email carries binary files as text. Attachments are encoded in base64, which turns every three bytes into four characters and adds line breaks, so the encoded attachment is roughly a third larger than the original file. A 20 MB PDF becomes about 27 MB inside the message, before headers, the message body and any other attachments are added. Limits apply to the whole encoded message, which is why a file that seems to be under the limit still fails. If you attach several files, add them together. Embedded images in HTML add to the total as well. The explanation of the encoding is in MIME attachments explained and the limits of the large providers are in attachment size limits of Gmail, Outlook, Yahoo and iCloud.

Typical limits

Limits vary by provider, plan and configuration, and they change. Treat these values as orders of magnitude and check the current documentation for the systems you send to.

The practical rule: the effective limit is the lowest one on the path, usually the recipient's, and you cannot see it in advance. If the message must reach a corporate recipient, assume a limit around 10 MB and keep attachments well below it.

Fixes for senders

Make the attachment smaller

Compress images before attaching them, export PDFs with a lower image quality, remove unused pages and embedded fonts, and zip text-heavy files. Avoid re-zipping files that are already compressed, since it gains little. Check the size of the message in your sent folder to see the encoded total.

Send a link instead

The best answer to a large file is not to send it by email at all. Upload it to a file-sharing or cloud storage service, set sensible access and expiry, and send the link. The message stays small, the recipient downloads the file on demand and you can revoke access. For automated mail, such as invoices or reports, generate a secure, time-limited download URL in the message. This also avoids content scanners that slow or block large messages.

Split carefully, or not at all

Splitting one large attachment across several messages works but is clumsy, can trigger rate limits and can fill the recipient's mailbox. Use it only as a last resort and tell the recipient how to reassemble the parts.

Change the format of blocked files

For 552 5.7.0 style rejections of attachment types, the rule is set by the receiver. Executables, scripts, some archives (especially password-protected ones) and files with double extensions are commonly refused because they are used to spread malware. Send the content in a different way: a document instead of a script, an unprotected archive from a trusted sender, or a link to a download page. Do not rename the extension to bypass the filter; scanners look at file contents, and attempts to disguise a file make the message look worse. Also see content and spam filters.

Fixes for administrators

Postfix

# /etc/postfix/main.cf
message_size_limit = 52428800        # 50 MB
mailbox_size_limit = 0               # 0 = no mailbox limit in Postfix itself
virtual_mailbox_limit = 0

# apply
sudo postfix reload

# check the active value
postconf message_size_limit

If you raise message_size_limit, make sure the downstream components match: the mailbox store (Dovecot quotas), the content filter (amavis, rspamd or a milter with its own size cap) and the web interface. A limit set in only one place produces confusing errors, where the SMTP conversation accepts the message and a later stage rejects it. Also consider memory and disk use, since larger messages make the queue heavier.

Exchange and Microsoft 365

Limits exist at several levels: organisation, send and receive connectors, and individual mailboxes. The effective limit is the smallest. Check them with the Exchange management tools, and align them. For Microsoft 365, the documentation states the default and maximum values and how to change them. Remember that the limit applies to the encoded message and not to the file size shown in a file manager.

Other servers and gateways

Exim has message_size_limit, Sendmail has MaxMessageSize and hosted panels expose a setting in the control panel. Security gateways usually have their own limit and may reject earlier than the mail server. If your outgoing provider enforces a limit, the error comes from them, not from the recipient; check their documentation.

Diagnosing which form you have

1. Read the full bounce and find the enhanced code and text.
2. If the text mentions size or length, compare the encoded message size with likely limits and test with a smaller message to the same recipient.
3. If it mentions quota or mailbox, ask the recipient to check their storage; a small test message will also fail while the mailbox is full.
4. If it mentions attachment, type or content, remove or change the attachment and resend.
5. If the bounce is from your own server or provider, look at your outbound limits first.
6. Record the working size so that your team knows the practical limit for that recipient or domain.

Design for size in applications

If your application sends attachments, make size a first-class concern. Check the size before queuing and give the user a clear message, not a delayed bounce. Offer links for anything large. Store generated reports in your own storage and email a signed URL. Keep HTML emails light: host images on a server instead of embedding them, and keep total HTML below the sizes at which some clients clip messages. Handle 552 as a permanent failure for that message, and do not retry it unchanged. The queue and retry design is covered in designing reliable email sending queues.

References and further reading

• RFC 5321: Simple Mail Transfer Protocol
• RFC 3463: Enhanced Mail System Status Codes
• Postfix documentation: Postfix Configuration Parameters