Go Ahead, Run Your Own Mail Server!

What, Are You Chicken?

I have a confession to make. In the year 2025, I’m still running my own mail server.

I’ve been an internet nerd for a long time (My first link was a 1200 baud Hayes, IYKYK), and for the majority of that time I’ve run my own mail server. First it was on a SunOS-based Sparc 10, then on a Solaris server, followed by OpenBSD, and for many years now on Linux. For the vast majority of those years, a common refrain has echoed across the newsgroups and social media: “If you run your own mail server, you’re crazy.” This refrain is grounded in reality - there’s a number of well-documented reasons to not run one. It’s difficult. It costs more than free email elsewhere. You will never hope to match the security and reliability of Google or Microsoft’s global systems and their thousands of full-time, round-the-clock security staff.

Stay tuned, though - if you're early in your career and want to learn cybersecurity, or even later in your career and enjoy a fun challenge, I think running a mail server has some real benefits nobody is telling you about.

Cybersecurity is not an entry-level job.

It’s a common complaint on social media today: “Where are all the entry-level cybersecurity jobs we were promised?” While I can’t speak to the promises that have been made, I have an answer: They were always only half of the story. The truth is that you can take classes, get training, and learn cybersecurity skills, but cybersecurity as a field isn’t entry-level. You have to know how things work to be a good Security Engineer. That means learning how systems interact with one another, not just in isolation. Understanding how systems connect to the network, how they authorize, how they work, and how they fail is all key to really being able to prioritize and implement effective security for those systems.

What does this have to do with mail servers?  Well, quite a lot. The missing link in the entry-level cybersecurity job conundrum is how to get the experience in understanding complex systems without having the job first? The answer: you run some complex systems. Running a mail server is a great way to put a lot of basic system administration, network administration, and security skills into practice. A mail server that can send, receive, and give you (and only you) access to your email is a complex interdependent system. Add on the requirement “only the email I want to receive,” and you’ve tacked on a ton of other layers!

The Basics:   Let’s take a look at the various protocols, RFCs, and layers involved in running a mail server.

  1. Operating Security fundamentals.
  1. You need a foundation before building the house, so you must install, manage, and secure the OS.
  1. Networking fundamentals (RFC# 791, 768, 9293, 1122, 1123)
  1. Email is a connected system. You’ll need to learn how to put your operating system online, configure it correctly, and keep it available.
  1. DNS (RFC# 1034, 1035)
  1.  How will people contact you via email? By memorizing your IP address? You need to learn the DNS basics.
  1. SMTP  (RFC# 5321, 5322, 2045, 2046, 2047, 2048, 2049)
  1. The heart of the beast. You’ll need to learn how it works as you set things up.
  1. IMAP or POP (RFC# 9051, 9590, 9738)
  1. Just receiving and sending emails isn’t any good if you can’t read them. You’ll need a way to download it to a client, serve it over the web, or otherwise interact with it.

Beyond the Basics: Getting it up and running is only the beginning. To make it secure and reliable, you get to play with a whole bunch of other things!

  1. SPF, DMARC, and DKIM (RFC# 7208, 6376, 7489 and 2505 for kicks)
  1. Once you have your email server sending email, you’ll likely find out that not many people want to accept it from you. Their logic goes - any server that’s not known-trustworthy is probably a spam engine. To earn some trust, you need to go back and learn more about how SPF (Sender Policy Framework), DMARC (Domain-based Message Authentication, Reporting, and Conformance), and DKIM (Domain Key Identified Mail) work. This is going to require some more advanced DNS work. Special thanks here to learndmarc.com (with whom I have no affiliation) for being a GREAT resource to trial-and-error your way through to the correct setup.
  1. Firewall policy (RFC# 2979, 7288, 3093)
  1. That shiny new server you’ve got on the internet won’t be lasting long unless you start implementing some host and/or network-based firewalls!
  1. Identity and Authorization (RFC# 6749, 6750, 7636)
  1. A simple username and password might work for a little while. You’re eventually going to have more authentication needs, especially if you let a friend or family member use your domain. You get to look into OAUTH, second factors, etc.

By my count (OK, that’s a lie, I made Gemini ‘Deep Research’ count for me, but I did double-check its work), you’re already looking at becoming more intimately familiar with 20+ full-fledged internet RFCs just to get this thing running reliably. And if you want to use webmail, you’re going to start getting into Web RFCs too - another huge bucket.

Putting skin in the game

A key feature of running an mail server is that you need to use it and rely on it for your email and, if you’re bold, the email your friends and family members (or that nonprofit you help out) depend on.

Home labs are great, but one drawback they have is that they’re experimental labs. You blow them away and start fresh when the experiment is over, or life gets busy and you abandon them. What most people don’t do with home labs is let them acquire shortcuts and technical debt. The kind of shortcuts and technical debt that accrue when some change needs to be made because things aren’t working, and you’re in a rush because you have a competing personal or professional deadline, and you need to ‘just get it up now and come back to it later’.

If you have email that really depends on your own server, you have to get it working again. You can’t just put it away until you feel like playing some more. When you need your email back NOW and you just want to get it working again, what kinds of problems are you going to cause for “future you?” That kind of technical debt is the kind of thing you’re going to be in charge of discovering and fixing a lot later in your career, and the best way I’ve found to get comfortable with it is to just do it.

Knowing how to build is knowing how to break. Also, compassion is key.

A special note for red-teamers and offensive security folks:  Sure, your career path right now doesn’t foresee a lot of operations work or running infrastructure, so why would you need to learn to run a mail server? It’s because knowing how to build something is knowing how to break it. After you’ve accumulated some technical debt (see above) and know where ALL of your own skeletons are buried, what are the odds other mail admins have skeletons lying in the same places? Pretty good.  It’s hard for me to think that it’s a bad idea to become more intimately familiar with your attack surfaces.

Also, a completely intangible but still important benefit to red-teamers of running your a mail server - especially in your earlier career phases - is that it helps you build compassion for how hard this stuff is to create and tie together. The internet is one massive interconnected system held together by duct tape and baling wire. Blue teamers are doing their best to secure everything and get it right. While offsec is a key part of helping us discover where that needs to improve, I’ve been guilty in the past of feeling superior and pointing an organisation’s  “dumb” or “bad” security builds.

I’m often asked by folks who want to get into security as a field (see above, it’s not an entry-level job) what I look for in a good security engineer. Here’s my secret: I look at lots of things, but one of them is whether that person has done any stints as a helpdesk person or a system administrator. Because the most senior of all senior skills in security, after learning how everything works, is learning why everything works that way. The answer is that someone had requirements, and they had constraints.  The combination of requirements and constraints is how they ended up with the imperfect thing they’re running, and the more experience you can get solving those two problems, the closer to ready you are for doing it in security when the stakes are higher than ever before.

So: Go ahead, run your own mail server. What, are you chicken?

(This post is a blog-form version of a presentation I gave to SANS Pen-Test HackFest in 2014. It was not recorded, so a blog post will have to do.)