Migrating from another provider
Moving a domain that already receives mail: the order that never bounces a message, what to prepare, how the history import works, and what to check when something looks off.
The order that loses no mail
The intuitive plan, copying the old mail first and switching the MX at the end, is the one that loses messages. Copying a mailbox over IMAP takes hours or days, and everything arriving at the old provider during the copy has to be chased afterwards. Switching the MX takes effect in minutes: from then on new mail arrives here, and the history is copied calmly in the background, with nothing in flight.
- Add the domain. Nothing changes for your mail yet. This only starts the plan, and we detect your current provider from it.
- Publish everything except the MX. SPF and DKIM prove the domain is yours and do not affect delivery to your current provider.
- Create every address. Aliases included, and the ones nobody remembers. After the switch, mail to an address that does not exist here is returned to the sender.
- Switch the MX. The only step that changes where mail goes. It takes effect gradually: during propagation a message lands on one side or the other, never nowhere.
- Import the history. Per mailbox, over IMAP, in the background. Follow-up syncs run for a week to catch what the old provider received late.
Before you start
- Access to the DNS panel your domain nameservers point to. Records created anywhere else are ignored.
- A complete list of the addresses that receive mail today, aliases included. Compare it against the old provider user list before the switch; a forgotten address means bounced mail.
- Keep the old provider account active, or take a backup, until every mailbox here shows "Imported". Do not delete anything on the old side during the migration.
- Warn the team: after the switch, phones and mail apps need to be set up again, with the new server and the new passwords.
- Pick a calm moment for the switch. Not because mail is lost during propagation (it is not), but because devices reconnect and people have questions.
Two DNS moments, not one
The records split into two groups published at different times. The panel shows the exact values for your domain.
| Record | When | Why then |
|---|---|---|
| SPF (TXT) | First, before anything else | Proves ownership and authorises sending. It does not affect where mail arrives, so it is safe while the old provider still receives. |
| DKIM (CNAME) | First, with the SPF | Signs your outgoing mail. Same property: publishing it changes nothing for the old provider. |
| MX | Last, after every mailbox exists | This is the switch. Replace the old provider lines with ours. Keeping both splits your mail unpredictably. |
- If a TXT starting with "v=spf1" already exists, edit it to include our part. A second SPF record invalidates both.
- Propagation is gradual: minutes at most DNS hosts, up to 24 hours at slow ones. The panel checks your authoritative nameservers, so "Found" means published, not necessarily visible everywhere yet.
- While the MX propagates, each message is delivered to the old provider or to us. The follow-up syncs bring over what still lands on the old side.
Importing the history
The import runs per mailbox, from the panel, in the background. We detect the old provider from the MX records your domain had before the switch and pre-fill the server. Usually all you type is the mailbox password at the old provider.
| Old provider | What you need |
|---|---|
| An app password (myaccount.google.com/apppasswords, requires 2-step verification). An ordinary password is refused. | |
| Microsoft 365 | Contact support. We migrate it with you through a Microsoft-approved app, no user passwords involved. |
| Titan | In the Titan webmail, open Settings and enable "Titan on other apps" first, otherwise the connection is refused. |
| Anything else | The IMAP server (often mail.yourdomain.com) and the mailbox password there. |
- Follow-up syncs on days 1, 3 and 7 catch what the old provider received while the MX was still propagating. With "Finish automatically" checked, the password is kept encrypted for up to 7 days so those syncs run on their own, then deleted; unchecked, you are asked again for each sync.
- Running a sync again never duplicates: each message is copied once and remembered, so a second pass only brings what is new.
- Folders, read state and message dates are preserved. When the passes are done, the mailbox shows "Imported".
If something looks wrong
- Mail still arriving at the old provider after the switch. Propagation in progress, up to 24 hours at slow DNS hosts. Nothing is lost either way, and the follow-up syncs bring those messages here. If it persists past a day, check that the old MX lines were removed.
- A sender got a bounce. The address does not exist here. Create the mailbox (or an alias) and ask them to resend; for the first week, glance at the Rejected list in the panel. It catches the address everyone forgot.
- Replies landing in spam. SPF or DKIM not verified yet, or a second SPF record was created instead of editing the existing one. Fix the record and check again in the panel.
- The import fails immediately. Almost always credentials: a Google account needs an app password, Titan needs "Titan on other apps" enabled, and elsewhere it is usually a mistyped server or password. The exact reason appears on the user, under "Needs attention".
- Old messages seem missing. The panel shows how many messages at the old provider are not accounted for yet; a scheduled follow-up sync usually resolves it. If a gap remains after the last sync, press "Sync again" before cancelling the old account.
- A device cannot log in. It is still pointing at the old server. Set it up with the settings on the "Connecting apps and devices" page, using the new password.