EM

emailwiz

Script to deploy a full Postfix/Dovecot mail server

Mail Servers ★ 2.2k stars Medium setup GPL-3.0

emailwiz is a shell script that automatically configures a complete, secure email server with Postfix, Dovecot, Spamassassin, and DKIM on a Debian or Ubuntu system. It targets quick, opinionated setups.

Key features

  • One-script mail server setup
  • Postfix, Dovecot and SpamAssassin
  • Automatic DKIM and TLS
  • Opinionated, secure defaults

Pros & cons

Strengths

  • Fast to deploy
  • Transparent shell script

Trade-offs

  • No webmail included
  • Limited customization

emailwiz replaces

Last reviewed Sep 13, 2026 · 892 words

emailwiz is a shell script, not a mail server. You run it once on a fresh Debian or Ubuntu box and it installs Postfix, Dovecot, SpamAssassin and OpenDKIM, wires them together with sane TLS and authentication, and prints the DNS records you need. About 10 minutes later you have a server that passes SPF, DKIM and DMARC checks at Gmail. What you do not have is a web interface, an admin panel, or an upgrade path: once the script exits you are the maintainer of a hand-configured Postfix installation. Whether that is the point or the problem is the whole decision.

Read the script first, because you will be living in its output

The repository is one readable file plus a README, and reading it is the setup guide. The prerequisites it assumes are strict and it does not check all of them: it takes your domain from /etc/mailname (the Postfix install prompt fills that in, so answer it with example.org, not the machine name), expects the server to be reachable as mail.example.org, and needs a Let's Encrypt certificate for that mail hostname already sitting under /etc/letsencrypt/live/, so you run certbot before emailwiz, not after. Then:

apt install git certbot
certbot certonly --standalone -d mail.example.org
git clone https://github.com/LukeSmithxyz/emailwiz.git
cd emailwiz && sh emailwiz.sh

It configures submission on 587 and SMTPS on 465 with authentication required, IMAP on 993, Maildir storage under each user's home directory, Sieve filtering that moves SpamAssassin hits into a Junk folder, and a DKIM key for the domain. The final screen prints three TXT records (DKIM selector, SPF, DMARC) to paste into your DNS. Mail accounts are plain Unix users:

useradd -m -G mail alice
passwd alice

That gives [email protected] an inbox with no database, no web form and nothing to back up except /home/alice/Mail and three directories under /etc. For one domain and a handful of people it is the least machinery I know of that produces a real, standards-compliant server.

Deliverability is decided before you run anything

The script cannot fix the two things that actually sink small mail servers. First, outbound port 25: Hetzner, DigitalOcean, Oracle Cloud and Google Cloud all block it on new accounts, some permanently, some until you file a ticket. Check this before paying for the month. Second, reverse DNS: the PTR record for your IP must resolve to mail.example.org, and it is set in the provider's panel, not in your zone. Add a third check while you are there: paste the IP into a blocklist lookup before committing, because a VPS address that spent last year sending spam will be rejected by Microsoft no matter how clean your DKIM is. My longer piece on whether self-hosted email is worth it at all covers the reputation-warming period, which is real and is measured in weeks.

What it leaves out, by design

The README is honest about this list, and so should you be before choosing it:

  • No webmail. You read mail with Thunderbird, Apple Mail, K-9 or anything that speaks IMAP over 993.
  • One domain. Multiple domains are possible with Postfix virtual maps, but you are editing main.cf by hand at that point.
  • No quotas, no fail2ban, no rate limiting, no spam training beyond SpamAssassin defaults.
  • No updates to the configuration. apt upgrade keeps Postfix and Dovecot patched, but nothing ever revisits the config the script wrote.

The last point is the one that matters after year one. TLS ciphers, DMARC policy and the SpamAssassin ruleset all age, and emailwiz has no notion of re-running to refresh them. Budget an hour a year to read the diff between the current script and the one you ran.

The larger projects are safer for anyone who needs more than one domain

If you want an admin UI, several domains, webmail and a supported upgrade story, run something that packages the whole stack. Stalwart is the one I point people at now: a single Rust binary doing SMTP, IMAP and JMAP with a web admin, and it is comfortable in the same 1 GB a Postfix box needs once SpamAssassin is loaded. Mailcow and docker-mailserver are the Docker-era equivalents with larger communities and larger footprints. The email category lists the rest. emailwiz wins only on transparency: every line of the resulting configuration is one you can read, and there is no container layer between you and the logs when Gmail starts deferring your mail at 3 a.m.

What I'd do

For a single personal domain on a 1 GB VPS from a provider that unblocks port 25, I would run emailwiz, add two users, paste the DNS records, and then send 5 messages a day to accounts I own for 3 weeks before moving anything important onto it. I would keep the Google Workspace account alive for 60 days as a fallback. For a family, a small business, or anyone who has said the words "we need a second domain", I would skip straight to Stalwart and accept the extra moving parts, because the script's simplicity stops paying for itself the moment you touch main.cf.

Compare emailwiz

9 head-to-head comparisons.

Similar mail servers apps