Mail-in-a-Box vs Stalwart Mail: When the All-in-One Stack Hides a Broken PTR Record

The first time I trusted a green Mail-in-a-Box status page, I sent a password-reset mail to myself at Gmail and watched it vanish. Not spam. Not delayed. Gone. The box said DNS was fine. Roundcube sent the message. Postfix logged a 250. Somewhere between my VPS and Google’s edge, the mail was treated as a stranger with a forged nametag.

The nametag was the PTR record. The all-in-one stack had never mentioned it as a first-class failure. It had a checkbox for “DNS” that meant the records this box publishes, not the reverse DNS the internet believes about your IP. Those are different jobs. One is yours. The other belongs to whoever sold you the address.

Stalwart Mail does not hide that distinction as neatly. It also does not fix it. If you are still deciding whether to run mail at all, start with why almost nobody self-hosts email. If you are choosing between Mail-in-a-Box and Stalwart because you left Google Workspace or Microsoft 365, the interesting question is not which webmail looks nicer. It is whether the stack will let you see a broken PTR before you stake a domain on it.

What Mail-in-a-Box is actually selling

Mail-in-a-Box is a productized opinion. You get Ubuntu, Postfix, Dovecot, Nginx, Roundcube, a local DNS server, TLS via Let’s Encrypt, and a status page that tries to tell a non-specialist whether mail is “working.” It will also offer Nextcloud for contacts and calendars if you let it. The pitch is that email is a bundle, and the bundle should be installed by a script, not assembled from wiki pages.

For a lot of people that pitch is honest. If you have a cheap VPS with a clean IPv4, a provider that lets you set reverse DNS, and a domain you do not mind pointing entirely at the box, Mail-in-a-Box will stand up SMTP, IMAP, and a browser inbox in an afternoon. The status page will go green. Friends will receive your mail. You will feel like you beat the industry.

The cost of that opinion is opacity. When something is wrong, you are debugging a distribution, not a daemon. Postfix lives where the installer put it. The DNS the box serves is not necessarily the DNS the world uses if you later pointed the domain at Cloudflare. The Nextcloud bit becomes another thing to back up. The status page is a summary, and summaries lie by omission.

What Stalwart is actually selling

Stalwart Mail is a single Rust server that speaks SMTP, IMAP, JMAP, and the modern authentication stack without dragging a 2014 LAMP closet along for the ride. You configure it with TOML or the admin UI. You pick your database. You decide whether webmail is Roundcube, SnappyMail, or something you do not run at all. There is no Nextcloud “bonus.” There is no implied DNS appliance.

That makes Stalwart feel lighter and, if you are honest, more adult. It also means you own every adjacent decision Mail-in-a-Box made for you: how certificates renew, where DKIM keys live, how you expose the admin port, what happens when the disk fills with deferred mail. Stalwart will generate DKIM keys and tell you what to publish. It will not pretend that publishing them is the same as being trusted.

I have run both. Mail-in-a-Box is the weekend. Stalwart is the quarter. The weekend is cheaper until the first silent bounce.

The failure that looks like a working inbox

Forward DNS is the easy half. You create A and AAAA records for mail.example.com. You create MX. You publish SPF that names that host. You publish a DKIM TXT. You publish a DMARC policy that starts on p=none so you can read reports before you punish anyone. Mail-in-a-Box will do most of this if you let it be the nameserver. Stalwart will give you the strings and wait.

Reverse DNS is the half people skip because no web panel on your box can write it. PTR is owned by the IP’s allocation. On a good VPS, there is a field labeled “Reverse DNS” or “PTR” that accepts mail.example.com and propagates in minutes to hours. On a bad VPS, the field is missing or only accepts the provider’s hostname. On residential fiber, the PTR is something like customer-pool-12.your-isp.net and you will never change it. On CGNAT, you do not have a public IPv4 to point at all.

Receiving mail servers still care. Not every one, not every time, and not with a clear error. Gmail has been the loudest about it for years: if the connecting IP’s PTR does not exist, or does not forward-resolve back to an A record that matches the IP, the message is junk or rejected. Microsoft is similar. Smaller hosts copy the big ones. Your own Roundcube will still say “sent.”

