Same Email, My Own Server: Moving from iCloud to Hestia

I wanted to move away from Apple's ecosystem without changing the email address people already know: [email protected].

My domain's email was hosted in iCloud Mail. I also had a VPS running Hestia Control Panel, with an older mailbox still on it. My first thought was simple: could I just change Thunderbird's server settings and carry on?

That question became a useful lesson in how email actually works.

You can keep your custom-domain address when changing mail providers. But changing DNS does not transfer your old messages. The archive and future mail delivery are two separate parts of the migration.

Here is the process I followed, including the mistakes that made the steps easier to understand.

First, separate the address, the server and the app

These three things are easy to mix up:

Part	What it does	My setup
Email address	The address people write to	[email protected]
Mail hosting	Receives and stores the messages	Moving from iCloud to my Hestia server
Email app	Lets me read and send messages	Thunderbird on desktop; Roundcube in a browser

Roundcube is a window into the mailbox on my server. It does not automatically retrieve my iCloud history. Thunderbird can connect to both servers, which makes it useful as a bridge between them.

I did not need to develop a new webmail application. The existing mail service already supported the connections I needed. Hestia documents its mail accounts and webmail options.

You can use Thunderbird without leaving iCloud

My first step was connecting Thunderbird to iCloud while leaving the existing hosting in place.

For the manual setup, Apple's incoming server is imap.mail.me.com, using port 993 with SSL/TLS. Its outgoing server is smtp.mail.me.com, using port 587 with STARTTLS. I used my iCloud Mail address to authenticate and kept my custom-domain address as the sending identity.

The password caused an early snag. My usual Apple Account password was not the password required for this connection. I generated an app-specific password in my Apple Account settings and used it in Thunderbird. See Apple's current server settings and app-specific password instructions.

This is also a useful stopping point if you only want a different email app. You can keep iCloud hosting and use Thunderbird. Moving the hosting is a separate decision.

Check the destination before copying anything

I inspected the mailbox on my Hestia server before making changes. It already held 1,873 Inbox messages and 122 Sent messages, plus a Spam folder.

That older mail mattered. I wanted to preserve it, not replace it with an empty mailbox or overwrite it during migration.

I made a server-side backup of the existing mailbox, checked that the archive could be listed and recorded its checksum. That was a precaution before copying; it was not a full restore rehearsal or a replacement for an ongoing backup plan.

I also found two problems with browser access:

• webmail.example.com had no DNS record.
• The mail certificate had expired.

Adding the missing DNS record made the server reachable. Renewing the certificate through Hestia restored a valid HTTPS certificate. Those were separate fixes: a correct DNS record does not repair an expired certificate.

My mail and webmail records point to the VPS and use Cloudflare's DNS only setting. I kept Apple's mail-delivery records in place while preparing the destination.

Add Hestia as a second Thunderbird account

I kept the working iCloud account and added the Hestia mailbox separately.

For my Hestia connection, I used:

Setting	Incoming mail	Outgoing mail
Server	mail.example.com	mail.example.com
Protocol	IMAP	SMTP
Port	993	587
Security	SSL/TLS	STARTTLS
Authentication	Normal password	Normal password
Username	Full mailbox address	Full mailbox address

The password here is the Hestia mailbox password, separate from the Apple app-specific password. If you follow this process, use your own server hostname and verify its connection details in Hestia.

I gave the accounts clear names so I could tell which server I was using. That turned out to be especially important.

Copy the messages, then verify the destination

I created a folder called iCloudMigration under the Hestia account. In Thunderbird, the intended action was:

1. Open the iCloud Inbox.
2. Select the messages in that folder.
3. Right-click and choose Copy To.
4. Select the migration folder under Hestia.
5. Wait for the upload, then inspect the results in Roundcube.

I used Copy, keeping the source messages in iCloud.

The first attempt exposed a mistake: I had copied the old Hestia Inbox into the migration folder. A server-side comparison found 1,873 identical messages and no new message contents. Seeing a populated destination folder was not proof that I had copied from the right account.

