Fixing Message Too Large Migration Errors in IMAP

A migration that has been running cleanly for hours suddenly throws Message too large for destination on a handful of items, and your log fills with the same error per mailbox. The destination is rejecting individual messages because their encoded size exceeds the per-message cap. The fix is not raising limits — most destinations will not let you — it is identifying the oversized items, deciding how to handle them, and continuing the move without losing anything.

Why this error appears#

Email size limits are enforced per message, on the MIME-encoded payload, not on the raw attachment you see in a mail client. Three things conspire to produce the error mid-migration:

• Destination per-message caps. Microsoft 365 stops at 150MB. Gmail and Google Workspace stop at 50MB for IMAP appends. Self-hosted destinations often enforce 35–50MB by default.
• Base64 inflation. Any binary attachment is base64-encoded for transport, which adds roughly 33% to its size. A 38MB Outlook archive attachment becomes a ~51MB MIME message — over Gmail's limit by 1MB.
• IMAP literal limits. Some IMAP servers refuse APPEND commands whose literal size exceeds a fixed buffer, often 25–50MB, regardless of the mailbox quota policy.

The source server accepted the message originally because it was delivered before the policy changed, or because the source has a higher cap, or because the message was created locally (drafts, sent items with full original attachments) and never went through the SMTP boundary.

Step 1: confirm which limit you are hitting#

The error wording varies but the cause is one of three.

• Destination per-message cap. The destination IMAP server returns a NO on APPEND with text like Message too large or Message size exceeds the maximum size allowed. This is the most common cause.
• Quota exhaustion. Different error: OVERQUOTA or Mailbox is full. Not what this post is about — that one is solved by raising quota or archiving.
• IMAP literal limit. The destination drops the connection mid-APPEND or returns a BAD literal style response. Less common but worth checking if you see disconnections rather than clean NO responses.

If you are unsure which you are hitting, the log line matters. Message too large for destination is the per-message cap. A clean drop with no NO response is the literal limit.

Step 2: run a pre-flight scan#

Before changing anything, get the full list of oversized messages. The source IMAP server exposes message size via FETCH RFC822.SIZE, which is the encoded size in bytes. Compare against your destination cap.

Targets for the threshold:

• Microsoft 365 destination: flag anything over 150MB. In practice flag over 140MB to leave headroom.
• Gmail / Google Workspace destination: flag anything over 50MB. Flag over 47MB for headroom.
• Self-hosted IMAP destination: confirm with the admin or test with a known large message. Common defaults are 35MB or 50MB.

Mailbox Taxi runs this scan as part of pre-flight and produces a per-mailbox list before the migration starts. If you are diagnosing after the fact, the same data is in the failure log.

Step 3: decide a handling policy#

You have three real options per oversized message. Pick one before re-running, because mixing strategies mid-migration creates inconsistent mailboxes.

Skip and report#

The simplest: leave oversized messages on the source, log them, and hand the list to the mailbox owner. Works well when "oversized" means a handful of items per mailbox and the source will remain accessible for a few weeks.

Strip attachments, link to source#

Migrate the message body and headers; replace each attachment with a small text note that says where the original lives (a SharePoint link, a shared drive, or the still-accessible source mailbox). The message stays searchable in the destination and the bulk content stays where it already is. This is the right call for compliance scenarios where the message thread must move but the bulk content does not.

Leave on source until the source is decommissioned#

If you are running a phased cutover, leaving the oversized items on the source IMAP server until last is often cleanest. You finish the bulk migration, communicate the affected items to users, and either upload them manually post-cutover or let users save them locally.

Step 4: fix IMAP literal limits (if you control the destination)#

If the destination is a self-hosted IMAP server you control — Dovecot, Cyrus, or similar — and the failure is the literal-limit class rather than the mailbox-cap class, you can raise the limit.

For Dovecot, the relevant setting is mail_max_lock_timeout and the protocol-level imap_max_line_length, with the actual append size governed by mail_plugins and any quota plugin you have configured. The exact knob name depends on your Dovecot version, so check your installed config rather than copying values blindly.

For a hosted destination — Microsoft 365, Google Workspace, Fastmail, Zoho — you cannot change the limit. You must handle the oversized messages with one of the policies above.

Step 5: re-run the affected batch#

Once you have a policy and (if applicable) raised any destination literal limits, re-queue just the affected mailboxes. Mailbox Taxi resumes from the last successful UID per folder, so you are not re-uploading what already landed.

Watch the log on the second pass for two things: any remaining size errors (meaning your threshold was set too high) and any new errors that appear because the oversized items were creating downstream noise like stuck folders. The Exchange migration stuck fix is the right next stop if a stuck folder shows up.

Related context#

Per-message caps are the most common surprise on the Gmail-to-Microsoft-365 path, where the source cap is lower than the destination so you would not expect a problem — but messages composed in Outlook that never went through SMTP can exceed the source cap. The Gmail to Office 365 guide covers the specifics. For Exchange-to-365 moves, the same pattern shows up on PST-imported sent items; see the Exchange to Office 365 guide. The Office 365 migration guide goes through the broader picture, and the email migration troubleshooting hub catalogues the rest of the error classes you might hit next.