Photo by Samuel Zeller on Unsplash
You have some sort of application that has to deliver email. You are also a tech savvy person who believes in the ?email is decentralised? mantra so you decide to self-host a mail server yourself. Not so fast. In the following paragraphs I will try to summarise what I have learnt and what it is like to self-host a mail server in 2019.
It all started a month ago when I launched a small community-driven tech newsletter. The newsletter application consisted of a simple static website and a simple backend for dealing with subscriptions and email deliveries. Deploying to production I had to configure the application?s SMTP settings so I googled about the most recent trends.
Almost every article I read stated:
Self-hosting a mail server is hard, better use some Cloud/SaaS solution.
Why is it hard though? No arguments on that. I decided to give it a shot.
After a short research I started a Postfix instance in a docker container. A few hours later I successfully configured my domain to work with the SMTP server and sent a test email. It arrived in the SPAM folder of my Gmail account.
Lesson #1: Running your own mail server is easy. What is hard is to configure it correctly.
The first thing I instantly noticed was that my email was delivered unencrypted.
Gmail warns me that the email was not encrypted.
I quickly fixed that with a certificate provided by Let?s Encrypt. There are a lot of step-by-step tutorials on the topic. Now my emails are encrypted but are still classified as Spam.
I decided to quit the guesswork and a few minutes later I arrived at this helpful page. Here is a quick checklist of what you need to do in order to pass the Spam classification when delivering to Gmail:
- Static IP
- Reverse DNS on your IP address that points to the domain you use for sending emails
- Confirmation email before adding to subscription list
- Unsubscribe link
1, 6, 7 were already done on my side. I continued with the configuration of my mail server with DKIM, SPF and DMARC. Apart from the DNS records there is also a decent amount of configuration that has to be done on the server-side.
Lesson #2: A usable mail server needs a carefully designed architecture, maintenance and continuous awareness of the most recent security and content practices.
At this point I decided to check for some community driven mail server (architecture) projects because it requires a lot of knowledge and effort to run a usable mail server. My requirements were the following:
- Popular and regularly maintained
- Easy to setup
I quickly arrived at the following solutions:
- Mail-in-a-Box ? it isn?t Dockerized and you need a dedicated server or VM in order not to pollute your environment with whatnot. It might be easy to run in a custom docker container but I prefer an officially supported solution.
- Mailu ? it is Dockerized and well-documented but in my opinion not easy to setup. I expect a docker-compose up to be enough so I can check up a demo of the project. After some issues with networking and certificates I decided to move on.
- Mailcow ? Dockerized, popular, well-documented and easy to install. I managed to get up and running in less than 30 minutes. The project provides a neat admin UI, as well as a nice looking mailboxes for your domain accounts. Mailcow also guided me how to correctly setup my DNS records. It is just awesome! (P.S. I?m not affiliated in any way with Mailcow)
I was ready to send another test email. Fingers crossed ? BOOM! My email arrived at the Spam folder once again. The only thing I hadn?t done from the checklist was the Reverse DNS. My ISP refused to add a Reverse DNS record to my IP address that points to my domain. I was compliant with everything but this and there was nothing I could do about it.
At this point I decided to follow the recommendation to just use some cloud mail delivery service.
I checked out the most popular services and decided to give Amazon SES a try. It worked perfectly. However I quickly realised that I need to use their other cloud services in order to be able not only to send but also to receive emails.
Lesson #3: Even paid mail transport services have downsides which you need to consider.
I continued digging the self-hosted mail server topic. Let?s assume you even have a Reverse DNS record setup on your IP address. Is there anything else that can stop you? Yes ? there is :). Your IP address might be included in one or more Spam blacklists which many email providers take into account when assessing your emails. Most of them incorporate a process for unbanning IP addresses but this might take some time and communication.
Other things to keep in mind when self-hosting a mail server:
- Your mail server?s IP address is ALWAYS exposed and you cannot do anything about it. This is the way emails work. If you host you application on the same server even behind Cloudflare or other proxy, you can easily become a victim of a DoS/DDoS attack.
- Setting up a Spam filter on your mail server can prevent malicious uses of your MTA which can result in your IP address being blacklisted.
Final lesson: Mail servers are stable. Once you go through all the hassle, you can relax and enjoy your setup.
In conclusion my personal feeling about self-hosting a mail server is positive. Setting up a self-hosted mail server for a volume of a few hundred emails a month is not only an overhead but also will cost more than using some mail service provider. However for big volumes I would definitely walk the extra mile with the self-hosting way.