tl:dr; I’m going to tell you all the reasons you shouldn’t run your own mail server.

I actually wanted to name this post “Thinking about running your own mail server? Here is why this is a bad idea” but I’d like for everyone to opt out of click bait titles. I stopped clicking on anything that sounds like click bait (Youtube, Twitter, News) as my brain got trained to see those as low quality time stealers.

Anyway, I wanted to talk about my experience of running a mail server. Over the last 10+ years I’ve operated my own mail server on VMs hosted by netcup.de. (Not a paid ad, I promise) Their servers have decent performance and for just a few euros they are a steal.

So I went and setup ispconfig – a management interface for basic web, mail and dns servers – to have a more simpler interface for configuration. Till Brehm (the maintainer of ispconfig) is doing an amazing job at developing that piece of software over the last decade. The interface is clean, neat and gives your customers basic settings to do self service if they want to.

Configuring a mail server is complex

Configuring your mail server is more than a couple configuration files. Its also very reliant on a clean and proper DNS configuration. You need to fulfill a few basic requirements for your emails to get delivered:

• A SMTP, IMAP and MTA systems
• A proper stable DNS setup (ideally with DNSSEC)
• SPF – a DNS record of what IPs/mail servers are allowed to send emails under your domain
• DKIM – automatic signatures for all your sent emails, so other mail servers can verify the messages originated from a trusted source
• DMARC – get reports of misuse of your mail services
• Rate limiting – don’t let your users send too many emails
• Monitoring – it happens from time to time that your mail server gets blacklisted

So just installing ispconfig on your VM is certainly not going to get you all of the above. In fact all you get out of the box is the first point: a SMTP and IMAP server. The rest needs tedious manual config file adaption and looking through various other tools which can automate this work away.

SMTP, IMAP and MTA

Quick intro to how email works: Your mail client connects to the SMTP server. SMTP is the protocol used to submit new emails for sending. The MTA then accepts those messages and forwards it to the receivers MTA. The receiving MTA checks its configuration to find the right IMAP account to store the email in. Your mail client connects to this IMAP account to view any stored emails.
(don’t quote me on the correctness of this)

Email is one of the oldest protocols on the internet. One of the earliest versions has been specified in RFC 561 in 1973. The software we have today is equally as old and brittle. Over the years developers have added bits and pieces to support newer features like virus scanning and server side filtering. But none of the available open source systems are the easiest to configure.

No wonder with how feature packed those are nowadays:

I admit, not all are pure mail servers and deliver much more value like a webmail interface. But this greatly visualizes the complexity such programs already have. Usually those tools can only do subsets of the tasks of SMTP, MTA or IMAP.

So for our use case of manually running our services we need to wire up Dovecot (as IMAP server), Postfix (as MTA/SMTP), sieve for server side filtering (which needs to interface with postifx) and amavis (for spam filtering) with a little bit of ClamAV (for virus scanning).

True, there are solutions out there that bundle all of this into single binaries. This might be convenient because configuration is easier but will usually come as closed source and with a price tag (per user).

Is your brain hurting yet? Cullum Smith has a great blog article on how to run to do such a setup. Do I recommend it? NO! Hell no! Why? Well because if you got this far, you still haven’t checked all the other things so your mail actually gets delivered to other domains. Did I mention Backups yet?

Your DNS setup probably sucks

There is this joke I first heard when I started to look more into becoming a Site Reliability Engineer that when you are investigating an outage that “it is always DNS”. In reality I’ve fallen into this trap several times, where I’ve looked at the server and running services. Everything seemed to work, but somehow the DNS got jammed up. Of course its the last thing I checked. (Got monitoring for your DNS? Of course you do!)

DNS is a simple text protocol (ha!, just like email) that is the heart of the internet. Sure we could use IP addresses to connect to systems, but those change frequently (because IPv6 is still not a thing) and nobody can be expected to remember a bunch of numbers.

The reason why DNS is hard, because we rely on it in such a fundamental way. It’s reliability is key to enable everything else to work. To increase the performance of DNS servers we have master/slave setups and anycast IPs. Are you planning on just setting up a DNS server on your one VM? Well, you are going to have a really bad time.

Latency is probably going to be high and there is no fallback with use one nameserver. You probably want to use multiple nameservers that are scattered throughout the world. No, your registrar (the site you “buy” the domain) is probably not going to give you such a setup.

Alright, then you use a hosted service from Google Cloud DNS, Cloudns or Route53. Well good thinking, those vendors probably have the capacity to have a decent setup of servers throughout the world. But now you are trusting other entities with your DNS records and that they replicated them accurately throughout the world. Oh, you don’t trust them? You are using DNSSEC? Great!

How do you rotate the DNSSEC keys? Cause those also expire. Oh, and of course your registrar does not offer an API to change the DS records. Of course you have monitoring for this as well.

/rant – As you can probably tell, running your own DNS is already a superbly big challenge. Even if you get your server’s setup 100% correct, chances are you are going to fail at DNS at some point. Make sure to check out Dan’s presentation about other challenges in DNS land and how he solved them at eGym. DNS today is superbly complex and if you can avoid it, please don’t ever run “apt install bind9”.

SPF / DKIM

Email in general is highly reliant on a few special DNS entries to establish trust between parties that don’t know each other.

The sender policy framework (SPF) is a simple DNS entry that controls which mail servers are allowed to send emails for a particular domain. In most cases you just want your MX server to be able to send emails, so you’d be good with:

v=spf1 mx ~all

This will make anything that is not sent from a valid MX DNS entry usually be handled as spam on the receiving MTA. (But not all MTAs verify SPF records) Sounds simple right?

DKIM on the other hand adds signatures to every email that leaves your server. Your keys need to be also saved in a DNS record. I’ve used opendkim in the past, but the setup is also tedious and another extra step for each domain that I want to use.

Without SPF and DKIM you can probably forget to ever land in anyone’s inbox these days. Your email will in most cases be classified as spam and will not be read by many people. In some cases I’ve even seen other mail server just rejecting my mail because of a misconfiguration. (Which is absolutely the right thing to do – don’t get me wrong)

I haven’t even mentioned DANE did I?

Summary

The whole challenge in email is that its a distributed system where each part is controlled by different entities. You can setup your own domain / server in the best possible way and take all the precautions. (Trust me, you’ll fail more than once)

Chances are high that your email will still land in spam folders.

You will have to deal with the misconfiguration of other MTAs, Microsoft’s special handling of blacklisting and many other Email Blacklists out there (RBLs).

The standards are old and the software mostly cobbled together. Therefore you will have to implement a multitude of them to get decent delivery rates and not get swamped by spam. Of course don’t forget to add TLS to all your services, because we actually want transport to also be encrypted because nobody is using end to end encryption for mails.

I’ve been failing over the last ten years at getting my setup to a point where I’m completely happy with it. The time spent was significant (several weeks worth) and the results were at best mediocre.

So in order to no longer have to deal with this mess, I’ve finally bought G Suite and am migrating most of my users over. Initial impressions are decent and it has most settings I’ve needed in the past years.

So long postfix, dovecot and ispconfig thanks for all the mails!