BillionMail: self-hosted mail server, newsletter and campaign sending in one stack

What BillionMail replaces, and for whom

BillionMail is a self-hosted alternative to the combination most teams assemble from a managed ESP plus a separate mail server. The README describes it as an open-source mail server and email marketing platform for newsletters, promotional mail and transactional messages, and the repository topics list dovecot, postfix, rspamd and smtp alongside email-marketing and newsletter. That combination is the point: the MTA that delivers the mail and the application that composes the campaign ship together, so a bounce or a complaint is visible in the same place as the send.

The audience is narrower than the marketing copy suggests. Anyone can run the install script, but the product only pays off for operators who are willing to own a mail domain end to end: DNS records, reverse DNS, TLS certificates, and the reputation work that follows a first bulk send. If your team has never operated an SMTP server, BillionMail does not remove that requirement, it concentrates it into one deployment.

The container topology behind the campaign UI

The architecture is visible in docker-compose.yml. The compose project is named billionmail and defines a private network called billionmail-network with service aliases pgsql, redis, rspamd and dovecot, so application containers reach each other by hostname rather than by published port. PostgreSQL 17.4-alpine stores the application data, with its data directory bind-mounted to ./postgresql-data and a socket directory at ./postgresql-socket. Redis 7.4.2-alpine runs with a custom entrypoint script mounted from conf/redis/redis-conf.sh and sets net.core.somaxconn to 4096, which is a queue-depth tuning for connection bursts rather than a default.

Rspamd runs from the billionmail/rspamd:1.2 image and depends on redis, which is how it keeps its statistics and rate limiting. Its local configuration, statistic.conf and rspamd.conf are mounted from the conf/ directory, so tuning survives a container rebuild. Dovecot runs from billionmail/dovecot:1.6 and depends on PostgreSQL. The README adds that RoundCube is integrated and reachable at /roundcube/ for webmail. The data flow is conventional for this kind of stack: mail arrives or leaves through the MTA, Rspamd scores it with Redis-backed state, Dovecot handles mailbox access, and the campaign application reads and writes everything through PostgreSQL.

Installing BillionMail and sending a first campaign

The README gives a one-line install that clones the repository into /opt and runs install.sh. The project claims eight minutes from installation to a successful send; that figure is the README's own, and it assumes the domain side is already prepared.

cd /opt && git clone https://github.com/aaPanel/BillionMail && cd BillionMail && bash install.sh

If you prefer to manage the containers yourself, the Docker path copies env_init to .env first, then brings the stack up. The README notes that Docker and the docker-compose-plugin must be installed manually and that the .env file should be modified before starting.

cd /opt && git clone https://github.com/aaPanel/BillionMail && cd BillionMail && cp env_init .env && docker compose up -d || docker-compose up -d

After the stack is running, the management script is the entry point for everyday tasks. bm help lists the commands, bm default prints the default login information, bm show-record prints the DNS records for a domain, and bm update pulls a newer version.

bm help
bm default
bm show-record
bm update

The README's three-step flow is then: add the sending domain and verify DNS records, which also enables free SSL automatically; write or paste the email; choose the list and tags and either schedule the send or send immediately. A live demo is published at demo.billionmail.com/billionmail with the username and password both set to billionmail, which is a reasonable place to look at the campaign editor before you commit a server.

Where self-hosted sending actually breaks

BillionMail removes the monthly fee, not the deliverability problem. A new IP sending bulk mail has no reputation, and the README does not describe any warm-up procedure, IP pool management or feedback-loop handling. The documentation also does not document rollback, so if bm update moves you to a release that misbehaves, the recovery path is whatever your own backups allow. That is a real operational gap for a component that sits in front of your outbound mail.

The published ports are the second thing to check. PostgreSQL maps ${SQL_PORT:-127.0.0.1:25432} to 5432 and Redis maps ${REDIS_PORT:-127.0.0.1:26379} to 6379. The defaults bind to localhost, which is correct, but the values come from .env, and the Docker instructions explicitly tell you to modify that file. Setting SQL_PORT or REDIS_PORT to a public interface exposes the database and the Rspamd state store to the internet. Nothing in the README warns against it.

The wrong-tool case is straightforward. If you send a few hundred transactional messages a month and have no interest in running Dovecot, Rspamd or a PostgreSQL instance, a managed transactional API plus a hosted newsletter tool costs less in engineer hours than this stack costs in attention. BillionMail is for volume and control, not for convenience.

BillionMail against Listmonk and Mautic

Listmonk is the closest comparison in the related searches, and the difference is scope. Listmonk is a newsletter and mailing-list application that expects you to bring an SMTP server; BillionMail ships the SMTP server, the IMAP server, the spam filter and webmail as part of the same compose file. If you already run Postfix and Dovecot and only want a campaign front end, Listmonk is the smaller dependency. If you want the MTA and the campaign tool versioned together, that is the case BillionMail is built for.

Mautic sits on the other side of the line. It is a marketing automation platform, oriented around lead scoring, multi-step journeys and CRM-adjacent workflows, and it also expects an external sending service. BillionMail's README lists analytics, customer management and templates, but nothing resembling multi-step automation, so choosing between them is a question of whether you need journeys or whether you need to own the delivery path. Neither is a drop-in for the other.

Licence terms and the cost of staying current

BillionMail is licensed under AGPL-3.0. The README summarises this as free use, the right to modify and distribute, and private use without restrictions, and links to the GNU licence text. The practical consequence of the AGPL for a company is the network clause: if users interact with a modified version over a network, the source of that modified version has to be offered to them. Running the unmodified stack for internal campaigns is the simple case; forking the campaign UI and hosting it for customers is where a legal review belongs. This is a description of the licence, not legal advice.

Upgrade cost is low on paper. bm update is the documented path, releases are tagged (v4.7, v4.8, v4.9), and the repository's last push was on 2026-06-11, which is more than six months before today, so treat the project as one whose current activity you should confirm yourself rather than assume. The compose file pins image tags such as postgres:17.4-alpine, redis:7.4.2-alpine, billionmail/rspamd:1.2 and billionmail/dovecot:1.6, which makes upgrades reproducible but also means a major PostgreSQL jump will need a dump and restore rather than a container swap. Budget for that, and for reading the diff of conf/ before applying it, since Rspamd statistics and Dovecot configuration live in bind mounts that an update can overwrite.

Editorial conclusion

Adopt BillionMail if you already run Postfix or Dovecot and want the campaign UI, list management and analytics in the same deployment, and if you accept AGPL-3.0 obligations for anything you expose over a network. Do not adopt it if you have no one to manage DNS, PTR records, TLS renewal and blocklist appeals, because a self-hosted sender is judged by its reputation, not its feature list. Before committing, verify three things: that your provider allows outbound port 25, that the DNS records printed by bm show-record match what your registrar accepted, and that the database and redis ports in .env are bound to localhost rather than the public interface.

Frequently asked questions

Official sources

1. Billionmail/BillionMail on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases