How to Increase the Maximum Attachment Size in Zimbra Webmail

The Short Answer

For Zimbra Webmail, raising only one setting may not be enough. If users need to attach larger files to outgoing messages, coordinate the web upload limit, the mailbox SOAP content limit, and the MTA’s total message-size limit. Also check for a server-specific override or an external proxy that imposes a smaller request limit.

As a worked example, suppose your organization wants users to attach files up to 25 MiB. Zimbra’s size guidance recommends allowing about 150% of the original file size for the complete MIME-encoded message. A 40 MiB ceiling (41,943,040 bytes) is a reasonable starting example for that policy, subject to testing and your storage capacity. MIME overhead varies by message, so no multiplier guarantees that every message will fit.

Run these commands as the zimbra user, after reviewing the current values and confirming that the example policy fits your environment:

su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize zimbraMtaMaxMessageSize

zmprov mcf zimbraFileUploadMaxSize 41943040
zmprov mcf zimbraMailContentMaxSize 41943040
zmprov mcf zimbraMtaMaxMessageSize 41943040
postfix reload

These commands set global values. If a mailbox server has its own lower override, check and adjust that server too. The exact attributes and restart behavior can vary by Zimbra release and deployment; verify them against your installed version before applying changes broadly.

Why There Is More Than One Limit

zimbraFileUploadMaxSize controls file uploads handled by Zimbra, including the request body accepted by the built-in web proxy. Zimbra’s proxy reference maps both HTTP and HTTPS maximum body size to this attribute; a request that exceeds the proxy limit can receive HTTP 413. In a multi-mailbox deployment, the attribute can be set globally or per server.

zimbraMailContentMaxSize controls the size of message content sent through the mailbox SOAP interface. zimbraMtaMaxMessageSize controls the maximum complete message accepted by the MTA, which is Postfix in a standard Zimbra deployment. That total includes message headers and MIME-encoded content, not just the original file on disk.

Zimbra’s Tech Center article on size configuration is explicitly marked as a work in progress. Its explanation and commands are useful, but check the attribute definitions and behavior for your installed Zimbra version. The references are Zimbra’s maximum-message-size guidance and the Zimbra Proxy variable reference.

Use the settings that match the failure: a file rejected immediately while attaching points first to an upload or web-proxy cap. A message rejected during send or delivery may be hitting the MTA or a recipient’s server. An upload that works but later fails to send means the MTA cap or MIME expansion still needs attention.

Choose a Limit That Fits Your Policy

Set a defined business limit instead of raising every cap as high as possible. For example, if users should attach files up to 25 MiB, the 40 MiB example leaves room for encoding and message overhead. Zimbra notes that the encoded size increase is not a fixed percentage and suggests using 150% as a planning assumption when estimating message limits.

Larger messages use more queue storage, bandwidth, and mailbox capacity. Zimbra warns that an excessively high Postfix size limit can cause mail delivery problems when the queue partition does not have enough free space. Very high Zimbra size attributes can also cause service problems in some versions; Zimbra has documented Web App and Admin Console failures after out-of-range values. Increase limits in measured steps and test the result rather than setting a multi-gigabyte ceiling without a capacity plan.

Check for a Per-Server Override

Global configuration is convenient when all mailbox servers should share one policy. A server-level value can override the global setting, however. Check the global values and then the mailbox host that handles the affected user:

su - zimbra
zmprov gcf zimbraFileUploadMaxSize zimbraMailContentMaxSize
zmprov gs mailbox1.example.com zimbraFileUploadMaxSize zimbraMailContentMaxSize

Replace mailbox1.example.com with the actual mailbox server name. If it has a lower server-specific value and your policy permits the larger size, update that host:

zmprov ms mailbox1.example.com zimbraFileUploadMaxSize 41943040
zmprov ms mailbox1.example.com zimbraMailContentMaxSize 41943040

Repeat only for the mailbox hosts that require the change. Do not assume that modifying the global configuration removes existing server overrides. In a multi-server environment, check every applicable mailbox node and every MTA.

Confirm the MTA Limit Took Effect

After changing the global MTA attribute and reloading Postfix, inspect the effective Postfix value on each Zimbra MTA:

su - zimbra
zmprov gcf zimbraMtaMaxMessageSize
postconf message_size_limit

The two results should agree in bytes. If the LDAP attribute is correct but postconf still shows the old limit, review the Zimbra MTA configuration process and logs before trying a full restart. A restart can interrupt mail services, so schedule one only when required by the installed release and deployment topology.

Zimbra’s proxy builds its HTTP request-body limit from zimbraFileUploadMaxSize. If your environment also places a separate Nginx, Apache, cloud gateway, or security appliance in front of Zimbra, that component may have its own upload cap. A 413 response or a proxy log entry is a clue to check the request-body limit on the layer that returned the error. Avoid editing Zimbra-generated proxy files directly; make changes through supported Zimbra settings and use the configuration regeneration or restart procedure documented for your version.

Test With a Controlled Message

1. Use a test mailbox and a file just below your intended attachment limit. Do not begin with the largest file the system could possibly accept.
2. Attach the file in Zimbra Webmail. If the browser reports that the upload is too large, inspect zimbraFileUploadMaxSize, mailbox-server overrides, and proxy limits.
3. Send the message to another internal test mailbox. If the upload succeeds but sending fails, check the mailbox SOAP cap and MTA limit.
4. Review the bounce text and logs. Zimbra’s MTA guidance shows Postfix rejecting an oversized message with a 552 size error and recommends checking /var/log/zimbra.log for reject, exceed, limit, or warning events.
5. If internal delivery works but an external recipient rejects the message, check the recipient’s advertised or documented size limit. Your Zimbra settings cannot raise a limit on another mail system.

For outbound SMTP, Postfix can advertise its accepted size in the SMTP SIZE capability. A remote mail server may advertise a smaller value or reject the message after Zimbra sends it. Zimbra’s troubleshooting article explains how to distinguish a local MTA rejection from a recipient-side rejection. See Postfix’s message-size parameter reference and Zimbra’s MTA size troubleshooting examples.

When to Use a File-Sharing Link Instead

Email attachment limits are not a reliable way to distribute very large media files, disk images, or project archives. Each recipient’s mail system may enforce a different total-message limit, and encoded messages are larger than their original attachments. If a larger limit would strain storage or queue capacity, share the file through an approved file-sharing service and email a permission-controlled link.

The change is successful when a test file within the new policy uploads, sends, and arrives for an internal recipient, while Postfix reports the intended message-size value. If only certain users or server nodes still fail, compare their mailbox-server overrides and proxy route. If only external recipients reject mail, confirm their limit before increasing Zimbra’s caps again.