Stalwart Mail Server: Modern Self-Hosted Email That Handles Everything

Self-hosting email is simultaneously one of the most rewarding and most punishing things you can do as a self-hoster. On the rewarding side, you get total sovereignty over your communications — no provider scanning your messages, no account lockouts, no terms of service changes that upend your workflow. On the punishing side, email is a federated protocol where your reputation is guilty until proven innocent, and a single misconfigured DNS record can send every outbound message straight to spam.

Photo by Daniel Forsman on Unsplash

If you've weighed those trade-offs and decided to go ahead anyway, Stalwart Mail Server is the strongest option available in 2026 for most self-hosters. This guide walks through what makes it different, how to deploy it, and — just as importantly — the challenges you'll face regardless of which software you choose.

Why Stalwart?

Stalwart is a mail server written in Rust that bundles SMTP, IMAP, JMAP, and a web admin interface into a single binary. In a landscape where most mail server solutions are either decades-old C codebases duct-taped together (Postfix + Dovecot) or multi-container Docker stacks that consume gigabytes of RAM, Stalwart takes a fundamentally different approach.

One process handles everything: accepting inbound mail, delivering outbound mail, serving mail to your clients, filtering spam, signing messages with DKIM, and letting you manage it all through a web UI. No coordinating between Postfix, Dovecot, Rspamd, and a webmail frontend. No wondering which container broke when mail stops flowing.

That architectural simplicity matters for self-hosters because email is the one service where downtime and misconfiguration have real consequences. Fewer moving parts means fewer things that can silently break.

Stalwart vs the Competition

Before diving into the setup, here's how Stalwart compares to the other major self-hosted email options:

When to Choose Stalwart

Choose Stalwart if you want a modern, resource-efficient mail server that handles SMTP, IMAP, and JMAP in a single process. It's ideal if you're a single user or small team, you prefer managing one service instead of a Docker stack, and you want features like full-text search and JMAP without bolting on extra components. The built-in spam filter, web admin, and automatic DKIM signing mean you can get a fully functional mail server running with minimal configuration.

Stalwart is also the best choice if you want JMAP — the modern, JSON-based email protocol that's faster and more efficient than IMAP for mobile clients and web apps. No other self-hosted option supports it.

When to Choose Mailcow

Choose Mailcow if you need a complete groupware platform — shared calendars, contacts, and a webmail interface — for a team or organization. SOGo gives you Exchange-like functionality for multiple users, and Rspamd provides battle-tested spam filtering with a rich web UI for tuning. The trade-off is 4-6 GB of RAM and a stack of Docker containers that all need to stay healthy. If you're running email for a small business with 5-50 users who need more than just send/receive, Mailcow is the right tool.

When to Choose Mail-in-a-Box

Choose Mail-in-a-Box if you're new to self-hosted email and want the easiest possible setup. The one-command installer handles everything, including DNS configuration, and the result is a working mail server with webmail. The catch: it needs a dedicated Ubuntu server (it won't play nice sharing resources), you can't easily customize the stack, and the underlying components (Postfix, Dovecot, SpamAssassin) are older. Think of it as a great learning tool and a solid personal mail server, but not something you'd scale up.

When to Choose Maddy

Choose Maddy if you're a minimalist who wants the smallest possible footprint and is comfortable with config-file-only administration. Maddy's Go-based single binary is even lighter than Stalwart, but it lacks a web admin, JMAP support, and full-text search. It's a good fit for single-user setups where you're comfortable editing config files and don't need a web interface.

Installation with Docker Compose

While Stalwart can run as a standalone binary, Docker Compose is the most practical approach for self-hosters who want easy backups and reproducible deployments.

Create a directory for your mail server:

mkdir -p /opt/stalwart && cd /opt/stalwart

Create your docker-compose.yml:

