Stalwart: Self-Hosting Your Own Email Server (and Why You Probably Shouldn't)

Every couple of years I get the itch to run my own mail server. I quash it, because every couple of years I remember what running a mail server is actually like: a Postfix config you don’t dare touch, a Dovecot setup nobody documented, Rspamd bolted on the side, and a Sunday afternoon vanished into SASL authentication errors. And then, the first time you email someone at a big provider, you land in spam anyway.

So when I tell you that the technical experience of self-hosting email has genuinely become pleasant, hold two thoughts at once. It has. And you still probably shouldn’t.

1 What Stalwart actually is

Stalwart is a modern, all-in-one mail server written in Rust. The pitch is that it collapses the traditional “mail zoo” — separate daemons for SMTP, IMAP/POP3, and spam filtering — into a single binary you can run as one container.

Out of the box it gives you:

• An SMTP server for sending and receiving.
• IMAP4 and POP3 for clients, plus JMAP, the modern JSON-based protocol that the better mail apps now speak.
• Built-in spam and phishing filtering, so no separate Rspamd.
• Native handling of DKIM, SPF, DMARC, ARC and MTA-STS rather than three more packages glued together.
• A web admin interface, so you’re not editing five config files by hand to add a user.

The contrast with the old stack is the whole point. Instead of wiring Postfix to Dovecot to Rspamd and praying the sockets line up, you run one thing, you configure it in one place, and the parts are designed to talk to each other. For a tinkerer, that alone is reason enough to spin it up on a weekend.

2 Getting it running

The container route is the path of least resistance. A minimal Compose file looks like this:

services:
  stalwart:
    image: stalwartlabs/mail-server:latest
    container_name: stalwart
    restart: unless-stopped
    ports:
      - "25:25"     # SMTP (inbound mail from the world)
      - "465:465"   # SMTP submission (implicit TLS)
      - "587:587"   # SMTP submission (STARTTLS)
      - "143:143"   # IMAP
      - "993:993"   # IMAP over TLS
      - "8080:8080" # web admin
    volumes:
      - ./stalwart:/opt/stalwart-mail

First boot prints an admin password to the logs; you finish setup in the web UI — adding your domain, creating accounts, and letting it generate a DKIM key. That part really is a few minutes of clicking. If only the rest of email were as kind.

3 The bit nobody can make easy

Here is where the honesty starts. The software is the simple part; the internet’s distrust of new mail senders is the hard part, and no binary fixes it.

To stand any chance of being delivered, you need all of the following correct, and any one of them being wrong will sink you:

• A static IP with clean reputation. Mail providers judge you by your IP before they read a byte of your message. If your IP was previously used by a spammer, you inherit their sins.
• Reverse DNS (PTR). The PTR record for your IP must resolve to your mail hostname, and that hostname must resolve back. No PTR, no delivery — many servers reject you outright.
• Port 25 open and outbound. Most residential ISPs and a lot of cloud providers block port 25 by default to fight botnets. No port 25, no sending. You often have to request it be unblocked, and the answer is frequently no.
• SPF, DKIM, DMARC and MTA-STS published correctly in DNS.

The DNS side looks roughly like this:

; Mail routing
mail.example.com.    IN  A     203.0.113.10
example.com.         IN  MX 10 mail.example.com.

; SPF — only this host may send for the domain
example.com.         IN  TXT   "v=spf1 mx -all"

; DKIM — public key generated by Stalwart (selector "default")
default._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSq...IDAQAB"

; DMARC — quarantine failures, send reports
_dmarc.example.com.  IN  TXT   "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

And the PTR record, set on the IP side by whoever controls the reverse zone (usually your provider):

10.113.0.203.in-addr.arpa. IN PTR mail.example.com.

Get all of that perfect and you have earned the right to be treated as a suspicious unknown. New sending domains and IPs start with no reputation, which the big filters treat as guilty until proven innocent. You warm up slowly, you watch your DMARC reports, and you accept that for the first weeks your mail to large providers may sit in spam through no fault of your own.

4 Why you probably shouldn’t

I run a lot of things I shouldn’t, so understand the spirit in which I say this: for most people, self-hosting outbound mail is the wrong call.

The deliverability problem never fully goes away. You can do everything right and still be collateral damage on a shared blocklist, or get throttled because a neighbouring IP in your provider’s range misbehaved. Reputation is maintained forever, not set up once.

Then there’s the uptime burden. Mail is not a service you can let fall over for a day. If your server is down when someone emails you, the sender’s server retries for a while and then gives up — and you never learn the message existed. Backups, certificate renewal, security patching, monitoring: this is now your job, indefinitely.

For most people the pragmatic answer is one of two things. Pay for a mailbox from a provider whose entire business is keeping their IPs trusted. Or, if you want to host your own inbox for control and privacy, send through an authenticated SMTP relay — let a reputable relay carry the outbound reputation while Stalwart handles your storage, filtering and clients. You keep the fun parts and outsource the unwinnable fight.

5 Where it does make sense

Self-hosting mail earns its keep when control is the actual requirement, not the hobby. If you have a static IP with a genuinely clean, established reputation, your volume is low and predictable, and you treat the relay route as a perfectly respectable option, Stalwart is a delight to run. It’s also a brilliant lab: standing it up taught me more about how email really works than a decade of using it.

Just go in clear-eyed. The server is no longer the hard part. Convincing the rest of the internet to trust you still is — and it always will be.