How to Switch Email Hosting Without Losing Mail

Changing email providers is a DNS migration with a mailbox migration attached. A staged approach prepares the new service while the current provider keeps receiving mail, then changes MX after every recipient and sending record is ready. The sequence gives the domain administrator a clear rollback path for a household, founder-run team or personal domain.

Thelemail’s custom-domain email hosting page summarizes the managed service. This guide focuses on planning and executing the move.

Understand what MX changes

MX records tell sending mail servers which hosts accept incoming mail for a domain. A lower preference number has higher priority. When you replace the current provider’s MX records with the new provider’s values, new senders begin delivering to the new service as their DNS caches refresh.

MX has no role in authenticating outbound mail. SPF, DKIM and DMARC handle sending authorization and domain alignment. Those records can usually be prepared before the inbound cutover.

DNS propagation is a cache-expiry process. Each resolver may retain an earlier answer until its time to live expires. Lowering the MX TTL ahead of a planned move can shorten many caches, provided the change itself has enough time to propagate. Some resolvers and sending systems may retain data longer, so the former service should remain active during the overlap.

The SPF, DKIM, DMARC and MX guide explains the role and interaction of each record.

Phase 1: inventory the current domain

List all recipients before touching DNS. Include:

• A mailbox for every person.
• Aliases and forwarding addresses.
• Shared household or company role addresses.
• Addresses used for automated systems, invoices or account recovery.
• Old addresses that still receive occasional messages.
• Senders that use the domain, including website forms, billing systems and newsletters.

Export the current provider’s routing configuration where possible. Search old documentation, password managers and message headers for forgotten addresses. A recipient that receives one annual renewal can be easy to miss during a short observation window.

Map every old address to a mailbox, alias or shared address at the new service. The alias, mailbox and shared address guide provides a clean classification model. Paid Thelemail plans include unlimited aliases, subject to a workspace anti-abuse guardrail; aliases are not included in the Free plan. Mailbox, storage and domain capacities follow the selected pricing plan.

Save the current DNS zone or record each mail-related value. Capture MX, SPF, DKIM selectors, DMARC, MTA-STS, TLS reporting and provider verification records. This snapshot supports troubleshooting and rollback.

Phase 2: reduce TTL and secure administrator access

Several days before the move, check the current MX TTL. If your DNS host permits it, lower the value far enough in advance that existing caches expire before cutover. A value such as 300 seconds is common, although your operational policy may call for another value.

Confirm access to the registrar, DNS provider, old mail host and new mail host. Enable multifactor authentication and verify recovery methods. Keep credentials available through a channel that remains reachable if the domain’s email is disrupted.

Write down the rollback trigger and owner. Examples include repeated recipient failures, authentication failures across major receiving providers, or a missing address discovered after cutover. A clear decision rule avoids improvised DNS changes during an incident.

Phase 3: verify the domain and prepare sending

Add the ownership record supplied by the new provider while the existing MX records remain in place. Verification establishes administrative control without redirecting incoming mail.

Publish the new DKIM record and configure SPF to authorize every legitimate sender that will operate during the transition. A domain should publish one SPF policy, so merge all provider mechanisms into that policy. Keep the lookup limit and third-party senders in view.

DKIM selectors can coexist because each selector has a separate DNS name. Keep the old provider’s DKIM key published while messages signed there may still be evaluated. Remove retired selectors only after the transition and any relevant message lifetime have passed.

Begin DMARC with a policy and reporting setup appropriate to the domain’s current maturity. Review aggregate reports to identify legitimate senders and alignment gaps. A strict enforcement change deserves its own measured rollout after every sender is understood.

Thelemail’s domain connection flow generates and checks the required values. Copy them exactly because host-field behavior varies among DNS control panels.

Phase 4: create recipients and import mail

Create every destination from the inventory. Give each person a separate mailbox, add shared addresses for group responsibilities and route every alias. Test account recovery and multifactor authentication before members depend on the new service.

Import historical messages while the old provider is still available. Large mailboxes may require several passes. Preserve folders, dates and flags where the migration method supports them, then compare representative folders and message counts.

Send outbound test messages from the new service to external providers. Inspect the received headers for SPF, DKIM and DMARC results. Replies will continue following the old MX path until cutover, which is expected. Test the address shown in From, Reply-To behavior and any shared sending identity used by the household or team.

Review the security and threat model with members before the move. Thelemail uses zero-access storage for mailbox content and end-to-end encryption between Thelemail accounts. For outside mail, WKD/OpenPGP protects message content when a compatible key is available; other delivery uses standard SMTP with TLS where supported. External subject headers and delivery metadata remain visible. Recovery methods matter because the service cannot decrypt stored mail after both password and recovery material are lost.

Phase 5: change MX once everything is ready

Choose a time when the administrator can monitor both providers. Remove the former MX records and enter the new provider’s complete MX set exactly as supplied. Preserve priorities and trailing dots according to the DNS host’s format.

Avoid using the old and new providers as equal-priority destinations. Sending servers may choose either path, creating unpredictable split delivery. A staged cutover keeps the old provider active as an account while DNS points incoming mail at one intended provider.

After saving the change:

1. Query the authoritative DNS servers and several public resolvers.
2. Confirm the provider’s wizard sees the expected MX state.
3. Send external tests to a personal mailbox, an alias and a shared address.
4. Send outbound tests and inspect authentication results.
5. Watch queues, bounces and both old and new inboxes.

Test from more than one outside provider because resolvers refresh at different times. Keep the old service accepting mail throughout this mixed-delivery window.

Phase 6: reconcile messages and monitor authentication

Some messages may reach the former host after cutover because a sender used cached MX data. Check old inboxes and perform a final incremental import or manual transfer. Continue until no new messages appear beyond the migration window set by your TTL and risk policy.

Watch DMARC aggregate reports and received-message headers. Confirm that every authorized source aligns with the visible From domain. Review website forms, monitoring systems, invoicing tools and scanners because they are common sources of overlooked mail.

Check for recipient failures. If a forgotten alias appears in a bounce or old inbox, create the missing route promptly and update the inventory. Unlimited aliases make it easy to recreate purpose-specific addresses, while workspace anti-abuse controls and the administrator’s routing policy still apply.

Restore a normal TTL after the setup has remained stable. Remove the old provider from SPF after all outbound sending there has stopped. Retire old DKIM records deliberately, and keep DMARC reporting active as the domain evolves.

Roll back with the same discipline

If the cutover exposes a serious issue, restore the recorded old MX values and verify them at authoritative DNS. Cached answers mean some senders will continue reaching the new provider for a time, so keep both services operational and preserve messages received at each.

Fix the recipient, authentication or account problem before scheduling another cutover. A rollback is a normal reliability tool when it follows a written plan. Document the cause and add a preflight check that would detect it next time.

Migration completion checklist

Treat the move as complete after these conditions hold:

• All known recipients deliver to the intended mailbox or member group.
• Outbound SPF, DKIM and DMARC results match the planned configuration.
• Historical and overlap-period mail has been reconciled.
• Members can sign in, recover accounts and use their expected sending identities.
• The old provider has stopped receiving new mail across the chosen observation period.
• Former sending mechanisms and stale DNS records have been retired.
• Normal TTL values and ongoing DNS monitoring are in place.
• A fresh export has been tested or archived according to the domain’s continuity plan.

The central rule is simple: prepare ownership, authentication, recipients and history while the current MX path remains active. Move incoming delivery only after the new service is complete. That sequence turns a risky all-at-once switch into a controlled domain administration task.