Why I still run my own mail server
People assume the hard part is SMTP. SMTP is from 1982 and it is approximately four verbs. The hard part is everything that grew up around it afterwards.
Every few months someone tells me that running your own mail server is impossible now, that the big providers have won, and that I should stop pretending otherwise. They are about a third right, which is the most annoying proportion to be.
What is actually difficult
Receiving mail is easy. You open port 25, you accept the connection, you write the message to a maildir. I had that working in an afternoon and so could you.
Sending mail that arrives is the whole job. Nobody trusts a new IP address, and they are right not to. So you do the paperwork:
- a reverse DNS record that matches your HELO name, which means your hosting provider has to let you set one;
- SPF, so receivers know which hosts may send for the domain;
- DKIM, so the message carries a signature that survives forwarding;
- DMARC, which ties the two together and tells receivers what to do when they disagree — and, more usefully, sends you reports;
- TLS on both sides, and MTA-STS if you want to say so out loud.
None of that is intellectually hard. All of it is unforgiving. A trailing dot in a DNS record will cost you an evening, and the failure mode is not an error message — it is silence, or a folder you cannot see.
The part nobody warns you about
Reputation is not a property of your configuration. It is a property of your address, your neighbours, and time. A correctly configured server on a fresh IP still lands in spam for a few weeks, because the only evidence you have offered so far is that you exist. You fix this by sending small amounts of real mail to people who reply, and by waiting. There is no flag for it.
The other thing nobody warns you about: you are now on call. Not heroically — the server is quiet — but a disk that fills at 3am is a disk that silently stops accepting mail, and mail that bounces is gone in a way a missed web request is not. Monitor the queue, monitor the disk, and test the restore.
So why keep doing it
Three reasons, in ascending order of honesty.
One: my address is mine. If I move providers, nothing about my identity changes, because the domain is the identity and the provider is an implementation detail. That was the original design and it still works.
Two: nobody reads it, indexes it, or trains on it. My mail sits on a disk I can point at, in a country whose data protection law I can read, and the only processor involved is the company renting me the machine.
Three, and the real one: I understand mail now. Not in the way you understand something after reading about it — in the way you understand something after it has broken in front of you and you have fixed it. DNS, TLS, retry semantics, the difference between a 4xx and a 5xx and why that difference is load-bearing for the entire system. That knowledge transferred to everything else I do.
Should you?
If you want to save time or money: no. A mailbox costs a few euros a year and the people selling it are very good at it.
If you want to know how the internet actually fits together, and you can accept that the first month will be irritating: yes. Start with a domain you do not depend on. Send mail to yourself at three different providers. Read the DMARC reports — they are XML, they are ugly, and they will tell you exactly what is wrong.
The message that reached you when you wrote to me came off that server. So did the one that told you this page exists.