It joins two jobs that are usually separate
BillionMail is trying to be both the server that receives and sends mail and the application that runs email campaigns. The README describes domain onboarding, DNS-record display, free SSL, lists, tags, reusable templates, scheduled sends, transactional messages, delivery tracking, open rates, and click-through rates. It also integrates RoundCube at /roundcube/, so ordinary webmail sits beside the marketing interface. That combination is the main attraction: 1 self-hosted system can replace a mailbox stack plus a newsletter dashboard, at least for teams whose needs match the documented feature set.
The positioning is unusually aggressive. The README promises an 8-minute route from installation to successful sending and says users can send a billion emails, with a guarantee. No benchmark or capacity evidence in the supplied material supports that volume, so treat it as marketing, not sizing guidance. What is supported is a practical installation surface: a shell installer, Docker Compose instructions, an aaPanel option, and a bm management command for defaults, DNS records, help, and updates. The AGPL-3.0 license also makes the code inspectable and modifiable, but a business should review the license terms before adapting or exposing a modified service.
What happened when we ran it
Our run used commit fc36c76 in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and the golang:1.24-bookworm image. The Go project lives under ./core/; the full checkout contained 1,242 files, about 115,889 source lines, and occupied 20.4 MB. Installation succeeded in 34 seconds after installing 343 packages. The build then succeeded in 77 seconds. Those are encouraging results for basic reproducibility, although they measure compilation in our controlled sandbox, not the time needed to configure a publicly reachable and reputable mail server.
Testing was the break in the path. go test ran for 115 seconds, with 32 packages passing and 3 failing out of 35. The captured tail showed successful packages including mail_boxes, mail_service, maillog_stat, middlewares, multi_ip_domain, public, rbac, relay, video_gen, video_outreach, and warmup, followed only by FAIL. It did not show the failing package names or an error explanation, so we cannot responsibly assign a cause. The repository scan also found 0 CI workflow files, no Dockerfile, and no dedicated tests directory. Go tests can live beside source, but absent visible CI, adopters should reproduce the full suite themselves.
The strongest feature is operational consolidation
For a small infrastructure team, one control plane for sending domains, DNS records, certificates, mailboxes, campaigns, and analytics is genuinely useful. The README's 3-step flow is easy to understand, and bm show-record could reduce mistakes during domain setup. Lists and tags cover basic audience organization, while send-now and scheduled-send options cover common campaign timing. Reusable templates and delivery, open, and click reporting address the everyday loop of composing, sending, and learning. RoundCube means the same deployment can also serve people who need inboxes, which focused newsletter tools such as listmonk intentionally leave to another SMTP system.
Self-hosting also changes the ownership model. Contact data and tracking data can remain on infrastructure the operator controls, with no hosted platform imposing a per-contact sending tier. The README describes unlimited sending, but the practical ceiling is governed by server capacity, queue behavior, network policy, receiver throttling, and domain reputation, none of which was measured in our 115-second test run. Full control therefore means full responsibility. Abuse handling, bounce processing, complaint monitoring, IP reputation, SPF, DKIM, DMARC, backups, patching, and incident response do not disappear because setup begins with 1 command.
The rough edges matter most after installation
The failed suite is the clearest caution because mail software handles hostile input, sensitive content, credentials, and an internet-facing protocol surface. A passing build proves the source compiled on our box; it does not establish production safety. The 0 CI workflow files in the repository snapshot make it harder for an evaluator to see whether every change is checked consistently. Documentation in the supplied README is strongest at the quick-start level and thinner around upgrades, backup and restore, monitoring, failure recovery, capacity planning, and secure production topology. The public demo helps exploration, but shared credentials should never be mistaken for evidence about isolation or production hardening.
There is also a mismatch between the README's confident promises and the evidence available here. Version v4.9 was released on December 11, 2025, while the repository was pushed as recently as June 11, 2026. That later push argues against calling the project abandoned, even though the latest listed release is roughly 9 months old. The 228 open issues and 15,507 stars show substantial attention and a meaningful backlog, but these numbers alone do not tell us response time or maintainer capacity. Release cadence appears slower than code movement in this snapshot, and 1 release date is not enough to infer a dependable schedule.
It fits best as an owned platform behind careful controls
In a real stack, BillionMail belongs on dedicated infrastructure with deliberate DNS, restricted administration, monitored queues, backups, and a staged rollout. Start with 1 low-risk domain and small internal or opted-in lists, then verify authentication records, bounces, complaints, unsubscribe behavior, and recovery before expanding. Teams already satisfied with a managed SMTP provider may be better served by listmonk for campaigns alone. Teams focused on dependable mailbox hosting should compare mailcow or Docker Mailserver. BillionMail earns a pilot when consolidation is the goal, but the 3 failing packages should be understood or cleared before a production decision.