services:
  stalwart:
    image: stalwartlabs/mail-server:latest
    container_name: stalwart-mail
    hostname: mail.yourdomain.com
    restart: unless-stopped
    ports:
      - "25:25"       # SMTP (inbound mail from other servers)
      - "143:143"     # IMAP (plaintext, STARTTLS)
      - "993:993"     # IMAPS (implicit TLS)
      - "465:465"     # SMTP submission (implicit TLS)
      - "587:587"     # SMTP submission (STARTTLS)
      - "8080:8080"   # Web admin + JMAP
    volumes:
      - ./data:/opt/stalwart-mail
    environment:
      - STALWART_HOSTNAME=mail.yourdomain.com

Start it up:

docker compose up -d

On first launch, Stalwart creates its configuration files and a default admin account. Check the logs for the initial admin credentials:

docker compose logs stalwart | grep -i "admin"

Navigate to http://your-server-ip:8080 to access the web admin. The first thing you should do is change the admin password and configure TLS — either by providing your own certificates or enabling the built-in ACME (Let's Encrypt) integration.

Configuring TLS with ACME

In the web admin under Settings > TLS, enable ACME and set the hostname to mail.yourdomain.com. Stalwart will automatically obtain and renew Let's Encrypt certificates. Make sure port 443 is reachable if you're using HTTP-01 challenge, or configure DNS-01 challenge for Cloudflare or other providers.

Adding Your First Domain and Account

In the web admin:

1. Go to Settings > Domains and add your domain (e.g., yourdomain.com)
2. Go to Accounts and create your first user account
3. Configure your email client with the IMAP/SMTP credentials

Your server hostname for both IMAP and SMTP should be mail.yourdomain.com. Use port 993 for IMAPS and port 465 for SMTP submission with implicit TLS.

Core Features

JMAP Support

JMAP (JSON Meta Application Protocol) is the modern successor to IMAP, designed for web and mobile email clients. Instead of IMAP's stateful, command-based protocol, JMAP uses JSON over HTTP — making it faster, more bandwidth-efficient, and easier to implement correctly.

Stalwart's JMAP endpoint is served on the same port as the web admin (8080 by default, or 443 if you configure TLS). Clients like the JMAP plugin for Thunderbird can connect directly. JMAP also supports push notifications, so your mobile client can receive near-instant email alerts without polling.

Built-in Spam Filtering

Stalwart includes a spam filter with a Bayesian classifier, DNS blocklists, and Sieve-based filtering rules. Out of the box, it checks:

• DNS blocklists (DNSBL) against known spam sources
• SPF, DKIM, and DMARC validation on all inbound messages
• Bayesian classification that learns from your spam/ham training
• Header and content analysis for common spam patterns

You can customize filtering behavior through Sieve scripts in the web admin. Sieve is a standard email filtering language that lets you write rules like:

require ["fileinto", "reject"];

# Move messages failing DMARC to spam
if header :contains "X-DMARC-Result" "fail" {
    fileinto "Spam";
    stop;
}

# Reject messages from known bad senders
if address :is :from "[email protected]" {
    reject "Unwanted sender";
    stop;
}

The spam filter is effective for most personal and small-team use cases. It won't match Rspamd's sophistication out of the box, but it improves over time as the Bayesian classifier learns from your mail.

DKIM, SPF, and DMARC

Stalwart handles all three email authentication protocols natively:

• DKIM signing — Stalwart automatically generates DKIM keys and signs all outbound messages. You can retrieve the DNS record to publish from the web admin under your domain settings.
• SPF validation — Inbound messages are checked against the sender's SPF record. You'll need to publish your own SPF record (covered in DNS setup below).
• DMARC validation — Inbound messages are validated against the sender's DMARC policy. You'll publish your own DMARC record to tell receivers how to handle unauthenticated mail from your domain.

Additionally, Stalwart supports ARC (Authenticated Received Chain) for preserving authentication results across forwarding, and MTA-STS for enforcing TLS on inbound connections.

Web Admin

The web admin interface lets you manage domains, accounts, aliases, DKIM keys, spam filter settings, and server configuration without editing config files. It's functional rather than flashy — you won't mistake it for a SaaS product — but it covers all the essentials and saves you from the config-file-only approach of Maddy or raw Postfix/Dovecot setups.

