Troubleshooting “Message too large” (Inbound/Outbound)

The “Message too large” error occurs when an email exceeds the maximum file size limit enforced by either the sending or receiving mail server. In Google Workspace, the default maximum message size is 25 megabytes (MB) for outbound messages and 50 MB for inbound messages. However, users frequently encounter unexpected bounces on files well under 25 MB because binary attachments expand significantly during the transmission encoding process. Resolving this issue requires understanding MIME overhead, adjusting Admin Console routing caps, or switching to cloud-shared links.

Quick Fix: “Message Too Large” Bounces

Gmail has a hard message limit of 25 MB for outbound emails and 50 MB for inbound emails. Because binary attachments are encoded using Base64, file sizes increase by approximately 33% to 37% during transmission. Consequently, an attachment larger than 18 MB to 19 MB will often exceed the 25 MB ceiling. To send larger files, share them through Google Drive or increase recipient transport limits.

Understanding Size Limits: Inbound vs. Outbound

Google Workspace enforces different message boundaries depending on the direction of mail flow:

• Outbound Limits (Sending): The absolute maximum size of an outbound message sent via Gmail is 25 MB. This includes the message body, headers, and all combined attachments.
• Inbound Limits (Receiving): Google Workspace accounts can receive messages up to 50 MB in size directly from external mail systems.
• SMTP Relay Limits: If your application sends mail through smtp-relay.gmail.com or smtp.gmail.com, the 25 MB outbound cap applies universally.

When an email exceeds these thresholds, the connection fails. If the failure happens during an outbound attempt from an email client, the client displays an immediate local error. If it happens while communicating with an external server, the sending system receives an SMTP Non-Delivery Report containing status codes 552 5.3.4 (Message size exceeds fixed limit) or 552 5.2.3.

The Hidden Multiplier: Base64 Encoding Overhead

The most common reason users get confused by this error is sending an attachment that appears to be well under the 25 MB limit—for example, a 20 MB PDF or video—only to have it bounce immediately for exceeding the cap.

Email protocols were originally designed exclusively for plain ASCII text. To transmit binary files (such as PDFs, ZIP files, images, or audio) over standard SMTP connections, mail clients convert raw binary bytes into ASCII text using MIME Base64 encoding.

Original Binary File (e.g., 20 MB PDF)
                  │
                  ▼
   Base64 Encoding Process
   (Converts 3 binary bytes into 4 ASCII characters)
                  │
                  ▼
   Calculated Size Increase: 33.3%
   + MIME boundary headers & metadata
                  │
                  ▼
Final Transmitted Size = ~26.8 MB  ──►  Exceeds 25 MB Cap  ──►  BOUNCE 552

The Base64 conversion process takes every 3 bytes of binary data and represents them as 4 text characters. This process adds a mandatory 33.3% overhead to the file size. When you add file metadata, boundary definitions, and transport headers, the overall message size expands by 35% to 37%.

To determine the safe attachment limit, calculate:

Maximum Attachment Size = Message Limit / 1.37
25 MB / 1.37 = ~18.2 MB

Any raw file attachment larger than 18.5 MB risks triggering a “Message too large” error during outbound delivery. For an in-depth breakdown of this mechanism, review Why Your 25MB Attachment Failed (Encoding).

Diagnostic Steps: Isolating the Limiting Hop

When an email fails with a size restriction, trace the delivery path to locate which system dropped the message:

[Sender Mail Client] ──► [Workspace Sending Server] ──► [Destination Gateway] ──► [Recipient Mailbox]
       │                            │                             │                        │
       ▼                            ▼                             ▼                        ▼
Check Local Client           Check Workspace Logs         Check Remote SMTP Bounce   Check Recipient Quotas
Attachment Pre-checks        Exceeds 25 MB Cap?           Remote Server Cap          Mailbox Storage Full

Step 1: Examine the Bounce Status Code

Read the diagnostic text inside the bounce notification:

• 552 5.3.4 Error: message file too big: The receiving mail server rejected the transmission because its local administrator configured an inbound cap lower than 25 MB (many corporate gateways limit inbound messages to 10 MB or 15 MB).
• 552 5.2.2 Mailbox full / quota exceeded: The message itself may not exceed transit caps, but the recipient’s mailbox lacks the storage space to store it.
• Message size exceeds fixed maximum message size: Often generated by Microsoft Exchange or custom Postfix MTAs along the routing chain.

Step 2: Check Google Workspace Email Log Search

If you are an administrator, verify whether the message cleared Google’s outbound infrastructure:

1. Go to the Google Admin Console.
2. Navigate to Reporting > Email Log Search.
3. Search by Sender, Recipient, and date.
4. If the message appears with a status of Rejected at the Google hop, Google dropped it before outbound dispatch. If the message appears as Delivered to the recipient MTA, the size restriction was applied by the receiving domain.

Step 3: Check Compliance and Routing Rules

Google Workspace administrators can configure organizational rules that impose lower size restrictions than the default 25 MB.

• Navigate to Apps > Google Workspace > Gmail > Compliance.
• Review your active rules under Content compliance and Maximum message size.
• If an administrative rule blocks files over a custom size (such as 10 MB), the message will be dropped internally. For troubleshooting guidance, see Fix: “Content Compliance” Rule Blocking Mail.

Solutions and Workarounds

When messages exceed size limitations, apply the appropriate remediation based on your operational environment:

1. Leverage Google Drive File Insertion

The standard resolution for large files in Google Workspace is to bypass SMTP attachments entirely by sharing the file through Google Drive:

• In the Gmail composition window, click the Google Drive icon instead of the paperclip icon.
• Select the file and choose Drive link (do not select “Attachment”).
• Gmail inserts a secure cloud link. This avoids Base64 encoding completely and allows you to share files up to several terabytes depending on your account’s Drive storage limits.
• Ensure recipient permissions are configured correctly by following How to Fix Google Drive Link Permissions in Gmail.

2. Compress or Split Archives

If external security policies require file transmission through email rather than cloud links:

• Compress the file using ZIP, 7z, or RAR tools.
• Note: Avoid password-protected ZIP archives containing executable files or scripts, as these can trigger security blocks. See How to Bypass “Zipped File Blocked”.
• Split large archives into multi-part segments smaller than 15 MB each (e.g., archive.part1.rar, archive.part2.rar) and send them in separate messages.

3. Adjust Inbound Gateway Size Limits

If your organization routes inbound email through a third-party security filtering service (such as Proofpoint, Mimecast, or Barracuda) before delivering to Google Workspace:

• Confirm that the perimeter service’s maximum message size matches Google’s 50 MB inbound capacity.
• If the edge gateway is capped at 25 MB or 30 MB, large messages will bounce before reaching Google Workspace, regardless of Gmail’s capabilities. Review overall routing behavior in The Admin’s Guide to Gmail Routing Logic.