Preparing to Self-Host Email

Written By: Jake Bauer | Posted: 2020-05-15 | Last Updated: 2020-11-01

Email is one of the oldest and most fundamental underpinnings of the Inernet as a whole. Unfortunately, it has a reputation of being very difficult to self-host, let alone self-host correctly. I’ve seen many online talk about the issues they’ve run into getting their mail past the spam filters of Big Mail Corps or keeping their servers safe against the onslaught of crackers trying to gain access which eventually leads them to give up on self-hosting email and return to using proprietary services from the likes of Google or Microsoft.

Despite all this, I think self-hosting email is one of the best ways to take control of your data and become digitally independent. Regardless of which email provider you choose, there is always the possibility that they could shut down, analyze your emails and sell that data to advertisers, or block you from using their service. If you’re dependent on email (which I’m sure many of us are to a certain extent), this is something to be concerned about.

I am currently with ProtonMail. My only complaint, now that they’ve open-sourced all of their client applications, is that I have to use the ProtonMail Bridge, and therefore be a paying user, in order to be able to interact with my email using open, standard protocols like IMAP and SMTP. It’s also somewhat annoying that I have to have a separate (electron-based) application running any time I wanted to send or receive email. I understand why they do it, but it’s still something I wish I didn’t have to deal with. Besides, I’m also coming to terms with the fact that email is almost a completely public form of communication; the only way that I can be sure that my communications are secure is by using PGP-based encryption with my emails, or a separate secure messaging system like Matrix. With nearly every email passing through servers belonging to Google or Microsoft and being stored unencrypted in most others’ mailboxes, it seems an unavoidable truth.

This is the first time I’ll attempt to properly self-host email. I’ve previously set up mail communication inside my LAN and I have experience with SPF, DKIM, and DMARC, but I’ve never set up proper mail from scratch. I plan to run OpenBSD, OpenSMTPD, Dovecot, and Rspamd; OpenBSD because of its reputation for taking security very seriously and because I want to become more familiar with the BSD ecosystem, OpenSMTPD because it seems very easy to configure when compared with Postfix or Sendmail (though I know Postfix isn’t that hard from experience), Dovecot because right now it seems to be the best software available for doing what it does, and Rspamd because it’s what seems to be recommended the most alongside the other options I’ve listed.

I plan to run my mailserver using a hosted VPS because I don’t have a static IP at my house and I need more reliable infrastructure for a service as critical as email. Although this somewhat lessens my digital independence, since the VPS provider could theoretically shut down or ban me, I think it’s the best solution given my circumstances right now. I chose to go with Vultr because they’ve been highly recommended to me, they have good hosting rates, and they offer deployment of OpenBSD VPSes. Here is a referral link if you’d like to give them a try while supporting me. That link will give you a 30-day, $100 credit (if, for whatever reason, the link above doesn’t work, here is an alternative referral link which won’t give you a credit but does still reward me).

As the final component, I plan to first trial a setup using a spare domain which I own:, just in case things don’t work out well. I wouldn’t want to lose access to my current email by messing up my first time self-hosting. I am also considering using that domain permanently for personal mail if things work out since it’s slightly easier than spelling out for people, but we’ll see.

Also, here are some of the resources I’ve been reading to prepare for self-hosting email, in case you also want to give it a go:

This is my twentieth post for the #100DaysToOffload challenge. You can learn more about this challenge over at