WHAT IS THIS?
This post is like most of my other posts – a documented journey and a kind of ‘how to’ manual.
Scenario: I have a paid email server for a company I have shut down. I don’t want to pay every month for this premium email but I also don’t want to shut down my email addresses in case I decide to re-open the business later. The idea is to use a cheap web-host hosting Stalwart to keep the email somewhat functional.
This post could probably also be used as a template workflow for any other email server (ie. Mailcow -another great open source email server project) migration by modifying accordingly, especially the basic flow in the “Pre-Planning” section below. It’s a ‘how to move’ or ‘how to migrate’ post, in short.
Usual disclaimer. I’m not any kind of pro. Adjust everything and anything however you like. Just sharing my own journey and hope it helps someone else somehow.
MY SETUP
- My DNS is hosted at Cloudflare
- My Stalwart is hosted on an Ubuntu server. More on that journey here if you’re interested
- Ubuntu laptop
- Thunderbird email client
PRE-PLANNING
The problem with doing these kind of exercises is you always wonder what to do first and all that. Thankfully, I was able to create this list after having a few things go wrong so that you can benefit and get it right the first time (or at least more right). Here is the summary list – and in this order (order matters in this game):
- Step 1: Backup email accounts
- Step 2: Assure website domain is pointed to Cloudflare (and propagated)
- Step 3: Assure current MX records (for the email) are in CloudFlare and working with current email provider
- Step 4: Add domain to Stalwart Server
- Step 5: Add ACME SSL Certs to Domain
- Step 6: Add Required email addresses to Stalwart
- Step 7: Get the required DNS records from Stalwart for this domain to enter into Cloudflare
- Step 8: Send out any last minute ‘maintenance warnings’ to whoever needs it
- Step 9: Add DNS records from Stalwart into Cloudflare
- Step 10: Remove Old Email Server DNS records
- Step 11: Await Full Propagation
- Step 12: Update Email Server Settings in Email Client while waiting for propagation to complete
- Step 13: Send Some Test Emails
Hope this will work, now let’s begin each step with a section…
Oh, wait. There is one more TIP I wanted to add before we start. At some point below you’ll need to add the passwords for each of the email accounts. If you aren’t using a password manager like Keepass then you should start because it will make that job so much easier. But the main point here is that when you hit big Step 6 below, you’ll need to add the passwords for each email account. If you want them to be the same as what they are now, you better have them near you, or, be ready to provide the newly-updated passwords to anyone who needs them, perhaps even in advance. There you go.
Now let’s really begin.
Step 1: Backup email accounts
This one is important. I actually didn’t do this – on my first rodeo – and just continued on and as soon as I switched the DNS records (switched servers officially) my inbox was wiped (of course) because the IMAP started immediately synchronizing my empty server with my full inbox to empty because empty is the newest status.
Thankfully for me, propagation hadn’t completed so I was able to quickly reconnect to the old server and re-download all the content. So back up your emails if you want to be safe, is my point.
This backup process will assume you are using Thunderbird, like me. You’ll have to adjust the tutorial accordingly if not.
In Thunderbird:
- On the left pane, locate ‘Local Folders’ header (it has a slightly different icon).
- Create a new folder by right clicking on Local Folders and selecting “New Folder”. I named mine
2026-IDName-DomainName-backupwhere ‘2026’ is the year I’m in now, IDName is the first part of the email address before the @ and DomainName is your emails domainname. - Mirror any sub-directories you want to backup. You may not wish to back up, for example, your trash or sent items, but if you do, right click on the main local directory you just created/named and select ‘New Subfolder’ and give it a name like ‘sent items’ or ‘trash’ etc.
Now you have a mirrored inbox of all the stuff you want to backup and we will move the contents of your soon-to-disappear email accounts into these local folders
- In your main, currently-live inbox, click and highlight just one email, and then hit ‘Control + A”. This will select/highlight all the items in your entire inbox
- Very (very, very) carefully, click and drag the emails into your new LOCAL directory folder(s) that you created in steps 1, 2, and 3 above accordingly. The emails will all move together and start loading into the new local folder. This does not happen quickly, especially if you did your whole inbox because it starts deleting them from the server and copying them over to these directories. It might even take hours depending on how fat your inbox / directory is, so budget your time accordingly if you plan to sit and watch the process. TIP: I would suggest you try drag-dropping a few emails first, perhaps even one at a time, to get used to the feel of how Thunderbird works in this way and the location of your target directory so that you don’t accidentally drag and drop your whole inbox into a random location. One mistake and you could have a serious headache. Go slow. Be sure on this step.
- Repeat for any other directory (such as sent items) until you have completed all directories you want to save.
Your original inbox and all it’s sub-directories (that you wish to keep) should now be empty and all your emails should be in the newly-created local folders.
- Confirm they are in fact in the new folders you created by going there and looking.
If everything is all backed up into the local folders, proceed. Note: if any emails come in between now and the end of this process, just manually drag/drop them individually into the appropriate directories.
Step 2: Assure website domain is pointed to Cloudflare (and propagated)
Search your own tutorial on this, lots of resources out there. Sorry about that.
Step 3: Assure current MX records (for the email) are in CloudFlare and working with current email provider
Search your own tutorial on this again. Sorry.
Step 4: Add domain to Stalwart Server
In Stalwart admin:
- go to
manage/directory/domainsand simply hit the ‘Create Domain’ button - Enter the domain name in full into the domain field (ie. example.com)
- Hit the ‘Save changes’ button
Step 5: Add ACME SSL Certs to Domain
If you don’t do this you will get immediate TLS certificate warning messages in your email client. Happened to me. You simply must have certificates for email to work these days…
In Stalwart admin:
- Go to
settings/acme/(which is hidden under TLS header if you can’t find) - Directory ID | name it something memorable, usually something like example cert for a domain like example.com is fine
- Challenge: TLS-ALPN | (leave it)
- Contact email: Add one (gets notifaictions)
- Subject names: Add your Stalwart
mail.yourdomain.comfrom whatever Stalwart automatically pumps out for your CNAME domain in the zone file - Save changes
- Wait about 1 minute then Open it again with ‘edit’ and assure there are some blanked-out private details in the Account key field at bottom. Save and exit
Step 6: Add Required email addresses to Stalwart
In Stalwart admin:
- Go to
manage/directory/accounts - Click ‘Create account’ button
- Add email address number 1 (ie. info@example.com) as the ‘Login name’ field. I suppose this could be different from the email, but easier to use the email address in my opinion
- Enter the ‘from’ name (ie. John Doe) into the “Name” field.
- Enter the email address in full (again) into the “Email” field
- Go to ‘Authentication’ tab
- Enter your password for this email account (the one you want the user to enter into their email client when they log in / connect)
- Adjust any other advanced settings you might want in the other settings in Stalwart.
- Click ‘Save Changes’ button
- Repeat steps 2-9 for each email address you need to set up for this domain.
Step 7: Get the required DNS records from Stalwart for this domain to enter into Cloudflare
In Stalwart admin:
- Go back to:
manage/directory/domains - Click the hamburger icon and select “DNS Records” option
- Here is both the individual records (which you can post into Cloudflare individually) and the Zonefile. Sadly I don’t think you can just import them all into Cloudflare and if you can – AI lied to me (boo hoo) and let me know in the comments, kindly.
Step 8: Send out any last minute ‘maintenance warnings’ to whoever needs it
Self explanatory. You are about to switch email servers and things could go wrong. You may not receive emails nor be able to send them for whatever unknown reason. Even if you do it right there might be propagation delays. Sending an email is a wise courtesy if your emails are active and any stakeholders need to know.
TIP! Don’t forget any aliases or forwarded email accounts! For example, I had an ex-business partner’s email forwarding to my main one which I almost forgot since it was not a direct inbox in my email client. I needed to re-create that one too and re-forward it (again) on new server. Actually, there is an ‘alias’ feature in Stalwart under each account. You could research that and do that perhaps? Anyways, consider forwarding email accounts!
Step 9: Add DNS records from Stalwart into Cloudflare
In Stalwart, get this on your screen again: manage/directory/domains
Then, in a new tab in your browser, log into your Cloudflare admin and:
- Select your domain (if it’s not there you’ll need to add it, so search how elsewhere if you don’t know)
- Select “DNS” and “Records” from the side panel to get into your DNS records for your domain
- Insert, manually, all the Stalwart records you need with a minimum of the MX and SPF records but as many as you want / need for this generation.
TIP: Make sure the ‘proxy cloud’ is switched off from orange to grey in all these.
I did the following records just as an FYI and don’t know if I even need them all (there are more too):
MX | mydomain.com
TXT | “v=spf1 (spf)
TXT | 202601r._domainkey (DKIM)
202601e._domainkey (DKIM)
CNAME | autoconfig
CNAME | mail
CNAME | autodiscover
TXT | _dmarc
TXT | _smtp._tls
Step 10: Remove Old Email Server DNS records
- Back up your old DNS records into a simple text file so that, if you need it for some reason, they are easy to find and copy/paste back in again if required.
- Delete your other email servers DNS records (the ones only that are associated with your old email service provider) from Cloudflare (typically MX, SPF, DMARC, etc), but be sure at least to delete the MX record so the change starts propagating right away.
TIP: I thought I had deleted the old Cloudflare MX record the first time but in fact I had not hit the red “Delete” button which was hidden on my screen. I had only cleared the fields, thinking that it was deleted. Be sure to actually delete the record and double check it is deleted because I had two servers confusing each other for a while because of this mix up.
Step 11: Await Full Propagation
When you delete your old one, and insert the new Stalwart records, the DNS servers of the world will still have the old one cached for a while – until they don’t. For this reason do not cancel your original email service until propagation has fully completed (probably best to wait 48 hours to be sure), if your email service matters at all to you. Because we have not yet changed the server settings in your email client, the first ‘clue’ that your propagation is getting close is likely when your own email client starts to fail. At that point, you can start using the dig command to see a bit more accurately how the rest of the world is viewing your DNS records. In my case, I saw both my old server and my new one for a period of time (which apparently is normal). From your ubuntu terminal, run this command replacing your domain into example.com of course:
dig example.com MX
Once you see (only) the new Stalwart server, propagation is mostly complete. If your email is working, great, but again, probably not wise to cancel your current provider until it’s all confirmed working. You can proceed to update your email client to see if you can force email to work on your new Stalwart server, but just remember that your propagation is still not complete – until it is – and you have no power over this. Use the dig command above to check in throughout the day.
Step 12: Update Email Server Settings in Email Client while waiting for propagation to complete
In my case I’m using the ol’ trusty Thunderbird.
In Thunderbird:
- From the left-most pane / panel, select your target email account (top entry / email account)
- Click ‘edit SMTP server’ button
- Change the server to your CNAME server name that you entered into Cloudflare.
Note: If you only have one domain associated with your email server, then they might be the same but in my case I have a random domain for Stalwart (just to host the server) which is the MX record for all my domains. You will need to make sure it’s the one you can get from Big Step 5 above, probably ‘mail.yourdomain.com’. - Assuming you have the exact same password in your old server as your new one, you can click ‘save’ otherwise adjust password too
- Under your main header in the side panel, select “Server Settings”
- Paste in new server (ie. mail.yourdomain.com) into the ‘Server name’ field
- Click anywhere else such as the main header of your email account in the left panel. This will trigger a ‘Restart is required’ warning and then click ‘restart’ to restart thunderbird with the new settings.
You will also need new certificates on Stalwart for new domain…
Step 13: Send Some Test Emails
- Send a test email from the new account to another email (hopefully far removed) and make sure it arrives
- Send a test email from an account to the new one. If it sends but doesn’t arrive, it’s probably still propagating the new server and going to the old one. If you need it, you’ll have to get it another way such as logging into a webmail email server or have another email client connect to the old server to retrieve it.
Bonus Section and Farewell
BUG: I wanted to add an interesting story of a ‘bug’ I found in Step 13 above in case this happens to be your situation. I had two domains, and both were using the same email provider, let’s call it ABC Email. After doing everything above, I was able to send emails back and forth from all emails I tested, except one – the one that was using the same email service with the same company. Emails sent to/fro failed only to that domain. Apparently this is because of the company using ‘internal routing’ for email accounts hosted on their servers and I now have to contact them to undo that (somehow). Just FYI
FAREWELL: With that said, have a great day wherever you are and I hope that some or all of this helped.