Postfix message size exceeds fixed limit: 552 5.3.4 and message_size_limit

The error 552 5.3.4 Message size exceeds fixed limit appears in Postfix logs when a message, including headers, body, and MIME encoding overhead, exceeds message_size_limit. This is a hard rejection, not a deferral. The sender receives a bounce, and the message never enters the queue.

The default message_size_limit is 10240000 bytes (approximately 10 MB). Base64 encoding inflates binary attachments by roughly 33 percent, so a 7 MB attachment becomes approximately 9.3 MB of encoded data before headers are added. Many operators discover this only when users report that “sometimes attachments work, sometimes they don’t.”

The rejection can occur at several points: at MAIL FROM time if the sender specifies a SIZE parameter exceeding the limit, at DATA completion if the actual message exceeds the limit, or at the destination’s own size cap. The fix is not always to raise the limit. Determine whether the message is legitimately oversized, whether the limit is set too low for the workload, or whether a downstream component (content filter, destination MX) has its own lower cap.

What this means

Postfix enforces message_size_limit as a hard ceiling on the total size of any message it accepts, including envelope information, headers, and body. The limit applies at the smtpd (inbound SMTP) and cleanup (message normalization) stages.

Postfix advertises the SIZE capability in its EHLO response, set to the value of message_size_limit. Well-behaved senders check this advertisement before attempting to transmit and never send a message that exceeds it. Some senders pipeline SMTP commands aggressively and may not process the SIZE advertisement before sending MAIL FROM with a SIZE parameter, resulting in the 552 rejection.

flowchart TD
    A["Message rejected: 552 5.3.4"] --> B{"In your Postfix logs?"}
    B -->|Yes| C{"SIZE in MAIL FROM?"}
    B -->|No| D["Destination MX cap"]
    C -->|Yes| E["Limit too low"]
    C -->|No| F{"Content filter in path?"}
    F -->|Yes| G["Check filter limit"]
    F -->|No| E
    D --> H["Not your server"]
    E --> I["Raise limit, check effects"]
    G --> I

Common causes

Quick checks

# Check current message_size_limit (default: 10240000)
postconf -h message_size_limit

# Check mailbox_size_limit (must be >= message_size_limit, default: 51200000)
postconf -h mailbox_size_limit

# Check queue_minfree (default: 0, meaning 1.5x message_size_limit is the floor)
postconf -h queue_minfree

# Verify the EHLO SIZE advertisement your server sends
{ echo "EHLO test.local"; sleep 1; echo "QUIT"; } | nc -w 5 localhost 25 | grep -i SIZE

# Check free space on the queue partition
df -h /var/spool/postfix

# Search logs for 552 5.3.4 rejections
grep '552 5.3.4' /var/log/mail.log | tail -20

# Search for size-related rejections with context
grep -i 'exceeds.*limit\|message too large\|size limit' /var/log/mail.log | tail -20

# Check if Postfix started cleanly (catches mailbox_size_limit mismatch)
postfix check 2>&1

If your distribution uses /var/log/maillog instead of /var/log/mail.log, adjust the path accordingly.

How to diagnose it

1. Confirm the rejection is from your Postfix, not the destination. Search your mail log for the 552 5.3.4 string. If it appears during an inbound SMTP transaction (client connecting to your server), the rejection is yours. If it appears in an outbound delivery log as the remote server’s response, the destination MX has its own size cap and you cannot fix it by changing your configuration.

2. Determine the actual message size. The 552 rejection often includes the message size or the configured limit. Compare against postconf -h message_size_limit. The limit covers the entire message including envelope, headers, and MIME structure, not just the attachment payload.

3. Account for base64 overhead. Binary attachments encoded in base64 grow by approximately 33 percent (every 3 bytes becomes 4 bytes on the wire). A 7 MB binary file produces roughly 9.3 MB of encoded data before headers are added. If your message_size_limit is 10240000 (10 MB), the practical attachment ceiling is about 7 MB.

4. Check for a content_filter size mismatch. If you run Amavis, Rspamd, or another content filter, the filter may have its own size limit lower than Postfix’s message_size_limit. The message passes Postfix’s size check but gets rejected by the filter. Look in the filter’s logs, not just mail.log.

Parameter names and defaults vary by filter version and deployment, so read the filter’s own documentation.

5. Verify Postfix started cleanly. If you recently raised message_size_limit without also adjusting mailbox_size_limit, Postfix may have failed to start. The error is: fatal: configuration error: mailbox_size_limit is smaller than message_size_limit. Run postfix check to confirm.

6. Check disk space on the queue partition. Postfix rejects all inbound mail (not just oversized messages) when free space drops below 1.5 times message_size_limit. This produces a different error code (typically 452 4.3.1) but operators sometimes conflate the two when investigating “mail rejection” incidents.

Metrics and signals to monitor

Fixes

Raise message_size_limit

The direct fix when the limit is genuinely too low for your workload.

# Set message_size_limit to 26214400 (25 MB)
postconf -e 'message_size_limit = 26214400'

# Ensure mailbox_size_limit is >= message_size_limit
# Default is 51200000 (50 MB), but verify
postconf -h mailbox_size_limit

