I have read for years that it is just not worth it to host your own email. I have understood this. I have believed this.

Recent changes in Google's policy have me considering moving away Gmail and even Google Workspace. I already only use it for the email feature - I use Immich, Nextcloud, Vaultwarden, etc. I use a combination of self hosted in the home and on self managed cloud servers (can't really have Uptime Kuma on the home network to tell me if the home network based services go down, for example).

I researched other email providers. I didn't like what I saw or the prices you would get per user.

So I decided I would just try and see if I could make it work to host it myself. I found Stalwart and got that going on a cloud server. It has a setting to link right into the Cloudflare API and add all the records it needed. It was way easier than I expected. The IP I got for the server was clean on spamhaus and everywhere I checked. Once I got everything set up, I sent some emails to test. They all arrived. They passed SPF,DKIM,DMARC. Stalwart has cardDAV/calDAV. Scored 10/10 on mail-tester. Shows up even to my Outlook inbox for my work email (now that was filtered to spam but so is everything that isn't whitelisted by IT).

Everything is hardened and access is locked down behind cloudflare. I have bichon running to back up everything from Gmail/Workspace now. I did this all on a separate subdomain for testing.

Am I an idiot? What am I missing that is going to blindside me on this? Is the other shoe going to drop? Why should I not just full send it and move over to my shiny new selfhosted email provider?

Talk me down off this cliff here because I am already in my swimsuit and the water down there looks inviting.

Heads up for anyone running Ubuntu on their self-hosted boxes.

CVE-2026-98432 is a use-after-free in the kernel's IPv4 TCP code (inet_opt / ireq_opt get freed before the RCU grace period ends). Ubuntu rates it High with a CVSS of 9.8. Red Hat's bulletin says a remote, unauthenticated attacker could win the race condition and get code execution. Neither Ubuntu nor Red Hat says it is being exploited yet.

The annoying part: as of Ubuntu's last update on Oct 30, every supported LTS is listed as "vulnerable, work in progress". There is no fixed linux package yet for 22.04, 24.04 or 26.04, so a normal apt upgrade won't fix it this time. 20.04 and older are simply listed as vulnerable.

Red Hat has published a temporary nftables mitigation that drops incoming IPv4 TCP packets that carry IP options. The core of it is:

ip protocol tcp ip hdrlength > 5 counter drop

They are clear that it reduces exposure but does not fully prevent it, and that a kernel update is the only complete fix. The full rule file and the command to remove it after patching are in their bulletin. IP options are rare in normal traffic, but I would still test it on one box before rolling it out everywhere.

Quick checks while we wait:

uname -r

apt list --upgradable 2>/dev/null | grep linux-image

For those of you with services exposed to the internet: are you applying the nftables workaround now, or just watching the Ubuntu tracker and patching when the kernel lands?

Sources:

- Ubuntu CVE tracker: https://ubuntu.com/security/CVE-2026-98432

- Red Hat RHSB-2026-016 (with the mitigation): https://access.redhat.com/security/vulnerabilities/RHSB-2026-016

(Drafted with AI help. The facts are from the Ubuntu and Red Hat pages linked above.)