Full-Text Search

Stalwart includes built-in full-text search across all messages. Unlike Mailcow, which requires a separate Solr container for search, Stalwart indexes messages internally. This means your users can search message bodies, not just subjects and senders, without adding another service to your stack.

DNS Configuration

Email is entirely dependent on correct DNS records. Get any of these wrong and your mail won't arrive, won't be trusted, or both.

MX Record

The MX record tells other mail servers where to deliver mail for your domain:

yourdomain.com.  IN  MX  10  mail.yourdomain.com.

A and AAAA Records

Point your mail server hostname at your server's IP:

mail.yourdomain.com.  IN  A      203.0.113.10
mail.yourdomain.com.  IN  AAAA   2001:db8::1

SPF Record

Declares which servers are authorized to send mail for your domain:

yourdomain.com.  IN  TXT  "v=spf1 a:mail.yourdomain.com -all"

The -all (hard fail) tells receivers to reject mail from any server not listed. Some guides recommend ~all (soft fail) during testing, which is fine temporarily, but switch to -all once you've confirmed everything works.

DKIM Record

Stalwart generates DKIM keys automatically. Retrieve the public key from the web admin (under your domain's settings) and publish it as a TXT record:

stalwart._domainkey.yourdomain.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

The selector name (e.g., stalwart) and public key value come from Stalwart's generated configuration.

DMARC Record

Tells receivers what to do with messages that fail SPF and DKIM checks:

_dmarc.yourdomain.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1"

Start with p=none while monitoring, move to p=quarantine, then p=reject once you're confident your setup is correct. The rua address receives aggregate reports about authentication results — useful for catching misconfigurations.

Reverse DNS (PTR Record)

Your server's IP address must have a PTR record that resolves back to your mail server hostname. This isn't a DNS record you set in your domain registrar — it's configured through your VPS provider's control panel.

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

Many receiving servers will reject mail outright if the sending IP's reverse DNS doesn't match the HELO hostname. This is non-negotiable.

MTA-STS (Optional but Recommended)

MTA-STS tells other servers to require TLS when delivering mail to you. Create a file at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.yourdomain.com
max_age: 604800

And add a DNS record:

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260213"

Resource Requirements

Stalwart idles at roughly 100-150 MB of RAM for a single-user setup, which is remarkably efficient compared to Mailcow's 2-4 GB idle footprint. The disk requirement depends entirely on your mail volume — plan for growth and set up log rotation early.

For a VPS, expect to pay $5-10/month for a personal setup (providers like Hetzner, DigitalOcean, or Vultr). Make sure to check your chosen provider's IP reputation before committing — some IP ranges are heavily polluted by previous abuse.

Honest Limitations

Self-hosted email has challenges that no software can solve for you. Stalwart is excellent software, but you need to go in with open eyes.

Email Deliverability Is the Real Problem

The hardest part of self-hosted email isn't the software — it's convincing Gmail, Outlook, and Yahoo that your server is legitimate. Major providers are increasingly hostile to small senders, and a brand-new IP address with no sending history starts with essentially zero reputation.

Your perfectly configured Stalwart instance can have flawless SPF, DKIM, and DMARC records and still land in Gmail's spam folder for weeks while you build reputation. This is frustrating, but it's the reality of the modern email landscape.

IP Reputation Is Out of Your Control

If your VPS IP was previously used for spam (common with cheaper providers), you inherit that reputation. Tools like MXToolbox Blacklist Check can tell you if your IP is on any blocklists, but delisting can take time. Some self-hosters go through multiple IPs before finding a clean one.

Stalwart Is a Relatively New Project

Stalwart has matured rapidly, but it's still younger than battle-tested stacks like Postfix/Dovecot. The community is growing but smaller than Mailcow's or Mail-in-a-Box's. Documentation covers the common cases well but has gaps in edge cases. If you hit a niche problem, you may be on your own.

This isn't a reason to avoid Stalwart — the code quality is high and the development pace is impressive — but it's worth knowing that you might occasionally hit uncharted territory.

No Built-in Webmail or Groupware

Stalwart handles the server side of email but doesn't include webmail (like Roundcube or SOGo) or groupware (calendars, contacts). If you need browser-based email access, you'll want to deploy a separate webmail client. Roundcube is the most common choice and pairs well with Stalwart over IMAP.

Learning Curve

Even though Stalwart simplifies the software side, email infrastructure has an inherent learning curve. You'll need to understand DNS record types, TLS certificate management, email authentication protocols, and deliverability best practices. The web admin makes day-to-day management easier, but the initial setup requires understanding what you're doing and why.

Practical Tips for Success

Start with a Relay for Outbound Mail

The most practical approach for new self-hosted email setups: use your Stalwart server for inbound mail, but relay outbound mail through a transactional email service like Amazon SES, Resend, or Mailgun. This gives you self-hosted privacy for receiving mail while piggybacking on the relay's established IP reputation for sending.

Configure Stalwart to use an SMTP relay in the web admin under Settings > SMTP > Outbound. Once your IP has built enough reputation (usually 4-8 weeks of clean sending), you can switch to direct delivery.

Warm Up Your IP Gradually

If you do send directly from your IP, don't start by blasting 500 emails. Begin with a handful of messages per day to addresses you control (Gmail, Outlook, Yahoo). Check that they arrive in the inbox, not spam. Gradually increase volume over 2-4 weeks.

Sign up for Google Postmaster Tools and Microsoft SNDS to monitor how these major providers view your sending reputation.

Test Your Setup

Before relying on your mail server for anything important, test it thoroughly:

• mail-tester.com — Send a test message and get a deliverability score
• MXToolbox — Verify DNS records, check blacklists, test SMTP
• DMARC Analyzer — Monitor DMARC reports

Aim for a 10/10 score on mail-tester before considering your setup production-ready.

Set Up a Backup MX

If your primary mail server goes down, a backup MX ensures you don't lose incoming messages. You can use a cheap VPS running a minimal Stalwart or Postfix instance as a secondary MX that holds mail until your primary comes back online. This is optional for personal use but worth considering if you rely on your email.

Back Up Everything

Your mail data lives in the Stalwart data directory (/opt/stalwart-mail inside the container). Back this up regularly — losing your email archive is not something you want to experience. A simple cron job with rsync to a second server or an object storage service works well.

Don't forget to back up your DKIM private keys separately. If you lose them, you'll need to generate new keys and update your DNS records, which can temporarily break your outbound email authentication.

Monitor Your Server

At minimum, monitor that ports 25, 993, and 465 are responding, that your TLS certificates haven't expired, and that your disk isn't filling up with logs or mail. Tools like Uptime Kuma or a simple health check script can alert you before problems affect your email.

Resources

• Stalwart official documentation — Comprehensive setup and configuration guides
• Stalwart GitHub repository — Source code, issues, and discussions
• Stalwart Docker Hub — Container images
• learndmarc.com — Interactive tool for understanding DMARC, SPF, and DKIM
• mail-tester.com — Test your mail server's deliverability score
• MXToolbox — DNS lookup, blacklist check, and SMTP diagnostics
• Google Postmaster Tools — Monitor Gmail's view of your sending reputation
• Sieve language specification — Reference for writing email filter rules

Final Thought

Stalwart is the best self-hosted mail server available in 2026 for most individual and small-team use cases. It brings a modern architecture, efficient resource usage, and protocol support (especially JMAP) that no other option matches. But no software can solve the fundamental challenges of self-hosted email — IP reputation, deliverability to major providers, and the ongoing responsibility of being your own email administrator.

Start with a relay for outbound mail, test extensively before going live, and keep a fallback plan. Self-hosted email is a marathon, not a sprint. The first week of configuring DNS records and watching mail-tester scores is the easy part. The real commitment is the months and years of keeping your server running, your reputation clean, and your mail flowing reliably.