# Reload Postfix to apply (non-disruptive, does not restart)
postfix reload

Tradeoffs to understand before raising the limit:

• Memory and queue implications. Each message that enters the queue occupies disk space and, during processing, memory in cleanup and delivery agents. Raising the limit allows larger messages to flow through, which increases peak resource consumption.
• Disk space floor rises. The 1.5x free-space check scales with message_size_limit. If you raise the limit from 10 MB to 50 MB, Postfix requires at least 75 MB free on the queue partition before accepting any mail. On small partitions, this can cause an unexpected outage.
• MIME nesting limit. Deeper MIME structures in large messages can hit mime_nesting_limit independently of the byte limit. Check whether the current default (100) is sufficient for your workload.

Postfix documentation does not recommend scaling mime_nesting_limit with message_size_limit; they are independent limits (a recursion-depth cap versus a byte cap).

Set message_size_limit to 0 (unlimited)

Setting message_size_limit = 0 removes the limit entirely. This is valid but risky. A single oversized message or a flood of large messages can fill the queue partition, exhaust inodes, and cause a broader outage. Use this only if you have robust disk space monitoring and understand the downstream impact on delivery agents and content filters.

Adjust mailbox_size_limit

If you are raising message_size_limit above the default mailbox_size_limit of 51200000 (50 MB), you must also raise mailbox_size_limit:

# Set both consistently
postconf -e 'message_size_limit = 104857600'
postconf -e 'mailbox_size_limit = 104857600'

# Reload
postfix reload

If mailbox_size_limit is set lower than message_size_limit, Postfix logs fatal: configuration error: mailbox_size_limit is smaller than message_size_limit and refuses to start.

Fix content_filter size limits

If the rejection comes from your content filter, not Postfix itself, raising Postfix’s message_size_limit will not help. The filter has its own size cap that must be adjusted independently.

The parameter names vary by filter, version, and deployment; check the filter’s own documentation for its size limit.

Check the filter’s configuration and raise its limit to match or exceed your Postfix message_size_limit. After changing the filter, test by sending a message near the new limit and verifying it passes both Postfix and the filter.

Address destination-side size limits

If the 552 5.3.4 comes from the destination MX, not your Postfix, you cannot fix it by changing your configuration. The destination has its own message size cap. Options include advising the sender to use a file-sharing service for large attachments, or configuring a transport map to route large messages to a destination that accepts them.

Prevention

• Calculate the effective attachment ceiling. Take your message_size_limit and divide by approximately 1.37 to get the maximum binary attachment size that will fit after base64 encoding and headers. If users need to send 20 MB attachments, set message_size_limit to at least 30 MB (31457280).
• Always adjust mailbox_size_limit in tandem. Verify postconf -h mailbox_size_limit is greater than or equal to message_size_limit after any change. A postfix check after postfix reload catches the fatal mismatch.
• Monitor free space against the 1.5x floor. When you raise message_size_limit, the disk space threshold for accepting any mail rises proportionally. Alert on free space dropping below 2x message_size_limit to leave headroom.
• Document the content_filter size limit. If you run Amavis, Rspamd, or another filter, record its size limit alongside your Postfix message_size_limit. They must be consistent, or the filter will silently reject messages that Postfix accepted.
• Patch regularly. A BDAT command handler bug (introduced in Postfix 3.4) allowed the SMTP server to read message_size_limit bytes into memory when handling malformed BDAT commands. Ensure you are running a patched version; the fix is in Postfix 3.5.25 and later (the defect was introduced in 3.4, when BDAT was added).

How Netdata helps

• Per-second queue metrics show the immediate impact of a size-limit change on active, deferred, and incoming queue depth. If raising message_size_limit causes queue processing to slow under larger messages, the effect is visible within seconds.
• Disk space and inode monitoring on the queue partition catches the 1.5x free-space floor before it triggers total mail rejection. Correlating disk usage with mail flow velocity tells you whether a disk-space event is caused by queue growth or an unrelated process.
• Bounce rate tracking surfaces the reputation impact of size-limit rejections. A spike in 552 bounces after a configuration change is visible alongside delivery rate and injection rate.
• Correlation across signals (queue depth, disk usage, bounce rate, delivery latency) in a single view shortens diagnosis when a size-limit change has unintended side effects on the broader mail pipeline.

Related guides

• Postfix active queue saturation: hitting qmgr_message_active_limit
• Postfix backscatter storm: bounces to forged senders and blocklisting
• Postfix IP blocklisted: deliverability collapse and sender reputation
• Postfix bounce rate spike: 5xx failures, bad address lists, and reputation risk
• Postfix check warnings: configuration drift and permission problems
• Postfix connection refused: blocked port 25 and rejected outbound delivery
• Postfix connection timed out: delivery deferrals to unreachable destinations
• Postfix content_filter backpressure: incoming queue growth when Amavis or Rspamd slows
• Postfix deferred queue growing: why mail piles up and how to drain it
• Postfix destination concurrency limit: tuning per-destination delivery
• Postfix DNS resolver failure: when a broken resolver defers mail to everyone
• Postfix flushing and clearing the deferred queue: postqueue and postsuper