I self-hosted my own email for a year, and it's the one project I'll never try again

Published Oct 4, 2026, 5:00 PM EDT Shekhar Vaidya is a veteran technology journalist and computer science engineer. He is the founder of TechLatest, where he has spent years providing technical analysis on hardware and Windows ecosystems. Now a Computing Writer at XDA, Shekhar leverages his deep background in NAS, storage solutions, and PC internals to help readers master their tech. You have a working homelab. It already replaced many of your cloud services with self-hosted alternatives, and then you go after one of the last ones. I did the same. From Google Drive and Apple iCloud to Bitwarden Premium and NextDNS, I ditched almost everything for free alternatives via my homelab. And when everything worked in my favor, I aimed big. I tried to replace my Google Workspace with a self-hosted mail server. Spoiler alert: it didn’t work the way I expected. Getting a mail server online is its own project Port 25 was open. My ISP had other plans. I already had a good homelab setup. My internet was good enough, and I already had a public IP address. So, I assumed a mail server on my home Debian server would work like the rest of the services. I started by searching for the best self-hosted mail server on tech forums, and the most recommended one was Mailcow. I took everyone’s word as is and decided to move ahead with Mailcow. But as soon as I opened Mailcow’s documentation and saw the minimum system resources, I immediately reversed the decision. The minimum memory requirement listed in the docs was 6 GB + 1 GB swap, and my whole server was running on 12 GB of memory with more than 20 services. I took a quick look at the forum threads again, and after going through each one’s review and requirements, I landed on Stalwart. Their documentation mentioned that for 5 to 10 users, 1 GB of memory is more than enough to run Stalwart comfortably. For a mail server to work, the basic first network requirement is outbound and inbound TCP connections on port 25, so I quickly ran netcat and verified that it was already open from my ISP’s side. I was good to go. I deployed Stalwart and ran the setup wizard; it was all good till then. When I got to the DNS and mail identity, I noticed the PTR requirement. A PTR record is a reverse DNS record that ties my IP address to a hostname, so mail providers like Gmail and Outlook can verify the legitimacy of the setup. On a home internet connection, the PTR record is managed by the ISP itself. When I checked my IP with nslookup, it returned "non-existent domain," which means no reverse DNS record at all. So, I contacted my ISP to set one for me; they declined. And my plan to host my own email server started to disappear, and then I thought of hosting it on a cheap, small VPS. Hetzner said yes in minutes. The catch came later. I had already been using VPSs for various other projects, so I thought, why not add another cheap one to host the email server? A new server on my existing Hetzner account took a couple of minutes. This time I wanted to check all the requirements before deploying anything. So, I started by opening outgoing traffic on ports 25 and 465, but it turned out Hetzner blocks them by default. After going through the documentation, I found out why. Both ports were blocked to prevent email spammers from using their cloud hosting. Each account needed a manual request to unblock those ports. So, I put in a manual request to unblock them, and fortunately, it was unblocked in a few minutes because my account was old and it had many paid invoices. After that, everything went in my favor. I deployed Stalwart on the VPS via Docker Compose, ran the setup wizard, did all the basic configuration, and finally completed the setup with seven DNS records, four firewall rules, the port unblock, the Let's Encrypt certificate, one mailbox, and a postmaster alias. All the steps were simple enough since I was already familiar with these parts. The certificate did take a few more manual steps because I kept the DNS management manual. I had to issue the certificate with acme.sh and a scoped Cloudflare token. I didn’t worry about the recurring VPS bill because I was already using multiple Google Workspace seats at $8.40/user/month, and the VPS was costing only $4.99/month. So, in my mind, I was hoping for a substantial saving over Google Workspace if Stalwart works. Then I sent my first email. Stalwart Individual pricing Free and open source (Community Edition) Developer(s) Stalwart Labs Stalwart is an open-source mail and collaboration server written in Rust. It supports SMTP, IMAP, POP3, and JMAP, along with CalDAV, CardDAV, and WebDAV, and runs self-hosted, including as a Docker container, with a built-in web admin interface. Platform(s) Self-hosted (Docker) Everything passed, and one provider still said no Proton and Outlook said yes. Google said spam. I assumed gathering the minimum requirements and setting up the mail server was the tough part, and since they were done, everything would work seamlessly, but my assumptions fell apart almost immediately. I logged in using my new email address on Thunderbird and started with new test emails to my existing accounts from providers like Gmail, Outlook, and Proton. I sent similar emails to each one of them. Google marked it spam in the first attempt, whereas both Outlook and Proton Mail considered it legitimate and delivered it to the Inbox. Since two out of three major providers accepted it as normal, I marked the Gmail email as “Report not spam” and moved to a fail and restore test (explained in the later section). After the test, I tried sending another email to my Workspace address, and it again marked it as spam. Since it failed to reach the Inbox again, I decided to dig deeper. I started by checking each provider’s received message headers. Gmail and Proton successfully validated the RSA DKIM signature, while their handling of the additional Ed25519 signature differed. That wasn't enough to explain Gmail's spam classification, because the RSA signature was valid and DMARC still passed. Whereas Outlook passed the same checks, plus Microsoft's composite auth (compauth=pass), and ignored Ed25519 as an unsupported signature algorithm. This discovery made me go deeper since Gmail and Proton failed Ed25519, but only one of them marked the email as spam. I checked the VPS IP against MXToolbox and found no listings across the public blocklists it checked, including Spamhaus ZEN. That ruled out an obvious public blocklist problem, but it didn't prove the IP had a good reputation with Gmail. Google maintains its own sender-reputation systems, and a fresh domain or low-volume VPS IP can still have little or no reputation. In the end, I never figured out why Gmail marked it as spam, and since Google didn’t expose any other information, it was not worth digging further. Now, zooming out from the individual tests, the situation did improve over the next few months, but there were more issues that led to letting go of the idea of self-hosting a mail server. Setup was the easy part. Staying alive is the job. The restore worked. It also ate an email. Apart from deliverability, there were a few more things that I faced along the way. The first and most important thing was actually using it on a day-to-day basis. With Gmail, Outlook, or any other email provider, what we do is either use their app or log in to the web client in a browser. But in Stalwart’s case, there is neither. There is no traditional way to log in to my mail account and use it. There is no dedicated app or webmail client, at least in the version I ran (0.16.24). I have to use a third-party app like Thunderbird or existing apps from other providers to log in. And the login process isn’t as simple as you think; in both apps I tried, I had to use the IMAP server details along with the usual email ID and password. Once you are logged in, you are good to go, but you can’t just open a browser and log in on someone else's laptop and send an email; you will need a third party with custom IMAP support. There are third-party webmail options, but self-hosting would be another dependency, and hosted ones defeat the point. As I always say, hosting a service isn’t a big deal; keeping it up and running is the main task. And for a mail server, it is a non-negotiable requirement. It is supposed to run 24/7; if it is down for a few moments and someone sends an email at the same time, it may or may not be received. I actually ran a test for the same thing. I deliberately took down the Docker container and sent an email to my self-hosted address while it was down. The good part was that I received the email, but 20-25 minutes after the container was up, Gmail tried again. So, in my test, it depended on the sender’s retry policy. Even though restore worked perfectly, the backup was older and didn’t have the new emails, so restoring wiped the new messages from my server. And the email client dropped the message in the next sync. Finally, coming to the cost part. As mentioned earlier, I was already using paid Google Workspace emails, so a $5 VPS felt cheap, but if I'd only been using free Gmail, then the VPS recurring bill would have felt like an additional expense. The screenshots are from a separate test mail server I deployed for this article. They are not from the original server I used for my longer-term email hosting experience. The bill I chose to keep Some projects teach you how to build something; others teach you that you don't want to own it. After facing various walls like email deliverability, no webmail client, the responsibility of managing the mail server 24/7, and the maintenance, I decided to stay with my paid Google Workspace and accept the extra bill each month. At least by paying a little bit extra, I can let go of the burden of running email. Stalwart itself isn’t the problem. It is no doubt an easy-to-deploy mail server. If you are ready to own that responsibility, it is something to take a look at.