Reusable documentation

Complete Email Migration Guide

Migration: Titan / any IMAP email provider → cPanel / Dovecot

This guide is written to be reusable for any domain. Replace the example values with your own domain, mailbox, server IP and credentials.

Contents

  1. Overview and architecture
  2. Requirements and preparation
  3. Create the destination mailbox
  4. Create the mail hostname
  5. Test IMAP connectivity
  6. Migrate mail with imapsync
  7. Verify the migration
  8. Change MX records
  9. Understand DNS propagation
  10. Configure SPF
  11. Configure DKIM
  12. Configure DMARC
  13. Test incoming and outgoing mail
  14. Perform the final synchronization
  15. Production cutover
  16. Troubleshooting
  17. Security rules
  18. Final checklist

1. Overview and Architecture

The safest migration is a staged process. First copy the existing mail, then verify it, then change mail routing, then configure authentication and finally perform a last synchronization.

ComponentExamplePurpose
Domainexample.comThe domain being migrated.
Old IMAP hostimap.titan.emailSource mail server.
New mail hostmail.example.comDestination cPanel/Dovecot server.
Mail server IP203.0.113.10Public IPv4 of the new mail server.
Mailboxuser@example.comMailbox being migrated.
IMAP993 / SSL/TLSUsed by imapsync to copy messages.
SMTP465 / SSL/TLSUsed by mail clients to send mail.
Important: IMAP migration copies mail messages and folders. It normally does not migrate contacts, calendars, signatures, filters, forwarding rules, autoresponders, mailbox passwords or client-side settings.

2. Requirements and Preparation

Do not change MX records at the beginning

Keep the old mail provider active until migration, verification, final synchronization and DNS cutover are complete. This prevents messages from being lost during the transition.

Identify authoritative DNS

dig NS example.com +short

The returned nameservers tell you where the authoritative DNS zone is hosted. DNS records should be changed at that provider unless cPanel is authoritative for the domain.

3. Create the Destination Mailbox

In cPanel:

  1. Open Email → Email Accounts.
  2. Create the mailbox, for example user@example.com.
  3. Set a strong mailbox password.
  4. Confirm the mailbox exists.

To list mailboxes from the shell, where supported:

uapi --user=CPANEL_USERNAME Email list_pops
Do not put passwords directly into shell commands or documentation. Enter them only at secure prompts or through an approved secret-management method.

4. Create the Mail Hostname

Create an A record for the hostname used by cPanel mail clients:

TypeNameValue
AmailNEW_MAIL_SERVER_IP

Verify:

dig A mail.example.com +short

Expected result:

203.0.113.10

Verify that cPanel/Dovecot is listening for IMAPS:

ss -ltnp | grep ':993'

Port 993 should normally show Dovecot listening on IPv4 and/or IPv6.

5. Test IMAP Connectivity Before Migration

Test the source

imapsync \
  --host1 imap.titan.email \
  --port1 993 \
  --ssl1 \
  --user1 'user@example.com' \
  --justconnect

Test the destination

imapsync \
  --host1 mail.example.com \
  --port1 993 \
  --ssl1 \
  --user1 'user@example.com' \
  --justconnect

These tests establish network/TLS connectivity. A successful --justconnect test does not necessarily prove that the password is correct.

Authenticate and synchronize folders without messages

imapsync \
  --host1 imap.titan.email \
  --port1 993 \
  --ssl1 \
  --user1 'user@example.com' \
  --host2 mail.example.com \
  --port2 993 \
  --ssl2 \
  --user2 'user@example.com' \
  --justfolders

Enter the source and destination passwords only when prompted. A successful run should report successful authentication and no errors.

6. Migrate the Actual Mail

Once connectivity and authentication are confirmed, run the actual synchronization:

imapsync \
  --host1 imap.titan.email \
  --port1 993 \
  --ssl1 \
  --user1 'user@example.com' \
  --host2 mail.example.com \
  --port2 993 \
  --ssl2 \
  --user2 'user@example.com'

The command copies messages from host1 to host2. With this basic command, the source mailbox remains available.

What to expect

Do not use destructive options such as --delete1 or --delete2 unless you fully understand the consequences and have a backup. For a migration, preserving the source is the safer default.

7. Verify the Migrated Mailbox

Do not delete the source mailbox yet.

8. Change MX Records

Only change MX after the mailbox has been migrated and verified.

Remove the old provider's MX records and add the new mail server. Example:

TypeNamePriorityTarget
MX@10mail.example.com.

The exact priority is not the important part; the important part is that the intended mail server is the MX destination and obsolete MX records are not left active unintentionally.

Verify authoritative DNS directly

dig NS example.com +short
dig MX example.com @AUTHORITATIVE_NAMESERVER +short

Also check public resolvers:

dig MX example.com @1.1.1.1 +short
dig MX example.com @8.8.8.8 +short

9. DNS Propagation and Caching

Different DNS resolvers may temporarily return different MX records because they cache records according to their TTL. The authoritative nameservers are the best reference for determining whether the change was actually published.

Example: If the authoritative server reports mail.example.com while Google DNS temporarily reports the old provider, the authoritative change is already published but some public caches have not expired.

Do not repeatedly edit MX records simply because one resolver still has the old value.

10. Configure SPF

SPF tells receiving servers which systems are authorized to send mail for your domain.

If the new mail server sends directly from 203.0.113.10, a simple SPF example is:

