Email Migration: 7 Failure Modes That Lose Mail

Email migration looks like a copy job until mail starts landing in two places, users reply to old threads and get bounces, and somebody discovers the CEO mailbox is 85GB larger than the plan you bought. If you want the tooling angle, start with this imapsync operator guide. This article is the runbook for the mess around it: DNS, folder mapping, throttling, mailbox quotas, and the ugly edge cases that turn a routine email migration into a weekend outage.

The problem is simple: people treat email like files. The agitating part is worse: mailboxes keep changing while you move them, DNS caches lie to you, and IMAP servers do not agree on folder behavior. The fix is not heroics. It is staging, verification, and refusing to cut corners that look harmless at 6 PM and catastrophic at 9 AM Monday.

Why email migration fails in production

Email migration fails when operators treat it as one event instead of a controlled sequence: inventory, pre-stage, cutover, delta sync, and validation. Mail is live data. DNS is cached. Client behavior is inconsistent. If you skip any one of those layers, you do not get a clean move. You get partial delivery, duplicates, or silent data loss.

1. DNS split-brain is the first email migration outage

The first email migration failure is usually not the copy itself. It is routing. Some senders use your new MX within minutes. Others keep the old MX cached for hours. During that window, mail can land on both systems. If the old host is already shut down, you get bounces. If it is still live, mail gets stranded.

Microsoft says to shorten MX TTL before IMAP cutover so updated records propagate faster. That advice is boring. It also saves migrations. If your current TTL is 86,400 seconds and you change MX on the night of the move, you have already lost control of the timeline.

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

If you are moving to TrekMail, get the exact records from Adding a Domain to TrekMail and verify that the domain turns active before you announce the move. TrekMail also checks DNS live, which helps catch the classic mistake of leaving old MX records behind.

Bad cutover: switch MX at 10 PM, decommission old host at 10:05 PM, discover Monday that one vendor's gateway cached the old record all weekend.

One more trap: SPF. If inbound points to the new system but outbound authentication is still wrong, replies start hitting spam. Google's sender rules are not optional anymore. Use one SPF record, align DKIM, and publish DMARC.

2. Throttling breaks the fantasy of the one-weekend email migration

The second email migration failure is physics. Your bottleneck is usually not local bandwidth. It is the source provider deciding you have copied enough for now. Google, Microsoft, and other hosted systems throttle aggressive IMAP traffic. When that happens, progress estimates turn into fiction and the job slows to a crawl or stops entirely.

This is why big-bang email migration is a bad plan for anything beyond a tiny team. A 10GB mailbox copied into an environment that effectively allows only a fraction of that per day will not finish because you want it to. Rate limits do not care about your maintenance window.

The fix is staged migration:

1. Pre-stage older mail first, usually everything older than 60 to 90 days.
2. Let the tool retry and back off during the week.
3. Switch MX only after the historical bulk is already at the destination.
4. Run a delta pass for recent mail during cutover.

TrekMail's server-side IMAP import is designed for this workflow. The live doc at Starting a Migration in the Dashboard confirms the migration tool pulls mail from an external IMAP server into a chosen TrekMail mailbox and supports a Skip Duplicates option. That matters because repeat passes are normal in a safe email migration, not a sign that something went wrong.

Old Way vs New Way: old providers make you pay per seat, then make you buy separate migration tooling on top. New Way: you stage the move with built-in IMAP migration, pay from a flat plan that starts at $3.50 per month, and stop turning every mailbox into a licensing event.

3. UIDVALIDITY can turn one email migration into three copies of the same mailbox

This email migration failure hides behind a successful-looking progress bar. IMAP messages have unique identifiers, but those identifiers are only reliable inside the rules of the mailbox they belong to. When the server changes folder state enough to reset UIDVALIDITY, a naive migration tool can mistake old messages for new ones and copy them again.

IMAP4rev1 (RFC 3501) defines UIDVALIDITY for a reason. If it changes, the old message UIDs are no longer trustworthy. That is normal protocol behavior. It is terrible migration behavior if your tool relies on UIDs alone.

Typical triggers:

• A user renames or recreates a folder during the move.
• The source server rebuilds indexes.
• An admin runs maintenance that changes mailbox state.

The practical defense is simple. Freeze mailbox housekeeping during the migration window. Tell users not to rename folders, drag thousands of messages into Archive, or clean up Sent Items while the sync is running. Then use a destination that can skip duplicates on repeat passes instead of blindly trusting folder UIDs.

If you are doing manual validation, compare folder counts before and after. Do not stop at the Inbox. Check Sent, Trash, custom project folders, and any shared archival structure. That is where duplicate storms hide.

4. Folder mapping is where email migration gets weird fast

Folder mapping breaks email migration because IMAP servers do not agree on hierarchy delimiters, system folder names, or Gmail's label model. Users experience this as missing folders or duplicate messages. Technically, the mail is often present. It is just translated badly, which is enough to cause panic and support tickets.

There are two common versions of this problem. First, delimiter mismatch: one server uses dots in folder names, another uses slashes. Second, Gmail labels: one message can appear under multiple labels, and IMAP presents those labels like folders.

