emailwiz.sh installs a full mail server on a bare Debian box

A single shell script that replaces a day of mail server setup

emailwiz is one shell script, emailwiz.sh, sitting in a small repository whose top level also holds a README, a licence file, a funding file and adddomain.sh. The script's stated purpose is to install an email server with all the features required in the modern web, and its audience is the person who has a Debian or Ubuntu server and does not want to assemble Postfix, Dovecot, spam filtering and DKIM by hand.

The distribution method is deliberately frictionless. The author links the file on GitHub to a shorter address on his own site, and the documentation tells you to fetch it with a single command:

curl -LO lukesmith.xyz/emailwiz.sh

The run itself is interactive. A dialog menu appears at the beginning, and the instruction is to select Internet Site, then give the full domain without any subdomain, for example lukesmith.xyz. The menu choice is the one decision that determines whether Postfix treats the machine as a relay for other domains or as the mail host for its own, so it is worth reading the prompt rather than pressing enter.

Two prerequisites are stated up front. You need a Debian or Ubuntu server, and you need DNS records pointing at least the mail. subdomain of your domain to your server IP, for both IPv4 and IPv6. The documentation is explicit that this is required on the initial run, because certbot needs the mail. subdomain resolvable in order to issue an SSL certificate for it. In other words the script is interactive with your DNS as well as with your terminal, and you cannot finish it in one sitting unless the records already exist.

Postfix for mail, Dovecot for reading, and the pieces that keep you out of spam folders

The component list is the clearest statement of what the script builds. Postfix sends and receives mail. Dovecot delivers it to your mail client, with mutt and Thunderbird given as the examples. SpamAssassin filters spam and lets you write custom filters. OpenDKIM signs outbound mail so that receivers, including Gmail and other large providers, can validate you. Certbot provides SSL certificates if they are not already present. fail2ban raises the security posture, with the enabled modules covering the programs just listed.

The glue between the first two is described as config files that link Postfix and Dovecot securely with native PAM log-ins, which is the piece that decides how a local Unix account becomes a mail login.

There is an optional branch as well. The script can skip OpenDKIM and Certbot and instead create a self-signed certificate that lasts 100 years, which it positions as a way to stand up an isolated mail server that collects notifications from devices on the same local network, or that acts as a private messaging system over a VPN such as wireguard. The trade is stated in plain terms: a server configured this way will not be able to send anything to public mail servers such as Gmail or Outlook, at least not directly. That is a genuine feature for a lab appliance and a disqualifier for anything that sends mail outward, and it is a decision you make by editing the script before the run, not through a menu.

Unix users instead of SQL, and no webmail on purpose

Two exclusions in the documentation are worth reading closely, because they define the project's scope. The script does not use a SQL database or anything like it, and the reason given is that it keeps things simple by using normal Unix system users for accounts and passwords. The second exclusion is a graphical web interface for mail such as Roundcube or Squirrel Mail. You are expected to use a normal mail client, with Thunderbird named, K-9 for Android named, and good old mutt with the mutt-wizard linked for the terminal case.

So the account model is the operating system's. Mail lives in the user's home directory, in a Mail folder, and the credentials are the ones the account already has. That is elegant for a small server with a handful of people on it, and it is a poor fit if you want a mail server for many users, if you want to change the authentication system, or if you want to move the mail store somewhere other than home directories.

The webmail question gets a pointer rather than a feature. The documentation notes that there is a guide for Rainloop on LandChad.net for those who want such an interface. That is the honest answer to the most common request this kind of script attracts, and it means the extra layer lives outside the script and outside its maintenance.

The four DNS records that decide whether your mail is trusted

At the end of the run the script prints the DNS records you need to add at your registrar, and it also writes them to a file called ~/dns_emailwiz. The documentation explains that these records are mostly there to authenticate your mail as non-spam, and lists four of them: an MX record directing to mail.yourdomain.tld, a TXT record for SPF to reduce mail spoofing, a TXT record for DMARC policies, and a TXT record carrying your public DKIM key. They look roughly like this:

@	MX	10	mail.example.org
mail._domainkey.example.org    TXT     v=DKIM1; k=rsa; p=anextremelylongsequenceoflettersandnumbersgeneratedbyopendkim
_dmarc.example.org     TXT     v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1
example.org    TXT     v=spf1 mx a: -all

The DKIM record is the one that cannot be prepared in advance. It is long and uniquely generated while emailwiz.sh runs, so it has to be added after installation. That single fact dictates the shape of the whole session: you run the script, you copy a long string from ~/dns_emailwiz into your DNS provider, and until that TXT record exists, signed outbound mail has nothing to validate against.

