Selecting the Stack Link to heading
This series begins with replacing Gmail using a fully self-hosted mail system on AWS. The goal is not just email independence — it is learning real infrastructure, security, and operational ownership.
This post explains the selected stack, what alternatives were considered, and why these choices were made.
TL;DR - Final Stack Overview Link to heading
- Hosting: Amazon EC2 (1-year Reserved Instance)
- Mail Server: iRedMail
- Mail Client: Mozilla Thunderbird
- Domain Registrar: Namecheap
- DNS Provider: Namecheap DNS
Keep reading if you want to know about the comparisons made in order to reach to these final verdicts.
Hosting Link to heading
I have a pretty good experience in working with AWS from my day job, so I didn’t pick any other cloud provider for this. Tbh, you can find pretty decent pricing on Linode, Digital Ocean etc. (I am not getting paid) if you are not comfortable with AWS. It’s just about setting up a cloud VM :upside_down:
Q. Why EC2? Link to heading
EC2 gives:
- Full OS control (Ubuntu/Debian)
- Root access
- Network control (security groups)
- Elastic IP support
- Reverse DNS configuration
- Snapshots for backups
For a mail server, full control is important. For learning purposes it’s best to manually configure things at first and later one might move onto a managed solution like Elastic Beanstalk / EKS.
Q. Why Reserved Instance (1 year)? Link to heading
Given that I’m pretty committed to this step iml… So, I’ll be using it for a while and thus 1 year seems reasonable. Also, Mail servers are:
- Long-running
- Stable workloads
- Not bursty
Reserved Instances will reduce my cloud costs significantly compared to on-demand pricing.
Q. Why Not Alternatives? Link to heading
| Alternative | Why Not Chosen |
|---|---|
| Lightsail | Simpler, but less flexible networking and scaling control |
| ECS / Kubernetes | Overkill for stateful mail servers (but might return to this in future) |
| Serverless | Not suitable for persistent SMTP services |
| Self-hosting at home | No static IP. Not resilient. ISP routers can be hard to setup. |
EC2 looks the right choise for control and saving costs.
Mail Server Link to heading
Note that there are a lot of options to choosing a mail server. I went with something that is configurable enough without overwhelming me with options as my goal through this series is to also learn about mail protocols and SMTP communication.
Q. Why iRedMail? Link to heading
Because it sits between two extremes:
- Too simple: Mail-in-a-Box.
- Too complex: Manually configuring Postfix + Dovecot + Rspamd + OpenDKIM
iRedMail also provides:
- Structured setup
- Standard components
- Clean Linux-based deployment
- Minimal abstraction
- No forced Docker dependency
…making it easier to learn without unnecessary complexity.
Q. Why Not Mailcow? Link to heading
Mailcow is Docker-based and powerful. However:
- It adds container orchestration layer
- and more moving parts for a beginner project
For this series, I have focused on clarity over abstraction.
Q. Why Not Fully Manual Setup? Link to heading
As mentioned, mail servers can be very complex with a lot of things ranging from communications with protocols and setting up custom spam filters. iRedMail allows learning the components gradually without starting from zero.
Mail Client Link to heading
Why Thunderbird? Link to heading
- Back in my college days, I switched to ubuntu full time and had a good hands-on experience with Thunderbird since then. As a matter of fact it’s UI is actually good and wayyy less buggier than outlook. (WHY MICROSOFTT!!??)
- Thunderbird also supports both the protocols for mail retrieval i.e. IMAP & POP3
Q. Why Not Webmail Only? Link to heading
Webmail is included (Roundcube via iRedMail), but:
- Having a desktop client is just convenient as it also offers better offline support
- Clear separation between server and client layers
Domain & DNS Link to heading
Q. Why Namecheap? Link to heading
I already bought my domains from namecheap and find the deals pretty affordable especially with newly registered domains. For this series only, I will be setting up my MX records pointing to the EC2 instance IP to setup my mail server.
Again, I am not endorsing buying domains on namecheap, (I have heard complaints about the malpractices they have been doing with their domains) it’s just I bought my domains over there already and it offers a decent enough experience to setup the DNS records peacefully.
Q. Ok, so what are the alternatives? Link to heading
- Well, you could surely go with Route53, to manage your domain within the AWS hosted zones, making it easier for you to manage
- Or you can pick Cloudflare. Domain hosting is also good I’ve heard, though some people have complained about the support seems to have some problems
- GoDadddy provides good offers to get started but then they have been known for increasing domain prices over the years and difficulty in transferring their domain off of their platforms.
Closing Notes Link to heading
With this stack defined, we can start to dive into the practical stuff. There are a couple more things we will be working with up ahead like setting up SPF and DKIM records in order to provide an authentic way for us to send out mail messages (else, we could easily get marked as spammed by gmail bots). This also includes setting up our own spam filters and blacklists (for which we will be using Apache SpamAssassin)… But more on that later.
If you like it, and would like to follow along, subscribe to the RSS feed here