This is the trap of the all-in-one. Mail-in-a-Box’s status checks are excellent at catching its mistakes: expired certs, missing local zone records, a firewall that forgot 25/tcp. They are weak at catching a provider PTR that still says vps-1844.cheapcloud.example while your HELO says mail.example.com. The dashboard can be green while Gmail’s postmaster tools show a reputation that never leaves the basement.

How Mail-in-a-Box hides a bad PTR

Mail-in-a-Box wants to be your DNS. That is a coherent design if the box is also the public nameserver for the domain. You log into the control panel, it shows the records it is serving, and those records match what dig @box.example.com returns. Your brain files that under “DNS is fine.”

Then you do the reasonable adult thing. You move the domain to a real DNS host so you can put the website on another machine, or you put the box behind Cloudflare because you read a blog post about hiding origin IPs. Now the box is still serving a zone that nobody queries. The status page may still believe itself. The public MX is correct. The public SPF is correct. The PTR is still the VPS hostname you never opened a ticket about.

I have also seen the inverse: people leave Mail-in-a-Box as the nameserver, pass every local check, and still fail because the VPS image came with an IPv6 address they never set a PTR on. IPv6 mail paths are less common from a home-sized box, but if the host prefers AAAA and the PTR is empty, you get a new flavor of the same bounce. The status page is still thinking in IPv4.

None of this is Mail-in-a-Box being incompetent. It is Mail-in-a-Box optimizing for the person who wants one appliance. An appliance cannot SSH into your ISP.

How Stalwart fails more honestly

Stalwart will not stand up a recursive DNS story for you. That sounds like a downgrade until you have been burned. You are forced to put MX, SPF, DKIM, and DMARC in the DNS you actually use. You are forced to look at the provider panel for PTR because nothing in the installer claimed it was handled. The first time mail fails, you have fewer layers to peel.

Stalwart’s logs are also closer to the protocol. You see the remote greeting, the MAIL FROM, the DATA, the 550 with a phrase about “does not have a valid PTR” or “not aligned.” Mail-in-a-Box’s Postfix will log the same thing if you go looking in the right file. The difference is whether looking in the right file is part of the product or an admission that the product ended.

Stalwart does not make PTR easier. If your only IP is a residential address, Stalwart will be rejected just as hard as Postfix. The honesty is the feature. You decide earlier that self-hosted submission from that network is a hobby, not a plan.

The networks where neither stack can save you

If you are on apartment fiber with CGNAT, stop. You can run IMAP and a fetch-from-elsewhere workflow. You cannot be a public SMTP speaker. A mesh overlay or a cheap VPS becomes the egress, and then the VPS’s PTR is the record that matters, not the box under the TV. People try to “just use IPv6” and discover that the destination still prefers IPv4 or that the ISP’s IPv6 PTR is a pool name.

If you are on a VPS that forbids port 25, stop again. Both stacks will listen. Both will fail at the first hop. The vendor will tell you to use their relay. Using their relay means you are not really self-hosting outbound mail; you are self-hosting the mailbox and renting reputation. That can still be the right call. It is not the demo in the README.

If you can set PTR, set it before you cut over MX. Wait until dig -x YOUR.IP returns the exact name you HELO as, and that name’s A record returns the same IP. Do it for IPv6 if you have a global address you might use. Then send to Gmail, Outlook, and a small independent host. Then wait a week and read the DMARC aggregate reports. The all-in-one wants you to feel done on day one. Deliverability is a week-one problem that pretends to be a minute-one problem.

Green authentication, still junk

SPF, DKIM, and DMARC can all pass on a message that still lands in spam. Alignment is the extra knife. SPF can pass on a bounce address that is not the From domain. DKIM can pass on a signature whose d= is a hostname you never told users about. DMARC needs at least one of those to align with the visible From. Mail-in-a-Box’s defaults are usually aligned if you did not invent extra hostnames. Stalwart will let you invent extra hostnames. That flexibility is how people accidentally sign as mx1.example.com while sending as hello@example.com.