v=spf1 ip4:203.0.113.10 ~all

Critical SPF rule

A domain should normally have one SPF TXT policy. Do not create multiple independent SPF TXT records beginning with v=spf1.

If the old provider is no longer sending mail, remove its SPF include. If another legitimate service still sends mail (website, marketing platform, CRM, Microsoft 365, Google Workspace, etc.), its authorization must remain in the same SPF record.

Verify:

dig TXT example.com +short

11. Configure DKIM

DKIM adds a cryptographic signature to outgoing mail. cPanel/Exim can generate the DKIM key pair.

Find the cPanel-generated DKIM information

In cPanel, open:

Email → Email Deliverability → Manage for the domain.

cPanel will show a suggested DKIM record, normally using a selector such as:

default._domainkey

The DNS record generally looks like:

Host/Name:
default._domainkey

Type:
TXT

Value:
v=DKIM1; k=rsa; p=YOUR_PUBLIC_KEY
Never publish or share the DKIM private key. Only the public key belongs in DNS.

Useful server locations

cPanel commonly stores DKIM keys under:

/var/cpanel/domain_keys/private/
 /var/cpanel/domain_keys/public/

Do not paste the contents of a private-key file into DNS.

12. Configure DMARC

DMARC tells receiving systems how to handle mail that fails authentication/alignment and provides reporting capabilities.

A safe starting policy is monitoring mode:

TypeNameValue
TXT_dmarcv=DMARC1; p=none;

After SPF/DKIM are confirmed and legitimate senders are known, the policy can be strengthened gradually, for example with quarantine and eventually reject.

Do not immediately use p=reject if you have not identified every legitimate system that sends mail for the domain.

13. Test Incoming and Outgoing Mail

Inbound test

From Gmail, Outlook or another external mailbox, send:

external-account@example.net
        ↓
user@example.com

Confirm the message arrives in cPanel Webmail.

Outbound test

From cPanel Webmail, send:

user@example.com
        ↓
external Gmail/Outlook address

Confirm delivery. Check both Inbox and Spam.

Authentication checks

For a delivered message, inspect the recipient's message headers. Look for results similar to:

SPF: PASS
DKIM: PASS
DMARC: PASS

A Gmail rejection such as:

550-5.7.26 Your email has been blocked because the sender is unauthenticated.
SPF = did not pass
DKIM = did not pass

usually means DNS authentication is missing, incorrect, not propagated, or the sending server is not authorized.

14. Perform the Final Synchronization

After MX is changed and mail is being delivered to the new server, perform one final source-to-destination sync if the old mailbox remained active during the transition.

imapsync \
  --host1 imap.titan.email \
  --port1 993 \
  --ssl1 \
  --user1 'user@example.com' \
  --host2 mail.example.com \
  --port2 993 \
  --ssl2 \
  --user2 'user@example.com'

This catches messages that arrived on the old server before DNS propagation completed.

Goal: all messages that existed on the source are present on the destination, with zero errors.

15. Production Cutover

  1. Migration completed.
  2. Mailbox verified.
  3. MX changed.
  4. Inbound delivery verified.
  5. SPF corrected.
  6. DKIM published.
  7. DMARC published.
  8. Outbound delivery verified.
  9. Final imapsync completed.
  10. Keep the old provider available for a safety period.
  11. Only after everything is stable should the old mail service be cancelled.

16. Troubleshooting

MX still shows the old provider

dig MX example.com +short
dig MX example.com @1.1.1.1 +short
dig MX example.com @8.8.8.8 +short
dig MX example.com @AUTHORITATIVE_NAMESERVER +short

If authoritative DNS is correct but a public resolver is old, wait for its cache to expire.

Inbound mail does not arrive

Useful commands:

dig MX example.com +short
dig A mail.example.com +short
systemctl status exim
tail -f /var/log/exim_mainlog

Gmail says SPF failed

Gmail says DKIM failed

imapsync authentication fails

There is one extra message on the destination

This can happen when the destination mailbox already contained a welcome/system message before migration. Do not delete it automatically. Compare the message and decide whether it should remain.

17. Security Rules

18. Final Production Checklist

Typical cPanel mail-client settings

SettingRecommended value
Incoming protocolIMAP
Incoming servermail.example.com
IMAP port993
IMAP securitySSL/TLS
Outgoing servermail.example.com
SMTP port465 SSL/TLS (or the port shown by cPanel)
UsernameFull email address
PasswordMailbox password

19. Quick Migration Flow

CREATE MAILBOX
      ↓
CREATE mail.domain.com A RECORD
      ↓
TEST IMAP CONNECTION
      ↓
TEST AUTHENTICATION
      ↓
SYNC FOLDERS
      ↓
MIGRATE EMAILS
      ↓
VERIFY MAIL + ATTACHMENTS
      ↓
CHANGE MX
      ↓
WAIT / CHECK DNS PROPAGATION
      ↓
TEST INBOUND
      ↓
CONFIGURE SPF
      ↓
CONFIGURE DKIM
      ↓
CONFIGURE DMARC
      ↓
TEST OUTBOUND
      ↓
FINAL IMAPSYNC
      ↓
KEEP OLD PROVIDER TEMPORARILY
      ↓
FINAL CUTOVER COMPLETE

Page View Counter

This documentation uses a server-side SQLite counter. Each successful page load increments the total view count.

Total page views 91

The counter is stored on the server, so it is not reset when the browser is refreshed or closed.