SMTP 552 Message Size Exceeded: 5.3.4 and 5.2.3 Limits Explained

A 552 on a size problem means the message is bigger than some limit along the delivery path. RFC 5321 defines 552 as "Requested mail action aborted: exceeded storage allocation", and RFC 3463 gives the enhanced codes that say which limit was hit. It is a permanent failure; the same message will fail again until it gets smaller or the limit changes.

552 5.3.4 Message size exceeds fixed limit

postfix/smtp[3301]: 5F1A02E0: to=<kim@example.net>, relay=mx.example.net[198.51.100.30]:25, delay=4, dsn=5.3.4, status=bounced (host mx.example.net[198.51.100.30] said: 552 5.3.4 Message size exceeds fixed limit (in reply to end of DATA command))

Gmail uses similar wording and points to its message-size help page. The limits change, so check Google's current attachment limits rather than relying on a remembered number.

Which limit is it

A line saying in reply to MAIL FROM command is an early refusal based on the advertised size. in reply to end of DATA command means the server read the whole message first, which happens with servers that do not use the SIZE extension.

Step 1: understand base64 inflation

Attachments are encoded as base64 inside the message, which grows them by roughly one third, plus line breaks and headers. A 20 MB file becomes around 27 MB on the wire. A limit of 25 MB for a message therefore means about 18 MB of actual files. This surprises people more than any other part of this error.

Check the real size of the failing message in your outbound queue or the saved .eml file:

ls -l message.eml

Step 2: find the limit that stopped you

The server advertises its limit during EHLO using the SIZE extension from RFC 1870:

openssl s_client -starttls smtp -connect mx.example.net:25 -crlf -quiet
EHLO test.example.org

You get lines such as:

250-SIZE 10240000
250-STARTTLS

The number is the maximum message size in bytes the server says it accepts. Not every server advertises it, and a value of 0 or a missing line means "no declared limit" or "unknown". Find the MX with the MX Lookup first; a message passes through your own outbound server, optionally a smart host, then the recipient's MX, and any of those may be the one that rejected it.

Step 3: if the limit is yours (Postfix)

Postfix has two settings that cause this:

postconf message_size_limit mailbox_size_limit virtual_mailbox_limit

message_size_limit defaults to 10240000 bytes (about 10 MB) and caps the whole message. mailbox_size_limit defaults to 51200000 and must not be smaller than message_size_limit; virtual_mailbox_limit applies to virtual mailboxes. To allow 50 MB messages:

sudo postconf -e 'message_size_limit = 52428800'
sudo postconf -e 'mailbox_size_limit = 0'     # 0 = unlimited, or set a larger value
sudo systemctl reload postfix

Raise the limit on both your inbound server and the submission path. Then check for other components that parse the message:

• Milters and content filters such as amavis, SpamAssassin (spamd --max-size), ClamAV (StreamMaxLength in clamd.conf) and OpenDKIM have their own size caps. A message accepted by Postfix can still be refused by these.
• Dovecot LMTP/LDA and quota plugins can reject oversized deliveries.
• The web or webmail layer has a separate upload limit; see the nginx example in nginx 413 request entity too large.

For Exim and Exchange, the equivalent options are message_size_limit in Exim and the organization, connector and mailbox size limits in Exchange. Check the current documentation for your version, because there are several levels and the smallest wins.

Step 4: if the limit is the recipient's

You cannot raise it. Options, best first:

1. Send a link to the file in cloud storage instead of attaching it.
2. Compress or resize the file; images and PDFs shrink a lot.
3. Split the send into multiple messages, keeping each under the limit.
4. Ask the recipient's admin to raise the limit for your sender, if it is a business arrangement.

Large attachments also hurt deliverability: filters and mobile clients treat them with suspicion. Test how a message performs with the Email Deliverability Test.

Step 5: check the chain for smart hosts

If your server relays through a provider, the provider's limit applies in addition to your own. A message that clears Postfix with a limit of 50 MB can be refused by the relay at 25 MB. The log shows relay= and the host that said 552. Use that hostname when you read the provider's documentation.

How to verify

Send a test file just under the new limit and one just over it, as you would test any size cap. The smaller one should return 250 2.0.0 OK, the larger one should fail with 552. Confirm in the log with:

sudo grep -E "dsn=5\.3\.4|552" /var/log/mail.log | tail

Monitoring helps here: add an Uptime Monitor TCP check on port 25 and 587, and use the Port Checker when a relay is involved.

Next steps

• Read SMTP 452 insufficient storage for the temporary version of storage problems.
• See mailbox full 552 5.2.2 if the account is over quota.
• Review email bounce codes explained.
• Check ecommerce order email deliverability if invoices are attached.

FAQ

Is 552 the same as 452?

No. 552 is permanent, 452 is temporary. Both can mean a storage or size problem, so read the enhanced code.

Why is my 20 MB attachment rejected at a 25 MB limit?

Base64 encoding adds about a third. The encoded message is larger than the file you attached.

Where do I see the receiving server's limit?

In the EHLO response, on the SIZE line, if the server advertises it. If not, check the provider's documentation.

Will retrying help?

Not unless something changed. The size is fixed, so the same message gets the same answer.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.