After selecting the correct source, the migration folder grew by 1,391 messages. I also copied the iCloud Sent folder into a separate iCloudSent folder, where the server reported 18 messages.

Those are observed folder counts, not a claim that every item is a unique migrated message. The migration folder still included the earlier duplicate copy. I kept the folders separate for review rather than immediately merging everything into Inbox and Sent.

I checked the copied mail in the destination. For a larger migration, I would also compare every source and destination folder and check representative messages and attachments. A local download finishing is not, by itself, proof of a complete server-to-server copy.

Prepare outgoing authentication before changing incoming delivery

Before switching the MX records, I prepared the DNS records used to authenticate outgoing mail.

• SPF specifies which servers may send mail for the domain.
• DKIM lets the receiving server verify a signature on the message.
• DMARC checks alignment with the visible sender domain and publishes a policy for failures.

During the transition, I edited the existing SPF record to authorise both iCloud and my VPS. I did not add a second SPF record for the same domain.

For illustration, a transition record can look like this:

v=spf1 ip4:YOUR_SERVER_IPV4 include:icloud.com ~all

Replace the placeholder with the real sending IP and account for any other legitimate senders. This is a pattern to adapt, not a record to paste unchanged.

I retrieved the DKIM record from Hestia and published it at the selector Hestia actually uses: mail._domainkey. An older public key was sitting at a different DNS name; it was not a substitute for the configured selector. Always use the key generated for your server.

Then I sent a message from Roundcube to Gmail and opened Gmail's Show original view. The result was SPF PASS, DKIM PASS and DMARC PASS. That confirmed authentication for this test message; it does not guarantee every future message will land in an Inbox.

Switch new delivery with the MX record

Only after the copy and outgoing test did I switch incoming delivery.

I replaced the root domain's iCloud MX records with an MX record pointing to mail.example.com. I left the separate development subdomain's mail routing alone.

During the change, one iCloud MX record was still present at the same priority as the Hestia record. That could allow delivery to either provider. I removed the remaining Apple MX record and checked Cloudflare's authoritative DNS again.

A fresh message from Gmail then appeared in the Hestia Inbox through Roundcube. Outgoing delivery and incoming delivery had both been tested.

Keep the old mailbox available during the transition

At the time of writing, Hestia is receiving new mail, and the copied history is available in its migration folders. The final removal of the domain from iCloud is still pending. I have not claimed a completed archive deduplication, a mobile-app setup or a newly built synchronisation app.

I am leaving iCloud accessible during an observation period so I can catch messages sent using cached DNS information. I am using 48 hours as a practical check-in point, not as a guarantee that every DNS cache everywhere has expired. The final check is whether anything is still arriving at the old mailbox and whether the destination has the messages I need.

After that check, I can stop using the domain in iCloud, revoke the migration app password when it is no longer needed and remove obsolete Apple DNS authorisations after reviewing other senders. Apple's domain-removal guide explains the effect on all addresses using the domain.

Running my own mail also means owning certificate renewals, security updates, disk space, spam handling, delivery problems and backups. A working migration test is the start of that responsibility.

Questions I had before starting

Will changing the server settings bring my old mail across?

No. Connect both accounts and copy the messages separately. Changing the MX record changes where new messages are delivered; it does not move the archive.

Can I keep my custom email address?

Yes. I kept [email protected] because I control the domain. This does not turn an @icloud.com address into a self-hosted address.

Do I need Horde, SquirrelMail or a new email app?

I used Roundcube, which was already configured on my Hestia server, alongside Thunderbird. Once a message is stored in that server mailbox, those clients can access it through the appropriate connection.

Did I build a sync app?

No. For this migration I used Thunderbird's IMAP copying and checked the destination on the server. An automated migration tool may be useful for larger jobs, but it was not part of the result described here.

The address stayed the same. What changed was where the mail lives—and how deliberately I checked each step before letting go of the old provider.