Migrating mail while the domain has not moved yet

Why the server name leads to the wrong place

mail.yourdomain is an ordinary DNS record of your domain. Until you repoint it at the new provider it resolves to the old server, and every client — ours included — lands there. That is DNS working correctly, not a misconfiguration.

The practical rule follows: during a transfer you cannot use the same name for both sides. You need two different addresses — one that reaches the old server and one that reaches the new one.

What to use instead of an IP

Every hosting provider has its own mail hostname that does not depend on your domain: something like mail.hoster.tld, imap.hoster.tld or srv12.hoster.tld. It is printed in the control panel under mail client configuration, and in the message the provider sent when the mailbox was created.

That is the name to enter for the new side, while your own mail.yourdomain stays on the old side for as long as the record still points there. Both sides are reachable at once and the transfer runs normally.

• Old mailbox: mail.yourdomain — while DNS still points at the old server.
• New mailbox: the hosting provider’s own hostname from the control panel.
• After the DNS switch both sides answer on your domain again, and a second run picks up whatever arrived during the move.

When an IP does work

The server field accepts an IP address, but the connection succeeds only if the server’s TLS certificate covers that IP. Such certificates exist — some hosts issue them, and corporate networks with an internal CA do — but they are rare: nearly every certificate is issued for a name.

We verify the certificate against exactly what you typed and offer no way to turn that off. This is not fussiness: a "do not verify" switch is all it takes for a mailbox password to land on a server that merely claims to be yours. When a certificate does not match, the log shows which name was expected — and that line is usually where the correct address comes from.

The order that loses no mail

A migration needs no downtime and never modifies the source, so it happens before the domain switch, not after.

• Create the mailboxes at the new provider and check there is room for the whole volume.
• Migrate while the domain still works the old way: users notice nothing.
• Repoint the domain’s MX records at the new provider.
• A day later, run the migration again: it picks up the mail that reached the old server during the switch. No duplicates — messages already transferred are skipped.