PTR sits underneath that stack like a bouncer who does not read your DMARC XML. You can have a textbook aligned message and still get a policy rejection because the IP looks like a botnet node. The all-in-one status page will not show “Gmail thinks you are a botnet.” It will show checkmarks.

I treat three views as mandatory and the dashboard as optional: the provider PTR field, a query from a resolver that is not my box, and a received header on a message that actually arrived at a big host. If any of those three disagree, the stack is lying — politely, with green icons.

Operations after the first successful send

Mail-in-a-Box updates are a ritual. You take a snapshot, you run the upgrade path the project documents, you hope Ubuntu and the installer still agree. When they do not, you are restoring a whole appliance. That is acceptable if the box does only mail. It is miserable if you also parked files in the bundled Nextcloud and treated the VM as a general server.

Stalwart updates are a binary and a config. That is nicer until you have to migrate the data store or re-learn which TOML key moved. Backups are your problem in both cases. Mail-in-a-Box at least has a documented backup story aimed at non-experts. Stalwart assumes you already back up databases. If you do not, pick Mail-in-a-Box or pick a different hobby.

Webmail is not the differentiator people think it is. Both will sit behind Roundcube or a successor. The differentiator is whether you wanted JMAP, Sieve that you understand, and a server you can reason about — or whether you wanted a status page your future self will trust too much.

Spam filtering is the other place the all-in-one earns its keep. Mail-in-a-Box ships a working inbound stack. Stalwart can do filtering; you will configure it. If your threat model is “family members will mail me from random phones,” the appliance’s defaults are a gift. If your threat model is “I want to know why this message was rejected,” Stalwart’s explicitness wins again.

When I still install Mail-in-a-Box

I install it when the IP is clean, the PTR field exists, port 25 is open, and the person who will maintain the box is not me in six months. The status page is a kindness for that person. I also install it when the domain can live on the box’s DNS without a CDN in front, because that is the design center. I tell them not to add Nextcloud unless they have a second backup plan. I tell them to send test mail to Gmail before they tell anyone the new address.

I do not install it on a home fiber line and call it production. I do not install it on a $4 VPS that shares an IP reputation with a thousand forgotten WordPress sites. I do not install it and then immediately proxy the whole domain through a service that rewrites mail-related records I did not audit.

When I install Stalwart instead

I install Stalwart when I already have DNS elsewhere, when I want JMAP, when I do not want Nextcloud on the mail VM, and when I am willing to treat PTR, SPF alignment, and DMARC reports as my job. I also install it when I know I will outgrow the appliance’s opinions — extra domains, extra identities, a submission hostname that is not the MX hostname.

I still set PTR first. I still wait a week. The software change does not shrink the reputation clock.

If I cannot set PTR, I do not install either as an outbound speaker. I keep the mailbox local and relay through a provider that already bought the IP reputation. That is less romantic than “I run my own email.” It is the only version that does not waste a weekend on a problem the dashboard cannot name.

A decision that is not about features

Mail-in-a-Box versus Stalwart is usually sold as classic versus modern, bundled versus modular, PHP-around-Postfix versus Rust. Those are real differences. They are not why mail dies.

Mail dies because the internet still asks a question your installer cannot answer: who owns this IP, and does that owner agree with the name on the envelope? The all-in-one stack is dangerous when it answers a different question so confidently that you stop asking the real one. Stalwart is safer only because it stays quiet. Quiet is not a PTR record.

Pick Mail-in-a-Box if you want a single appliance, you control reverse DNS, and you will not clever your way around its DNS story. Pick Stalwart if you want a mail server, not a lifestyle distribution, and you are already in the habit of querying the internet from somewhere that is not the box. Pick neither as a public SMTP speaker if the PTR is a pool name you cannot change.

The inbox can look finished either way. The bounce log is the product. If your stack hides that log behind a green page, you did not finish. You just stopped looking.