GICT knowledge base
Migrate Email with imapsync Using Verified TLS Connections
Published
imapsync copies messages and folders between two authorized IMAP mailboxes. It does not create mail accounts or migrate an entire hosting service. Plan destination quotas, required folders and final mail reconciliation before changing MX records.
External-provider/cross-panel mailbox transfers are self-managed. InterServer’s complimentary migration service is limited to cPanel-to-cPanel or DirectAdmin-to-DirectAdmin on web hosting plans; VPS and dedicated-server migrations are not offered. For an eligible account transfer, confirm the mail scope through the migration support process.
Use a supported installation and authorized access
Follow the maintainer’s installation documentation for your operating system and release. Do not install the CentOS 6/EPEL/Remi packages previously shown here or assume an unverified repository command works on a current system. Check imapsync --version and imapsync --help after installation.
Create the destination mailbox and confirm both actual IMAP hostnames, authentication policies and quotas. Accounts may require application passwords or OAuth rather than the main login password. The example below is specifically for providers allowing password-based IMAP over TLS on port 993.
Protect credentials and verify both servers
Run on a trusted host. Create a private working directory and use a text editor to place only the appropriate mailbox secret on the first line of source.pass and destination.pass. Do not place passwords directly in command arguments, public directories, logs or tickets.
umask 077
mkdir -p "$HOME/private-imap-migration"
chmod 700 "$HOME/private-imap-migration"
cd "$HOME/private-imap-migration"
After creating the two password files privately, restrict them and run this dry comparison with your real provider hostnames and usernames substituted consistently:
chmod 600 source.pass destination.pass
imapsync \
--host1 imap.source.example --port1 993 --ssl1 \
--user1 user@example.com --passfile1 source.pass \
--sslargs1 SSL_verify_mode=1 \
--sslargs1 SSL_verifycn_scheme=imap \
--sslargs1 SSL_verifycn_name=imap.source.example \
--host2 imap.destination.example --port2 993 --ssl2 \
--user2 user@example.com --passfile2 destination.pass \
--sslargs2 SSL_verify_mode=1 \
--sslargs2 SSL_verifycn_scheme=imap \
--sslargs2 SSL_verifycn_name=imap.destination.example \
--dry
The maintainer documents that certificate authenticity is not checked by default, so this example explicitly requests peer and hostname verification for both connections. The host must have a usable trusted CA store; if verification fails, correct the certificate, name or trust configuration instead of disabling verification. An encrypted connection alone does not prove the server’s identity.
--dry still connects and authenticates and can write local logs. It does not establish that every message can be copied successfully. Check its report, folder mapping and any permission or quota errors. A test destination must be a mailbox you are authorized to access.
Copy conservatively, then check the result
Once the configuration and scope are accepted, repeat the reviewed command without --dry to copy. This writes to the destination. Start with a test mailbox or deliberately scoped folder before a large migration. Do not add deletion, expunge or folder-exclusion options unless their effect is understood and explicitly intended.
Inspect failures and skipped messages. Compare required folders and representative messages, attachments, dates and read/unread flags; do not promise that every provider preserves all metadata identically. Contacts, calendars, aliases, filters, signatures and server settings need separate handling. Mail downloaded only into a local POP3 archive is outside what an IMAP server exposes.
After the initial copy, agree the DNS cutover and final reconciliation so later mail on the source is not lost. Test both sending and receiving, retain the source until acceptance, then revoke temporary credentials and protect or remove working files/logs under your retention policy.
References: imapsync Unix tutorial, maintainer security FAQ, and IO::Socket::SSL certificate settings. Reviewed October 14, 2026. Command syntax, argument preservation and upstream option definitions were checked; no real mailbox copy or TLS connection was tested.
Related guides
Check MariaDB Versions and Compatibility on Shared Hosting
Check your actual MariaDB/MySQL server version, maintenance coverage and application requirements before requesting a shared-hosting upgrade or move.
MigrationMigrate WordPress with Migrate Guru: Scope and Safety Checks
Use Migrate Guru for a scoped WordPress copy. Review third-party processing, protect the destination and verify the application before changing DNS.
MigrationcPanel to DirectAdmin: Conversion, Restore and Verification
Convert a supported cPanel account archive to DirectAdmin with private delivery, ownership mapping and application/mail checks before DNS cutover.
MigrationcPanel to CWP: Private Backup Import and Recovery Checks
Plan a self-managed cPanel-to-CWP import. Transfer backups privately, check account conflicts and verify websites, mail and DNS before cutover.