One more record is not in that list of four, and the documentation treats it as equally important: a reverse DNS or PTR record pointing at mail.yourdomain.tld, set for both IPv4 and IPv6 at your VPS provider, to avoid getting spammed. Without it, the forward records are correct and the mail still gets flagged.

Ports your VPS provider blocks by default

Here is the part that catches people, and the script cannot fix it. While the script enables the mail ports on your server, it is common practice for all VPS providers to block mail ports on their end by default. The documented remedy is to open a help ticket with the provider asking them to open the mail ports, and they will do it in short order.

This means a successful script run is not yet a working mail server. The server side is configured, the certificate is issued, the DKIM key exists, but SMTP and IMAP traffic stops at the provider's edge until a human on a support ticket opens the ports. A reader who installs this and immediately tests from an external account will see a connection timeout, and the cause is not in the script.

The troubleshooting notes in the documentation point the same way. The first thing to check is journalctl -xe for specific errors, and the linked tools cover DNS checks, a TXT record test by mail, and a blacklist lookup for your IP. The blacklisting tool matters after the ports are open, because a server that has sent mail from a fresh IP is often listed before its reputation builds.

Switching to the isolated mode by editing two variables

The self-signed branch is controlled by variables inside the script rather than by a prompt. The documentation tells you to open the script and change one line:

selfsigned="no" # yes no

to this:

selfsigned="yes" # yes no

There is a second switch for automating the certificate creation, changing use_cert_config from no to yes:

use_cert_config="no"

and then the certificate subject fields can be filled in:

country_name="" # IT US UK IN etc etc
state_or_province_name=""
organization_name=""

Editing a script before running it is the normal workflow here, and it is worth noticing the implication for upgrades: there is nothing to configure, and nothing to re-run idempotently, because the state lives in the file you edited. If you later want the public path with DKIM and Certbot, you have to change the variable back and think about what the previous run already installed. The documentation does not describe an uninstall or a reset procedure, and the repository has no GitHub releases, so there is no version history to fall back on.

Mail accounts are Unix accounts, and the client settings are fixed

Adding a mailbox is a pair of ordinary user management commands. To create a new user called Billy who should receive mail, the documentation gives:

useradd -m -G mail billy
passwd billy

The group is the mechanism. Any user added to the mail group can receive mail, so for an account that already exists, such as Cassie, the command is:

usermod -a -G mail cassie

A user's mail then appears in ~/Mail/. If you want to read it over a terminal, the suggestion is to install mutt, add set spoolfile="+Inbox" to your ~/.muttrc, and use mutt to view and reply. The documentation expects you to log in remotely in practice, and the client settings for the author's own domain are given as SMTP server mail.lukesmith.xyz on port 465 and IMAP server mail.lukesmith.xyz on port 993. You would substitute your own domain, and those are the two ports the client configuration needs.

The repository also contains adddomain.sh, which sits next to emailwiz.sh at the top level.

A GPL-3.0 script that is still being touched

Maintenance is the last thing to weigh. The repository is not archived and the last push was on 2026-10-18, so the script is actively being worked on, but it publishes no GitHub releases, so there is no tagged version to pin and no changelog of breaking changes to read before an upgrade. You are running whatever the file at the short address currently contains.

The licence is GPL-3.0. For most people running it on their own server that has no practical effect, and it does matter if you redistribute a modified version or bundle it into something you distribute. That is the scope of the grant, not legal advice about your particular setup.

The last practical concern is what the script does not cover. It does not create the DNS records, it cannot open ports at your provider, it does not set up a reputation for a brand new IP address, and it does not tell you how to update an installation that has already run once. It configures a server, and a fair amount of the work that makes mail actually deliver sits outside it, in a DNS panel and a support ticket.

Editorial conclusion

emailwiz suits a person with a Debian or Ubuntu VPS who wants a working mail server with DKIM and TLS in one sitting and is comfortable editing a script before running it. It is the wrong tool for a managed mail provider, for a server you cannot reboot, or for anyone who needs a graphical mail interface. Verify first that your provider will open the mail ports, that a mail. subdomain resolves to the server on both IPv4 and IPv6 before the first run, and that the four DNS records the script writes to ~/dns_emailwiz are published, since without the SPF, DMARC and DKIM entries the server will be treated as a spam source.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LukeSmithxyz/emailwiz on GitHub
4. README