Moving email to a new hosting provider: an IMAP migration checklist

Plan an ordinary IMAP mailbox move: check storage, copy messages, verify folders, change mail routing and keep the old service until the handover is proven.

Person holding a memory card beside an open laptop
On this page

Moving a website does not copy its stored email. For an ordinary IMAP mailbox, plan a separate move: check the destination capacity, preserve the old messages, copy and verify the history, then coordinate mail routing and the final handover. Keep the original service active until both old and new deliveries have been accounted for.

Before choosing a destination, compare hosting packages and confirm the exact email product, storage and migration support. A free mailbox that cannot hold your existing history is not a suitable destination.

Check that this is an ordinary IMAP move

This checklist covers copying messages and folders from a provider-supported Internet Message Access Protocol (IMAP) account into an eligible new email service. It uses Hostinger Email’s documented import tool as an example, not a privately tested migration.

IMAP migration does not transfer contacts, calendars or tasks. It also does not copy mail stored only on a computer. If the source is Exchange, Microsoft 365, an OAuth-only account, a POP-only account or a local archive, ask the destination provider for its supported migration method before proceeding. Do not disable multi-factor authentication or bypass certificate checks to force an incompatible account through this example.

For the website files and database, follow the separate website-hosting move checklist. Changing web hosting can leave the existing email service in place.

A worked capacity check before copying

Suppose a fictional business has one ordinary IMAP mailbox containing 2 GB of messages. Hostinger’s current one-year email trial lists 1 GB per mailbox, so that destination is too small. Its paid Business Starter allowance is 5 GB: the existing 2 GB would leave about 3 GB of nominal capacity, before growth and any accounting differences.

Confirm the purchased account’s actual allowance and the source’s message sizes first. Hostinger’s import documentation sets a 50 MB limit per message. A history can fit the total quota while still containing an individual message the tool cannot import. Resolve exceptions before promising a complete transfer.

Prepare access, a backup and a handover owner

  1. Name one person responsible for the move. Agree the copy window, the mail-routing change, how messages arriving during the transition will be reconciled and who can restore the previous routing.
  2. Inventory each source mailbox. Record its address, size, folders and special arrangements such as aliases, forwarding and filters. Obtain the provider’s approved IMAP hostname and secure connection/authentication requirements.
  3. Preserve an independent copy. Use the source provider’s supported export or backup method, and check that representative messages and attachments can be opened. A synchronised mail client alone is not proof of an independent backup.
  4. Create the destination mailboxes. Map every source address to its intended target, confirm quota and recovery access, and keep the old subscription paid and active.
  5. Record the current mail configuration. Save the relevant DNS values, aliases, clients and website sending settings. DNS means the domain name system; its mail records may be managed separately from both hosts.

If the source hostname, authentication, backup or final synchronisation method is uncertain, stop before changing routing and ask the relevant provider. Handle credentials only through the provider’s secure migration interface.

Copy the initial history with Hostinger Email Import

The official import instructions allow an initial copy while the original email account remains active. This path is for Hostinger Email, not an assumption that Titan, Google Workspace or cPanel accounts have the same tool.

  1. In hPanel, open Emails, choose Manage for the correct domain, then open Email Import.
  2. Select New email import request and continue through the preparation step for importing from another service.
  3. Under Import from, provide the source email address, the credential accepted by that service and its approved IMAP hostname. Use a hostname with a valid certificate; do not substitute a raw IP address to work around a connection problem.
  4. Under Import to, select the destination mailbox and provide the required destination credential.
  5. Check the source-to-target mapping in the summary, then start the request. Monitor its status in the Requests area and the completion notification.

A completed request still needs inspection. Folder availability depends on what the source exposes through IMAP. Check Inbox, Sent and custom folders, older and recent messages, and attachments in the destination’s own webmail. Investigate missing folders, oversize messages or errors before switching mail delivery.

Coordinate the final mail-routing change

Do not assume a one-off import continues synchronising. Before the switch, agree with the migration provider how to copy messages that arrived or were sent after the first import, including whether its tool supports a safe incremental pass. Do not repeatedly rerun an import without understanding duplicate handling.

  1. Prepare the complete configuration. Recreate required aliases, forwarding and filters. Schedule client and website sending changes with the people who use them.
  2. Apply the destination’s current mail records. At the authoritative DNS service, use the exact values shown for the account. MX records route incoming mail; SPF authorises sending sources, DKIM signs messages and DMARC sets authentication policy.
  3. Preserve legitimate senders. Maintain one valid SPF record for the relevant hostname, incorporating required authorised services. Do not add a second SPF record or delete unrelated DKIM selectors merely because the mailbox provider changes. Have the provider review a complex configuration.
  4. Keep watching both services. DNS caches can mean mail still reaches the old service during the transition. Check both for new incoming messages and coordinate the agreed final copy, including messages sent from old clients.
  5. Update and test the users’ clients and website sender. Use the new provider’s documented settings. Send and receive with an external account you control, check replies, and test a real website enquiry if the site sends mail.

Accept the move before cancelling anything

Accept the handover only after the agreed folders and exceptions are accounted for, the independent backup is available, new inbound and outbound messages work, and the responsible person confirms that transition-period messages have been reconciled. Record the last checks of both services. An import notification alone is not enough.

If delivery fails, keep both copies and escalate to the migration owner. Restoring the recorded old routing may be part of the recovery plan, but a DNS rollback does not merge messages already delivered to the new mailbox. Preserve and reconcile those messages before any return. Do not cancel either service while the message history is unresolved.

For the buying decision behind the move, see our guide to email included with web hosting. Use the hosting comparison to assess the website package, with the mailbox capacity and supported migration route confirmed separately.

Sources and photo credit

Documentation checked on 29 October 2026.

Cover photo: Anete Lusina / Pexels. Illustrative photograph; it does not show an email interface, provider facility or migration test.

← All hosting guides