Transfer Mailbox: DNS Cutover Checklist for MX, SPF, DKIM

How to Transfer a Mailbox to a New Email Provider (DNS Cutover Guide)

When you need to transfer mailbox data between email providers, the difference between a clean switch and a 48-hour outage comes down to your DNS strategy. A single misconfigured TTL or a forgotten SPF include results in hard bounces and lost business.

This isn't a creative exercise. It's a sequence of precise technical operations. This guide covers how to transfer mailbox contents safely by manipulating propagation timers, merging authentication identities (SPF/DKIM/DMARC), and routing mail to your new provider without dropping a single message.

For the data migration side (actually moving your emails), see the full IMAP sync guide.

Why DNS Propagation Isn't Instant When You Transfer Mailbox Data

DNS is a distributed caching system. When you change a record, you're at the mercy of every recursive resolver—ISP DNS servers, Google's 8.8.8.8, local routers—respecting your Time-To-Live (TTL) value.

If your TTL sits at the standard 86,400 seconds (24 hours), your cutover creates split-brain routing for a full day. Some mail lands in the new inbox, some in the old.

The Long Tail and Negative Caching

Two hidden factors break cutovers regularly when you transfer mailbox accounts:

• The Long Tail: Even with a low TTL, roughly 1–5% of global resolvers ignore values under 60 minutes. Plan for residual traffic to the old provider for about an hour post-cutover.
• Negative Caching (SOA): If you query a record before it exists—say, checking a new DKIM selector too early—the NXDOMAIN response is cached based on your SOA record's minimum TTL (often 1 hour). This blocks the valid record from being seen even after you publish it.

Phase 1: The 48-Hour Countdown

Don't touch your MX records yet. Prepare the environment to accept the change first.

Step 1: Lower TTLs (T-Minus 48 Hours)

Locate your MX, SPF (TXT), and DMARC records. Lower their TTL to 300 seconds (5 minutes).

This compresses the propagation window. When you make the final switch, the world updates in 5 minutes instead of 24 hours.

Step 2: The SPF Merge (T-Minus 24 Hours)

SPF (RFC 7208) authorizes IPs to send on your behalf. During transition, you must authorize both providers simultaneously.

The trap: SPF limits you to 10 DNS lookups. Merging two providers (Google Workspace + TrekMail, for example) can exceed that limit.

The fix: Flatten the record. Replace nested include: statements with direct ip4: mechanisms where possible.

Example transition record:

If you're using TrekMail's BYO SMTP (Amazon SES or SendGrid), include their SPF records instead.

Step 3: DKIM Pre-Publishing

DKIM uses selectors (e.g., google._domainkey). Generate DKIM keys on the new provider using a unique selector (e.g., tm1._domainkey). Never reuse a selector name—new selectors can be published days in advance without conflicting with the old provider.

Step 4: Relax DMARC

If your DMARC policy is p=reject or p=quarantine, change it to p=none at least 24 hours before cutover. Authentication failures are likely during the first hours of a switch. p=none ensures failures are logged (RUA reports) but mail still gets delivered. The Google DMARC setup guide explains how to configure your policy correctly.

Phase 2: The Cutover Execution

TTLs are low, authentication is merged. Time to transfer mailbox routing to the new host.

Step 1: Verify Authoritative vs. Recursive

Check that new records are visible on your authoritative nameserver before checking the world:

Step 2: Update MX Records

Delete old MX records. Add the new ones. TrekMail users:

Keep TTL at 300 seconds. Don't raise it yet.

Step 3: Flush and Verify

Flush your local DNS cache (ipconfig /flushdns on Windows, sudo dscacheutil -flushcache on macOS). Run dig again—you should see the new MX records immediately.

Phase 3: Post-Cutover Stabilization

Watch for Tenant Attribution Errors (550 5.7.64)

A common failure when you transfer mailbox hosting to Microsoft 365 or similar suites. If the destination hasn't fully provisioned your domain in its internal directory, it rejects mail with "Relay Access Denied." Ensure domain status is "Verified" or "Healthy" in the new provider's dashboard before switching MX.

Monitor DMARC Reports (72 Hours)

Watch your RUA reports for three days:

• Success: Traffic from the new provider's IPs passes SPF and DKIM.
• Failure: Legitimate traffic (billing systems, marketing platforms) fails auth. Update SPF/DKIM immediately.

Cleanup (T-Plus 72 Hours)

Once traffic stabilizes:

1. Remove the old provider's include: from your SPF record.
2. Remove old DKIM CNAME/TXT records.
3. Raise TTLs back to 3,600s (1 hour) or 86,400s (24 hours).
4. Enforce DMARC (p=quarantine or p=reject).

The Transfer Mailbox Checklist at a Glance

TrekMail Makes the Transfer Mailbox Process Simpler

Manual DNS management is error-prone. A single syntax error in a TXT record can invalidate your entire SPF policy.

For Small Businesses

TrekMail provides a real-time DNS Health Check. Instead of guessing whether propagation is complete, the dashboard pings your authoritative nameservers and validates MX, SPF, and DKIM records against the required baseline. Syntax errors get flagged before they cause bounces.

Learn more about setting up email on your own domain.

For Agencies

Managing 50+ domains demands standardization. TrekMail lets you apply a consistent DNS template across all client tenants. On Starter and Agency plans, Managed SMTP handles IP reputation and delivery headers—no complex SPF flattening or IP warm-up schedules required.

See how multi-domain email hosting works for agencies.

All paid plans come with a 14-day free trial (card required). The Nano plan requires no card.

Conclusion

When you transfer mailbox data to a new provider, the DNS cutover is where things go wrong. Lower your TTLs early, merge your authentication records, execute the MX switch during a maintenance window, and monitor DMARC reports for 72 hours. That's the playbook.

If you'd rather skip the manual DNS juggling, try TrekMail for free and let the dashboard handle validation for you.