smtp4dev
Fake SMTP server for development email testing
smtp4dev is a dummy SMTP server that catches messages sent by applications and shows them in a web interface. It lets developers test email functionality without sending real mail.
Key features
- Catches outgoing email
- Web inbox viewer
- IMAP access
- API for automation
Pros & cons
Strengths
- Easy local testing
- Cross-platform
Trade-offs
- Not for real delivery
- Development use only
smtp4dev replaces
Last reviewed Sep 13, 2026 · 730 words
The single most common smtp4dev support question is "why does mail never arrive", and the answer is that it is doing its job. smtp4dev is a sink, not a relay: it accepts every message on port 25, stores it, and shows it in a web inbox. Nothing leaves. Point your staging Nextcloud or your half-built app at it and you get a safe place to see exactly what your software sends, complete with headers and HTML rendering, without ever spamming a real address.
Where it sits in a homelab
Two uses earn it a permanent container. The first is development: any app with an SMTP setting gets smtp4dev:25 while you are building, and you check the web inbox instead of a real mailbox. The second is quieter and more useful for self-hosters: every service in your stack that sends notifications (Vaultwarden invites, Nextcloud shares, Uptime Kuma alerts) can be pointed at smtp4dev first, so you can confirm the templates and recipients before switching the setting to your real provider. I have caught more than one service that would have emailed the wrong list on day one this way.
The Compose file, and the three ports that matter
services:
smtp4dev:
image: rnwood/smtp4dev:latest
ports:
- "5000:80" # web inbox
- "2525:25" # SMTP in
- "143:143" # IMAP out
volumes:
- ./smtp4dev-data:/smtp4dev
restart: unless-stopped
Inside the container the web UI listens on 80, SMTP on 25 and IMAP on 143; map them to whatever your host has free. Other containers on the same Compose network reach it as smtp4dev on port 25 directly, so the host port mapping for SMTP only matters for things running outside Docker. If an app insists on STARTTLS, smtp4dev can generate a self-signed certificate on first start, though switching the app's TLS setting off for a test host is usually simpler. The volume holds the SQLite message store; without it, every restart empties the inbox, which is sometimes exactly what you want on a build agent.
IMAP turns it into a real inbox
The IMAP listener is the feature I did not expect to care about. Add smtp4dev as an IMAP account in Thunderbird with any username and password (it does not check them by default) and the caught mail shows up like a normal mailbox, which is far better than a browser tab for reviewing 200 test messages from a bulk-send job. The REST API does the same for scripts: an integration test can send a password reset, then query the API for the message and pull the link out of the body.
Relay rules are for staging, not production
smtp4dev can forward specific messages to a real SMTP server, filtered by recipient. That is how you let a staging environment reach your own team's addresses while every customer-shaped address stays trapped. It is a convenience for a test box, not a mail architecture; if you are reading this looking for a way to actually deliver email from a homelab, that is a different and much harder problem, covered honestly in the self-hosted email post.
Mailpit is lighter, smtp4dev has more knobs
The obvious rival is Mailpit, a single Go binary that does the same catch-and-view job on a fraction of the memory. smtp4dev is a .NET application and wants about 128 MB, versus tens of megabytes for Mailpit. In exchange you get IMAP, the relay rules, and a web UI that has been polished for 10 years. If you only ever look at the last five messages, Mailpit wins on weight. If you use the IMAP path or the relay filters, smtp4dev is the one with the feature. MailHog, the older option, is effectively unmaintained and I would not start a new setup on it. The wider email category covers the real servers.
What I'd do
One smtp4dev container on the Docker network your other services share, persistent volume on, port 25 not published to the host. Every new service gets pointed at it before it gets pointed at a real provider. Thunderbird on IMAP for anything more than a glance. When the stack is stable and you are only doing occasional checks, swap to Mailpit to save the RAM; until then, the extra features are worth the 100 MB.
Compare smtp4dev
4 head-to-head comparisons.
Similar mail servers apps
listmonk
Mail ServersSelf-hosted newsletter and mailing list manager
Replaces Mailchimp, Sendinblue
Docker Mailserver
Mail ServersProduction-ready, config-driven mail server in a container
Replaces Google Workspace, Microsoft 365
Mailspring
Mail ServersCross-platform desktop email client
Replaces Outlook, Apple Mail
Postal
Mail ServersComplete mail delivery platform for outgoing email
Replaces SendGrid, Mailgun
MailHog
Mail ServersEmail testing tool with a fake SMTP server
Replaces Mailtrap
Mail-in-a-Box
Mail ServersTurn a fresh server into a working mail server
Replaces Google Workspace, Microsoft 365