I still self-host, but now I cheat for deliverability: route the problematic destinations (I'm looking at you, Outlook) through Amazon SES. At a few cents for five-figure numbers of emails, it's as close to free for personal/vanity email quantities as it gets to have someone whose full time job it is to make sure outgoing mail stays deliverable on your side while still keeping everything else under your control.
One thing to note is that Amazon are not very good at keeping amazonses.com up to date, so despite including it you can't set DMARC to hard-fail SPF or you will have mail bounce days.
4 different countries, different AS.
I'm always puzzled by all the issues described by others. I had about 4 issues during these 15 years, all 4 were solved by reading the bounce message and doing what was asked in the message (contacting support of the destination).
Took about 6 months initially of fiddling to get other email services to accept mail DKIM, DMARC, SPF, PTR, web form requests
The comments (not parents') are usually very weird like people are mad at us for hosting our own mail server or something. That is really an interesting phenomenon.
For personal email, self-hosting is much more manageable. Typically GMail will send those messages to spam at first, but after a few different mailboxes have clicked “not spam” GMail learns the lesson.
If they would at least dump it in the junk mail folder, I could fix it, but no, some earlier step in the process makes it silently disappear.
For the parent post, you configure an outgoing SMTP relay
Iirc called smarthost in postfix
When sending the other side is the server, when receiving, you are the one. The protocol also has the concept of relaying, where message can go trough intermediary nodes.
So you can set one server for receiving email (yours) and another one for sending (smtpgo).
For actually reading, the server for receiving need to deliver the message (either built-in feature or through a program) to the correct mailbox. That would probably means writing it on disk somewhere. And then you need to use a mail user agent (MUA) to read that file. Protocol like imaps and pop3 are for transfering your inbox to another computer, not for receiving or delivering email.
A user's inbound mail accumulates on a mail server. One server [protocol] handles getting the user's inbound mail to that user's mail client -- usually with protocols like POP or IMAP that let the user retrieve that accumulation.
Another server handles whatever mail the user decides to send, using SMTP. Each server is configured within the user's mail client, and that's just the normal way of doing things. It's ~always been split up like this (aside from outliers like Microsoft Exchange). :)
The user doesn't have to know anything about the existence or addition of a system like smtp2go. They just configure their client to send mail through mail.orgname.com (or whatever) like usual, and the back end handles the rest. Their pop/imap server address also stays the same.
---
Anyway, mail servers and relays. Mail servers don't talk to eachother using things like POP or IMAP. The traditional Internet way for a mail server to send mail to another is to look up the recipient domain's MX (Mail eXchanger) entry in DNS, which specifies the inbound mail server, and just send it over using SMTP.
It was thus delivered. It was all very trusting.
That trust began to break when spam became a problem that never went away. Requirements and reputation and filtering became a serious ordeal for mail servers -- both on the sending and the receiving side of things.
Services like smtp2go can handle part of the sending-side trust-wizardry in a centralized way. They do things like maintain the reputation of their IP addresses.
In using it like this, orgname's server (which might very well be under someone's desk) ceases to directly connect to each and every recipient domain's MX.
It goes through smtp2go instead: All outbound mail simply gets routed through smtp2go, as the result of a central back-end configuration thing on orgname's mail server.
In email terms this is called relaying, though smtp2go might prefer the term smarthost[1].
Meanwhile, local internal mail (from joe@orgname to jill@orgname, say) can just get delivered locally. It doesn't have to be relayed at all. This determination is made by orgname's mail server.
And, again: The user doesn't need to know or care that their mail is/isn't being relayed, and the concept of relays themselves is as old as the hills. The user can just be happy that their mail gets where it needs to go instead of being silently dumped into a ditch, and they don't need to do anything different on their end for this to happen.
So frustrating because they have no legal obligation to accept our emails but our product relies on them being delivered.
I gave up and moved everyone over to SES instead.
Not sure if that's still the case
And on the deliverability side, using SES for sending avoids this entirely. Yes, ok, not fully self-hosted I suppose, but it's close enough (and for most people, the bill will be pennies).
1. IP reputation is a big deal, its not just about not being on some blocklist, call it a cartel at this point, its about being on the allow list for other mail providers
2. Keeping it reputable is a continuous effort
But I encourage everyone who likes tech and freedom to host their own email. So many reasons.
Some are pragmatic, for example that way you won't ever get locked out suddenly of your entire digital existence when google/microsoft decide to lock you out for no reason and you will never reach support capable of helping.
Some are more about taking a stand for freedom, but that's also worthwhile. The internet was not meant to be owned by just a few behemots who get to control all content. The internet is about distributed peer to peer protocols. Nothing embodies that better than everyone running their own mail server, if you can.
As many say below, if you're worried about the deliverability you can still run your own email server and have nearly all the benefits even if you use a third party relay for delivery.
That said I also deliver from my email server and it is totally fine, the fears are overhyped. Delivery to microsoft is the worst, but even that one just takes filling a form on occasions (been over a year since had to do it last time).
Never had any issues since then, though I did have to adjust to new standards such as DKIM, DMARC, SPF etc. over the years.
- Outlook.com consumer mail addresses
you can still get >99% delivery rate if you have spf, dkim and all the new cool stuff.
So no, please DO NOT recommend against doing it because ONLY if mail stays a decentralized service providers will stay forced to not blacklist everything but other large providers.
You don’t build your own fridge. If it’s important and not your strong suit, pay someone to do it for you.
In my professional life I managed email infrastructures since 20 years ago. It only got harder.
If you achieve 100% delivery rate you will surely share the results, right? No? Oh i guess all those services simply tell you they make it easier for you while not actually achieving that - but why check?
AFAIK, that case in 2019 was the only time an e-mail went missing.
No deliverability problems. The issues with self-hosting email are drastically overblown.
Yea we do all the best practices but still no one can guarantee 100% deliveries. Just not possible for e-mail.
Yes we can have 100% over a year but after that it still is a lottery, can’t say anything about future not having suddenly 40% not delivered
Just too critical of a component in most people's lives to accept any level of unknowns in.
That's cheaper than I can rent any mail-capable VPS for, and it's cheaper than the electricity I'd pay (80W @ $0.15/kWh = $316 over 3 years) to self-host.
And that doesn't include my personal-time hourly cost.
The last small-corpo email server I ran myself was a Pentium 4 box that worked for eons. It did all of the things (the spam filtering, the virus scanning, the tossing, the software RAID storage, the open internet-facing ports including the webmail) for all of the people.
But it turned out that even with dozens of users, it hardly ever saw any load. Email was a complete snoozefest for it.
I'm quite confident that an N100 box would run circles around that P4 machine using any metric, and use an average of less than 10 Watts if all it needs to do is serve mail at home.
You can certainly rent a mail-capable VPS less. Especially if you send emails through the AWS mail service. A small home server capable of hosting mail will absolutely not use 80W. It will use <10w.
- you get the vanity email address
- you can switch email providers (including self-hosting later on)
- you can have ~unlimited aliases (depends on the provider)
Most of the setup consists of steps you will have to take anyway when self-hosting (getting a domain, changing DNS records), except for a major amount of headaches that will be taken care of for you.
my backend is still dovecot+postfix, still works beautifully. I am able to run rspamd+dovecot proxy on a small vps and the storage is handled by a backend office server with dovecot. If VPS has an issue can spinup another easily/anywhere and backend is also virtualized (libvirt) so easily restored (with multiple backups in multiple places)
biggest thing to worry about with deliverability is ensuring your SPF and DKIM (opendkim) are correct, which is not too difficult and rspamd is able to handle the dkim signing/verification which is nice
"spam is solved" looks a lot different at each of those
I have decided that if my VPS provider shuts down, I can just send my outgoing mail through a cloud provider's SMTP gateway. My volume is low enough that it will be free or cost a few cents a month.
Deliverability is not a problem for me, but incoming spam does not have a great solution. Even with rspamd, a lot of crap gets through if you start spamming your email address everywhere. This is why I use a lot of throwaway and company-specific email address.
If you only have one email address, yeah Fastmail or whatever is cheap. But as soon as you want multiple users (family) and throwaway email addresses, it gets expensive in a hurry. But those are free if you self-host.
I would never run my own mail server today. Deliverability is a nightmare, despite what this article says. Gmail/Hotmail (and all the domains they host for people, which is quite a lot) will pretty much block or silently drop any email that isn't from a large, known provider who has actually talked directly to them.
If you don't have time to be a full-time mail deliverability engineer/product manager, just pay someone to do it for you.
It definitely requires some effort but once you've got it up and running it's pretty hands off. The only issues I've ever had are expiring certs but I've fixed that by configuring auto-renewals and it's all good now.
Ensuring your source IP isn't blacklisted is probably the single most important factor. I had to request a new IP from Linode where my server runs as the one it was originally assigned had a bad reputation.
Other than every smtp relay hop and any network tap along the way that could keep a copy. Hope you're encrypting and not worried about the envelope. Email is fundamentally not private. Self-hosting doesn't help all that much (though it may keep it out of certain companies' hands, aside from the emails copied to or sent from that provider)
I use dyndns to handle IP changes (incredibly rare with Frontier FIOS, actually). I use mailhop.org to handle secondary MX records in case my machine is down (as well as mail filtering) Everything else is postfix, spamassassin, dovecot imap
It's not a trivial system, and it took a while to get everything working how I wanted. It's a terrific learning opportunity, but it's by no means simple to mentally model the process of all that happens inside.
So I'm doing it now but I'm ready to switch back to one of my Colo servers at any time and I won't be surprised if I have to at some point.
> but if your home internet checks these boxes, you can 100% host your own mailserver at home:
Static IPv4 address (make sure it's not blacklisted)
Not behind a CGNAT
Ability to change the PTR record of your IP (usually though the support of your ISP)
Ability to open common mailserver Ports (25,143,465,587,993)
For normal folks, they are better off using an alternate less privileged email service like email.riamu.io.
I also run mail servers for others, mostly non-profit adjacent groups who don’t have the capital to be extorted by cloud service providers.
Sure, there are some things to learn, but like anything – if you do it properly, it’s not hard and can work properly. Never had any deliverability issues over that time (yes, even to the big providers). I also almost never touch the boxes (I do about one architectural overhaul a decade and am working on the next right now).
If you’re willing to invest the time and resources to do it properly, I agree, it works fine.
It is absolutely possible to host, use, and achieve decent deliverability with your own server. It takes work and is a different beast than running a webserver, but that frontier is not dead (yet).
At the same time: it is an ABSOLUTELY TERRIBLE IDEA to suggest that folks operate an email server out of residential IP through your ISP. The spam prevention ecosystem is so draconian now that email traffic flowing out of address ranges belonging to residential owners is yeeted into the sun. If you've operated email infrastructure at decently large scales, you know that SPF/DKIM/DMARC are just one part of how spam is identified, and mixing in the source of email traffic into the detection heuristics is a significant part of that identification process. Achieving decent delivery can often involve "warming up" an IP over time to establish its reputation, and consumer address ranges are a hodge-podge of activity that incur very little trust about what they're doing.
I agree with some commenters that exhort the exercise of self-hosting email to prevent the venerable protocol becoming a homogeneous GMail and Outlook-only world, but there are reliable ways to do this: using a VPS, relying on a company for the sending/SMTP part, or something similar. But footguns abound, and disgorging SMTP packets from your LAN edge is one of them.
There was a moment when my son was born and he was in NICU that my mail broke. I just went without for a while. Not ideal.
Since then I've thought: self hosting is nice but hosting cooperatively is probably the best way forward. Democratic control might beat technical control. I'll do it soon, I think: I'd be fascinated to know what people think.
I’m currently working on a cooperative “lights-on” solution which might be complementary.
I am running Docker Mailserver because it's one of the very few options that were actually easy to administer: https://docker-mailserver.github.io/docker-mailserver/latest...
But the last release was like a year ago: https://github.com/docker-mailserver/docker-mailserver/relea... and same with the container that was published: https://hub.docker.com/r/mailserver/docker-mailserver/tags
I guess there is the edge version and more recent commits, and overall it should be stable, but you'd think there'd be more small patch releases to decrease the eventual risk of CVEs. Either way, cool that it exists.
I don’t want to have to install packages on the host system or pollute it with configs in case I need to get rid of something or migrate the OS separately from the software. I don’t want a complex backup story, just a /data mount for all of my stuff. I also sure as hell don’t want to copy random configs or add other config management systems into the mix. I also don’t want to have to configure cgroups or resource limits per thing I’m running. I also want to be able to version the config and deploy it easily wherever needed, and sure as hell don’t want to set it up manually; Ansible is passable but less convenient than just a Docker Compose or Swarm stack. Generally, I keep the apps separate from the more bare host system.
Especially useful when you can easily tell what is transient data vs actual data you need to store longer term per-app, alongside custom port setup across all apps and not needing to care much about individual config formats, in addition to being able to run different versions alongside one another.
Nix or other methods would probably also work for folks, but Docker (OCI) containers just get out of my way and do the thing.
I use Stalwart as a mail server and it was not too hard to setup (with some caveats to get it working with my SSL certs behind a reverse proxy. But nothing a bit of LLM chatting couldn't solve). All in all, it's not 100% self hosted, but works well.
However, I don't agree with the suggestion in the article to use a self hosted LLM. My mailserver needs a few hundred MBs of RAM at max, but with the spam filter this would increase like 10x-100x.
Another good guide that uses Debian and its standard packages:
* https://workaround.org/ispmail-trixie
(Updated with every release, and upgrade/migration instructions.)
I'd recommend mailcow for regular usage, or mailinabox if you're low on RAM or configuring email for server (not for people).
I've been doing it since late 90s for several domains, servers run in DCs.
Deliverablity wasn't a problem once I set everything well (and I forwarded most, including received phishing/spam, to my big provider account), but constant fight with incoming spam and effort to keep the servers safe, secure, updated, monitored and finally paid for, weren't really worth it.
For unlimited aliases I bought the service that lets me use my domains, for smtp for servers I was using sendgrid and ses anyway.
The effort is not worth that, especially not with the powerful LLMs looking for vulnerabilities.
I can spend the time I was sinking into keeping it afloat on something more creative.
I wanted to start this discussion because I think we are prime for more self hosted mail servers in 2026 and in the post I explain how to use a locally hosted LLM to nudge the spam detector rspamd to whether or not an incoming mail is spam.
Also in times where the EU can order your mail providers to scan for unwanted content [1] (currently limited to CSAM, later probably more) it does feel better to have your data at your hand.
[1] https://en.philenews.com/international/privacy-to-end-in-the...
My reason for self-hosting is control, not privacy: the fact that the cleartext of my outbound emails is visible in the MailPace UI is not a concern; the problem I'm solving is that email providers can delete your account.
Absolutely zero maintenance has been required since I set it up (unattended upgrades), until recently when Dovecot updated the configuration syntax. Claude ported the config script to the new syntax in about 2min.
You can get a solution like SimpleLogin (don't get actual SimpleLogin, they don't do SRS) in minutes without the headache of having to configure, administer, secure and patch all that.
SMTP relays are cheap--worth a few pennies a month to not deal with IP rep.
I did test email selfhosting before and there’s a substantial amount of times my emails were never seen by the recipient, sometimes it did cost me good jobs/deals.
So now I use paid email while I control the domain and everything else, so I have the portability feature if I wanted to switch providers without any efforts, but I know now my emails will be delivered whenever I hit sent.
That being said, I self host everything else in my digital life, and I believe everyone should.
It's not worth it.
I'm not sure what privacy you gain by self hosting these days, since no one else is.
Plus there's people in Europe talking to each other that don't want the USA to read their emails. I mean there tons of situations wheee emails don't go through Google or Microsoft.
For the use case of you and your wife, you don't really need to self host a mail server, you just need a file server, unless you're forwarding each other emails you got externally, in which case, someone probably already read it.
My overall point is that email requires at least two parties to have access to the content, oftentimes more than two, and chances are one of those parties is not privacy conscious, which breaks any privacy you think you might have.
So if they self-hosted more they would t go through the USA.
And I bet now that 75% is decreasing rapidly.
But really email is not secure. It should be encrypted on the wire server to server but that's not guaranteed.
So just try hosting it yourself. It's not a big deal.
Delivery isn't the problem, just people don't use mail as much as they used to. Most people reach for signal or whatsapp to communicate. Most mail is order confirmations. So don't really care if people can't get mail, it isn't the primary communication tool for most people like it used to me.
On the other hand HDD is fine for a mail server and you can get 400Gb for not much more than some email providers will charge you for three 10Gb mailboxes.
Also check out https://jmap.io - great stuff coming to the world of open source e-mail!
Hosting your own MX (the receive side) means a lot of private emails go straight to you: purchase receipts, utility bills, travel itineraries. You can have as many users/mailboxes/aliases as you like without having to pay more. You also get confidence that emails sent to you didn’t get silently treated as spam (cloud providers have disappeared enough 2FA code emails that I really care about this).
Sending emails directly also provides some benefits. You can guarantee that the email is sent with TLS, for example. Having logs to prove that my server sent a message and it was received and acknowledged by the receiving server has been useful to me a couple of times too.
it's still doable and you get the best feeling there is: Living in the internet.
Can recommend 100%.
https://en.wikipedia.org/wiki/Hillary_Clinton_email_controve...
I pay for a perceptual license of Zimbra.
Given your advice on mailservers in a public thread would you also care to share your real world practical experience with selfhosting email?
Configuration was pretty easy. Setup SPF, DMARC, DKIM. Chose a reputable provider, checked the IP is not blacklisted anywhere(had to try a few IPs). Verified that all configuration was right.
Then when I started replying to emails, I would never hear back from the recipients. I created a Gmail account and sent an email to myself and lo and behold my reply went straight straight to spam. Despite the mail headers saying everything was checked and was fine.
I’d love to hear ideas of what I did wrong. I tripled checked SPF and DKIM. Verified IP with McToolbox, Spamhaus, etc..
Also my domain is 10+ years old and has been hosted by google and fastmail in the past and only for very low volume private emails.
I was running Postfix+Dovecot+Seive+SpamAssassin+Fail2ban+certbot+spf+dkim+reverse-ip+<other random crap>
It worked! Receiving email was overall pretty easy. I know I also did things the "hard way" by ad-hoccing all that together, and today there are a lot more out-of-the-box solutions that do all that for you. But still. Being a full-time email administrator is a job I will never do again unless I'm getting paid for it.
You know what really sucked? Deliverability. Frequently, emails I would send would just ... vanish ... no warnings, no errors, no failures. From my end, everything was perfect. Until days later, people would follow up with me and say, "Are you going to send that email?" ...
I had a business IP (Comcast Business). The IP address was clean, not black listed anywhere, not on SORBS or other lists. Still, successfully delivering an email was like 50/50, with no way to confirm the other party actually got it.