That is how a source mailbox with clean Gmail labeling turns into a bloated destination with repeated mail in Sent, custom folders, and archive containers. Microsoft's own troubleshooting documentation explicitly calls out duplicate mail when Gmail labels are involved and the [Gmail] folder is not excluded.

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

If you migrate from Gmail, skip [Gmail]/All Mail unless you have a very specific exception. If you do not, you are asking for duplication. If you need client setup after the move, TrekMail keeps the post-cutover side straightforward with standard IMAP settings in IMAP & SMTP Settings for All Clients.

5. The whale mailbox kills email migration budgets and timelines

Email migration plans usually fail on averages. Real environments fail on outliers. One mailbox that has been collecting mail since 2011 can be larger than ten normal users combined. If you quote the job, pick the destination plan, and set the timeline without sizing every mailbox first, that one outlier will blow up the project.

This is the down-licensing trap. Source systems, especially older on-prem setups, often tolerated giant mailboxes. Many hosted platforms do not. When the destination quota is lower than the actual mailbox size, the migration does not fail politely. It often fails late, after wasting hours of transfer time.

Run an inventory first. No exceptions. Then decide whether the target model supports uneven mailbox size without forcing expensive one-off upgrades.

This is where pooled storage is operationally better than per-seat storage. With TrekMail, storage is shared across the account instead of forcing every mailbox into the same small box. That matters for founders, legal mailboxes, and agency shared inboxes. For teams managing lots of domains, multi domain email hosting only works if the storage model does not punish edge cases.

If you need to watch usage after the move, TrekMail documents mailbox limits and quota behavior in Mailbox Storage Quotas.

6. Corrupt messages are normal, so handle them like an operator

A clean email migration does not mean literally every item is valid. Old mail stores accumulate broken MIME structure, zero-byte attachments, and malformed calendar invites. If your process treats every bad item as a stop-the-world event, one rotten message from 2014 can stall a migration that is otherwise fine.

This is where people confuse precision with competence. You do want an audit trail. You do not want the entire batch frozen because a dead attachment cannot be parsed.

Use a bad-item threshold. Log every skipped item. Review the report. Move on. Most failed items are junk, duplicates from previous systems, or malformed legacy invites nobody needs. If the skipped-items CSV contains something sensitive, pull that message manually. That is still faster than holding the whole email migration hostage.

On TrekMail, the built-in migration workflow exposes progress and failures in the dashboard. On the receiving side, if mail is not landing where you expect after cutover, the fastest sanity check is I’m Not Receiving Emails, which walks through MX verification and mailbox checks.

7. LegacyExchangeDN is the Exchange-only trap that survives the email migration

This email migration failure is specific, ugly, and common. Users reply to an old internal thread in Outlook and get an IMCEAEX or recipient-not-found bounce even though the mailbox exists and new mail works. The reason is not SMTP. It is the old Exchange identity embedded in historical messages and cached addresses.

Exchange stores legacy X.500-style addressing through the LegacyExchangeDN attribute. When you migrate between Exchange environments, or away from one badly, replies to older messages can still reference that old identity. If the destination mailbox does not have the old value added as an X500 proxy address, the reply fails.

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

This does not affect every email migration because plain IMAP moves do not carry Exchange-native objects the way full Exchange migrations do. But if Outlook users must keep replying to old internal threads without breakage, check this before sign-off. It is one of those issues that only appears after the project is declared finished.

A safer email migration cutover plan

A safe email migration is staged, measured, and boring on purpose. That is the goal. You want fewer surprises, not more automation for its own sake. The best cutovers look uneventful because the risky work happened before the MX switch, not during it.

1. Inventory every mailbox size and flag anything unusually large.
2. Lower MX TTL 24 to 48 hours before cutover.
3. Create destination domains and mailboxes first.
4. Run historic IMAP sync before the cutover weekend.
5. Freeze folder cleanup and bulk moves during final sync.
6. Switch MX only when the destination is ready to receive.
7. Run one final delta sync.
8. Test inbound, outbound, folder counts, and old-thread replies.

If you are building the destination side from scratch, create email with your domain covers the setup sequence, and bulk create email accounts helps when you are provisioning more than a handful of users.

For TrekMail specifically, the practical path is straightforward: add the domain, verify DNS, create mailboxes, run the built-in IMAP migration on a paid plan, then switch live traffic once the heavy copy is done. Pricing starts at $3.50 per month. Paid plans include a 14-day free trial with a credit card required. The Nano plan is separate: no card, no trial, always free.

Conclusion: email migration is an operations job, not a copy job

Email migration succeeds when you respect the ugly parts: cached DNS, throttled sources, inconsistent IMAP behavior, quota mismatches, and Exchange leftovers. Ignore those, and the project looks fine right up to the point users start missing mail. Treat email migration like live infrastructure, and it becomes predictable. That is the whole game.

If you want the flat-rate model after the move, TrekMail gives you multi-domain hosting, pooled storage, built-in IMAP migration, mailbox forwarding, API access, and a standards-first setup without per-user fees. Start at trekmail.net or compare plans at TrekMail pricing.