Email Transfer: DNS, IMAP Copy, and Cutover Explained

Email Transfer Explained: DNS, IMAP Copy, and the Cutover

The phrase "email transfer" is a linguistic trap. In the physical world, transferring a file means it leaves location A and arrives at location B. In email infrastructure, that never happens.

An email transfer is actually two independent operations running in parallel: replicating a database (IMAP sync) and redirecting traffic (DNS cutover). Confusing these two layers is the primary cause of data loss, split-brain routing, and Monday morning support tickets.

This guide breaks down what "transfer" actually means in practice, what moves and what doesn't, and how to pick the right approach for your situation.

The Three Types of Email Transfer

Before touching a server, define the scope. "Transfer" gets used interchangeably for three distinct operations, and mixing them up causes real problems.

1. Domain Transfer (Registrar Change)

You're moving management of example.com from GoDaddy to Namecheap. This changes the billing entity for the domain name. Impact on email: none—provided you copy your DNS zone file exactly. Change nameservers without replicating MX records and email goes down instantly.

2. Email Migration (Provider Switch)

You're firing Google Workspace and moving to TrekMail (or any other host). This means standing up a new server, copying old data to it, and telling the internet to send new mail there. Impact on email: total. This is a forensic reconstruction of your data, and it's the focus of this article.

For the step-by-step execution plan, see the full IMAP sync guide.

3. Account Ownership Transfer

Changing the admin email on an account from bob@ to alice@. It's a database permission update. Impact on email: zero.

The Two Layers You Must Manage During an Email Transfer

A successful email transfer requires managing two timelines simultaneously. Mess up either one and you've got problems.

The Data Layer (IMAP Copy)

New providers don't absorb old data. You pull it via the IMAP protocol (RFC 3501). This is a copy, not a move—the original stays on the source server until you destroy it.

The UIDVALIDITY Trap: IMAP was designed for viewing messages, not bulk replication. Every folder has a UIDVALIDITY value. If the source server crashes or re-indexes during migration, this value changes. Your migration tool thinks every email is new and downloads them all again—users see 10,000 duplicates. The fix: use a tool that deduplicates based on Message-ID headers, not just IMAP UIDs.

The Routing Layer (DNS Cutover)

While data copies, you must redirect new mail. This is controlled by the MX (Mail Exchange) record:

The split-brain risk: DNS records are cached by ISPs worldwide. If your TTL is 86,400 seconds (24 hours) and you switch MX on Friday at 5 PM, some servers still send to the old provider until Saturday at 5 PM.

The fix: the "300-second rule." Lower your MX TTL to 300 seconds at least 24 hours before the move. For the full DNS cutover procedure, see how to set up email on your domain.

What Transfers via IMAP and What Doesn't

TrekMail is a specialized email platform (IMAP/SMTP). We don't offer calendar or contact sync because we believe in doing one thing well. When you move from a suite (Google/M365) to a pure email host, you need to know exactly what comes along.

The Modern Auth Cliff

If you're migrating from a provider that enforces OAuth (like Google), legacy devices—old scanners, Outlook 2013—may fail to connect to a standard IMAP server. The Google Workspace migration documentation details how App Passwords can bridge this gap. TrekMail supports standard IMAP/SMTP auth over TLS 1.2. Make sure your devices support it.

Which Email Transfer Path Do You Need?

Scenario A: Cutting Costs on Google Workspace

1. Set up a TrekMail account with your domain
2. Use TrekMail's migration tool to copy email data
3. Export contacts (.vcf) and calendars (.ics) to local files
4. Change MX records to mx1.trekmail.net / mx2.trekmail.net
5. Cancel Google Workspace

Scenario B: Moving Your Domain to a New Registrar

1. Enable domain transfer at current registrar
2. Get EPP/auth code
3. Initiate transfer at new registrar
4. Critical: Ensure nameservers don't change, or copy the zone file perfectly

TrekMail's Built-In Email Transfer Tools

Manual IMAP migrations are error-prone. A single timeout or UIDVALIDITY shift can corrupt a mailbox. TrekMail treats migration as core infrastructure, not an afterthought.

Migration Engine

The dashboard connects directly to your old provider (Gmail, cPanel, Exchange) and handles the IMAP sync server-to-server. Retries, throttling back-offs, and header deduplication are automatic. No command line required.

Pooled Storage for Agencies

If you're an MSP moving 50 clients, managing 50 separate storage quotas is a waste. TrekMail offers pooled storage (e.g., 200 GB shared across all domains). Allocate space where it's needed.

DNS Validation

A simple DNS check tool verifies your MX, SPF, and DKIM records are correct—so you don't accidentally blackhole your own email during the switch.

All paid plans include a 14-day free trial (card required). The Nano plan needs no card.

Conclusion: Know Which Email Transfer You Actually Need

Most email transfer failures happen because people conflate domain transfers, email migrations, and account changes. Separate the data layer (IMAP copy) from the routing layer (DNS cutover), handle them on independent timelines, and verify with item counts when you're done.

If you're ready to move, start your free TrekMail account and let the migration engine handle the heavy lifting.