Why am I getting a max message size exceeded error on some emails but not others?
Updated on 23 Oct 2026: We added checks for Sent-folder size errors and clarified how to diagnose partial delivery failures.
A max message size exceeded error can hit some recipients and not others because sending and receiving systems apply different size limits. They can evaluate size at the mailbox, domain, server, routing, or filtering layer. That means the same send can partly deliver and partly bounce, even when every recipient is on the same apparent provider family.
The rejected recipients crossed a size rule that accepted recipients did not cross, had a lower mailbox-specific message length limit, went through a different receiving path, or received a larger personalized copy. A client warning can instead concern saving a Sent copy after sending succeeded. A hard bounce label in the ESP does not prove that every address is permanently bad.
Treat this as a diagnostic problem first, not a suppression decision. Start by checking where the error appeared, the final MIME size, the exact SMTP and enhanced status codes, the provider pattern, and whether the failure clustered by send time. A one-off send can be inspected with an email tester before you rebuild the message or remove subscribers. That test does not establish the affected recipient's size limit.
What a max message size exceeded error means
A maximum message size exceeded bounce means a sending or receiving mail system rejected the message under one of its limits. The important word is "message", not "attachment". Total message size includes headers, HTML, plain text, inline images, attachments, tracking wrappers, base64 expansion, MIME boundaries, and any rewrites made before the size check. Binary attachments grow by about 33% with base64 encoding, plus line-wrapping overhead. With MIME line breaks, a 20 MB file becomes roughly 27.4 MB before the message body and headers are added. Leave headroom below the smallest applicable limit. RFC 2045 defines MIME base64 encoding.
Common SMTP wording includes 552, 554, 5.2.3, 5.3.4, or a generic 5.0.0 status. A 5.2.3 enhanced status means a per-mailbox administrative message length limit was exceeded. A 5.3.4 status means the message was too large for the receiving system. By contrast, 5.2.2 means the mailbox is full. These meanings are defined in the IANA status code registry. Some platforms map a 5.x.x response to a hard bounce because the receiving server returned a permanent failure, but that classification does not tell you whether a smaller future message can reach the same address.
Example bounce texttext
552 5.2.3 DATA size exceeds maximum permitted 552 5.3.4 message too big for system 554 maximum message size exceeded 5.0.0 undefined status maximum message size exceeded Message size exceeds fixed maximum message size
The exact code matters. A SMTP 552 error often points to storage, size, or policy limits, while a 554 response can be a broader permanent rejection. Generic status text gives you less certainty, so the pattern across recipients matters more than one line of bounce text.
If the error appears while you are composing, uploading, or submitting the message, treat it as a client-side or sender-side limit first. Outlook, OWA, and Exchange policies can enforce different maximum message or attachment sizes before the destination server evaluates the message. That is a different problem than a post-send bounce returned by the recipient's domain.
For Microsoft 365, 150 MB is a configurable ceiling, not a universal allowance. Microsoft lists Exchange Online defaults of 35 MB for sending and 36 MB for receiving. Client limits and encoding overhead reduce the usable size in some paths. Check the affected mailbox's settings against Microsoft's message limits rather than assuming the largest published number applies.
The key point
Do not assume a hard bounce means the address is invalid. With size-related wording, the address can be real and reachable, while that message version, route, or recipient limit caused the rejection.
Why only some recipients bounce
Partial delivery usually means the limit was applied at a more specific layer than the campaign level. That layer can be the recipient mailbox, a transport rule, the receiving cluster, or the message after personalization. Some receiving servers advertise a SIZE limit in their SMTP EHLO response and reject oversized mail before the full message body is transferred. The SMTP SIZE extension expresses size in bytes, including headers and line endings. A message below that advertised limit can still exceed a recipient-specific limit.
- Recipient-specific size limit: One mailbox can have a lower administrative message length limit than the provider's general system limit.
- Different MX paths: A provider can route recipients through different inbound systems with different policy enforcement or error wording.
- Message variation: Personalization, dynamic sections, regional footers, or conditional modules can make one recipient copy larger than another.
- Transport rule: A mailbox, group, connector, or organization can have a lower limit than the server's advertised maximum.
- Provider incident: Suspect a receiving-side defect only after comparing message sizes and checking service status or provider support evidence.
Email size checks showing why the same campaign delivers to some recipients and bounces for others.
|
|
|
|---|---|---|
Recipient limit | Some mailboxes have a lower cap | 5.2.3 wording |
MIME growth | Copies differ by recipient | Final sent source |
Provider route | Clusters enforce differently | MX pattern |
Transport rule | Groups or connectors use a lower cap | Policy scope |
Provider incident | One domain spikes suddenly | Send-time cluster and provider confirmation |
Common causes of partial maximum-size bounces.
If the error only appears at one mailbox provider and in one time window, do not immediately treat the list as bad. Compare the same campaign across other providers, then compare the failed provider before and after the spike. A provider-specific size limit can produce the same pattern as an incident, so confirm the cause before changing suppression rules.
How to separate message size, mailbox quota, and policy
The fastest way to make progress is to split the evidence into actual message size, recipient mailbox rules, storage quota, and provider policy. Similar bounce descriptions can point to different conditions, so use the enhanced status code and confirming signs instead of trusting the short label alone.
True size rejection
- Pattern: Failures repeat for messages above the same size at the affected recipient or provider.
- Evidence: Final MIME size is close to or above a provider, server, or recipient limit.
- Fix: Reduce attachments, embedded assets, HTML, tracking markup, and unused modules.
- Retest: Send the lighter copy to seed accounts and affected providers.
Quota, policy, or incident
- Pattern: Failures cluster around specific recipients, one route, or a short incident window.
- Evidence: A 5.2.2 code points to quota; an incident needs confirming logs or provider evidence.
- Fix: Use a smaller message for a recipient limit, or pause retries during a confirmed incident.
- Retest: Compare a minimal message against the original copy for the same address or domain.
No attachment does not mean the message is small. Embedded images, long HTML, base64-encoded assets, personalization blocks, and security wrappers can raise the final wire size. Compare the MIME size at the point of rejection; a received copy can include extra headers or other changes added after the sender transmitted it.
For Outlook group emails, inspect header limits as well as body size. Long To or Cc fields increase header size. Exchange Online has separate header limits and returns a header-specific 552 5.3.4 error. Recipient-count limits are separate from message-size limits. Microsoft documents these limits.
Do not confuse this with Gmail clipping. Gmail's "View entire message" link concerns message display, not a maximum message-size SMTP bounce. For this error, measure the final MIME message, not only the HTML source.
If you need the technical detail behind how MIME and encoding change size, review file size and MIME before you compare the editor preview with the transmitted message.
When a Sent-folder error appears after sending
An IMAP upload limit can cause a size warning even after SMTP sending succeeds. A mail client can use SMTP to send the message, then IMAP APPEND to save a copy in Sent. If only that second operation fails, the warning concerns saving the copy. Check submission logs or confirm receipt before resending to avoid duplicates; SMTP acceptance alone does not prove final delivery.
The IMAP APPENDLIMIT extension advertises the maximum message upload size in bytes. APPENDLIMIT=10240 means 10,240 bytes, or 10 KiB. It is an IMAP upload limit, not the receiving domain's SMTP limit. An oversized APPEND can return TOOBIG.
- Check the failed operation: Identify SMTP submission, an IMAP Sent or Drafts upload, or a later recipient bounce in the client logs.
- Compare webmail: If webmail works but desktop and mobile clients show the same small limit, ask the provider to investigate the protocol-specific path.
- Escalate with evidence: Give the provider the advertised APPENDLIMIT value, failed folder, message size, and timestamp. Reinstalling the client does not change a server-advertised limit.
Why replies and forwards can exceed the limit
A short reply can exceed a limit because the reply carries more than the new sentence. Quoted conversation history, inline logos, signatures, tracking data, and nested MIME parts can remain in the message. Forwards commonly retain original attachments; ordinary replies in Outlook do not automatically include them. Long reply chains can therefore fail even when a new message to the same recipient succeeds. Microsoft's reply and forward guidance explains attachment handling.
- Start a fresh message: Send the same short text without quoted history. Delivery points to inherited thread content as the cause.
- Remove inherited content: Delete retained attachments, inline logos, signatures, and unnecessary quoted messages before resending.
- Check the Outbox: A previously rejected large message can remain queued and trigger the same warning during later send attempts.
- Rebuild the draft: If only one draft fails, create a clean draft instead of repeatedly submitting the same stored MIME structure.
- Compare access methods: If the same small message fails in the web client and desktop client, check account-level limits before repairing one local client.
A client error that appears before SMTP handoff needs a different test from a destination bounce. Record whether the warning appears in the compose window, Outbox, sender non-delivery report (NDR), or recipient-domain bounce log. That location identifies which system enforced the limit.
A practical troubleshooting sequence
When this error appears on only part of a send, work in order. The goal is to avoid suppressing valid recipients too aggressively or continuing to send an oversized message pattern.
- Export evidence: Pull the raw bounce reason, SMTP and enhanced status codes, provider domain, send time, campaign ID, recipient count, and rejection stage.
- Group by provider and route: Separate failures by domain family, MX host, and send window instead of reading the whole send as one event.
- Measure MIME size: Obtain the sender's final raw .eml file or sending-system size log after personalization and encoding. Compare the exact variants sent to accepted and rejected recipients; the template preview is insufficient.
- Compare acceptance: Check whether the same message delivered to other mailbox providers, business domains, and seed accounts.
- Send a lighter test: Remove attachments, embedded images, quoted history, unused modules, and long legal copy, then test the affected provider or recipient.
- Review sender changes separately: Check authentication, DNS, and sending-source changes without treating them as proof of a size problem.
- Choose handling logic: Route repeat 5.2.3 recipients to lighter mail and temporarily hold provider-wide spikes for investigation. Do not automatically retry an unchanged message after a 5xx size rejection.
For Microsoft 365 migrations, "ErrorMessageSizeExceeded" or "Failed to write Mail" concerns writing an item to the destination mailbox, not necessarily SMTP delivery. Ask an administrator to inspect MaxSendSize and MaxReceiveSize for the affected mailbox. Review the migration method's limits before raising a setting. Microsoft's mailbox size guidance explains these properties.
Inspect one mailbox in an authenticated Exchange PowerShell sessionpowershell
Get-Mailbox -Identity "user@example.com" | Format-List MaxSendSize,MaxReceiveSize
A broad check helps when the bounce reason feels misleading. Use a domain health review to identify authentication and DNS issues that need separate action beside the size investigation.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
What to change in the email
If the evidence points back to the message itself, reduce the final transmitted size rather than only changing the visible design. The editor can look light while the MIME source is heavy.
- Remove attachments: Link to hosted files instead of attaching PDFs, calendar files, documents, or other bulk attachments.
- Avoid embedded images: Resize and compress images attached or encoded in the message. Remotely hosted images do not add their file weight to the SMTP message.
- Shorten HTML: Remove unused modules, repeated inline styles, excessive comments, and abandoned conditional markup.
- Limit personalization: Check whether recipient-specific blocks make some copies much larger than the default preview.
- Reduce wrappers: Audit tracking, URL rewriting, link decoration, and redirect parameters when the final source grows unexpectedly.
- Check client limits: If the error appears before sending, reduce inherited content or attachments and check the account's send limit.
Size-safe campaign checklisttext
Check final MIME source size Compare personalized variants Host files instead of attaching them Use linked images, not embedded image data Check whether SMTP submission, IMAP saving, or recipient delivery failed Retest affected provider with a lighter copy
Do not over-trust the editor preview
The message that leaves the ESP can be larger than the message you see in the campaign builder. Encoding, tracking, personalization, quoted content, and MIME packaging add bytes after design approval.
What authentication can and cannot tell you
DMARC and related authentication checks are not message-size controls. A valid DKIM signature does not guarantee acceptance, and a DMARC pass does not override a receiver's size or mailbox policy. An authentication failure also does not produce the standard 5.2.3 or 5.3.4 size condition, so investigate it as a separate cause.
If a provider starts rejecting only a portion of mail with size wording, check DMARC monitoring, SPF and DKIM results, and sending-source changes for concurrent problems. A broken SPF record does not explain a standards-based size response. Aggregate DMARC reports are not a complete record of delivery attempts, so missing report data does not prove a size rejection.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
Suped's DMARC reporting and email authentication platform helps check reported SPF and DKIM results and sending-source changes while the team examines raw bounce evidence and MIME size in the sending system. These reports identify concurrent authentication issues; they do not measure message size or establish why a recipient rejected a message.
How to classify the bounce
The classification decision should be based on the enhanced status code and pattern, not only on the ESP's hard bounce label. A normal invalid-mailbox response is different from a provider-wide spike where some recipients accepted mail and others rejected it with the same size wording.
Bounce pattern interpretation
Use these patterns to choose checks; the spread of failures alone does not establish the cause.
Single recipient
Low spread
Use a lighter message after confirming the size code repeats.
One provider spike
Medium spread
Hold affected sends, compare limits, and check provider evidence before permanent suppression.
Many providers
High spread
Fix message size or sending configuration before another campaign.
After lighter test
Investigate size
If the light copy delivers, compare both versions to confirm which size limit was crossed.
For suppression, separate invalid-mailbox responses from size and provider events. If one provider rejects a large batch at the same time with the same wording, record the event, test smaller mail, and avoid removing those addresses immediately. If the same recipient repeatedly returns 5.2.3 for large messages but accepts a minimal test, route that recipient to lighter mail. Follow the sending platform's suppression rules and restore a size-suppressed address only after correcting the cause; keep unsubscribe and complaint suppressions in place.
Blocklist (blacklist) status does not cause a standards-based size error. Treat a blacklist listing as separate evidence and do not use a blocklist listing to explain a 5.2.3 or 5.3.4 response.
