From practice

What running your own mail server really costs

Not money, and not skill either. The price is attention — and it is, because practically every fault in this chain happens silently. A record of what actually went wrong while setting up a single mailbox.

The occasion

This site needed a mailbox. Exactly one, for the address in the legal notice, with an expected load of perhaps a handful of messages a week. The kind of job you would describe as "quickly set up".

It took several attempts. Not one of the problems was difficult — each was merely invisible until somebody went looking for it specifically. That is the actual finding, and it is why this page exists.

What went wrong

One package had been blocking all updates for two weeks

On the first installation attempt the package manager aborted. The cause was a timezone package that had been stuck half-configured for eleven days: the system timezone pointed at a file that carried no valid timezone name, while a second file claimed something else. The package wanted to resolve the contradiction, asked, found no terminal and gave up.

The side effect was the real news. For eleven days this server's automatic security updates had been failing too — on every run, at the same point. There was no warning, no mail, no red dot anywhere. The server had simply been unpatched for a week and a half, and would have gone on that way had somebody not happened to want to install a package.

A service counted as dead and was running anyway

While setting up the signing of outgoing mail, the service manager showed the process responsible as "failed". At the same time the network port was occupied and answering. Both were true: a process from the previous year was still running, started outside the service manager, with a different configuration file from the one being maintained. The mail server had been talking to that leftover process the whole time.

Restarts therefore failed with "address already in use" — a message that points at a network problem and in truth pointed at an undead process.

Nothing got signed even so, and nobody said why

After the repair the service ran, the key demonstrably matched the published DNS record, the checking tools reported "key OK". Messages still went out unsigned. Two separate causes, one after the other:

• The configuration was missing the line that sets the operating mode to "sign and verify". Without it the service only verifies — and because there is nothing to verify about an outgoing message, it did nothing at all and wrote nothing about it to the log either.
• After that the lookup table did not match. The pattern *@domain.tld is the notation for a table read as a regular expression; in a plain table the comparison is literal, and then that pattern matches nothing. The service ran flawlessly and signed nothing.

Both only became visible once a logging option was switched on that outputs the reason for not signing. The default setting logs successes — about the absence of them it says nothing.

The certificate name could not be freely chosen

The key had to be published as a record in the DNS. The provider's management interface, however, allows no free-form records, only templates for well-known service providers — and the template assigns the name itself. The signature name of this domain is therefore named today after a mail delivery provider it has nothing to do with. Functionally flawless, semantically nonsense.

That is no fault of the provider. It is the consequence of a technically open system being operated through interfaces that know only the usual cases.

And then the brace

The mailbox service acknowledged its configuration with Garbage after '{'. The cause: after an opening brace it requires a line break. A setting on the same line is invalid — a formatting rule the configuration founders on, not its content.

The pattern

None of these points is difficult. Every one of them can be fixed in a single line once you know about it. What they have in common is something else:

That is the actual bill. It is not the setting up that costs but the standing obligation to go and check actively whether what was true yesterday is still true. Anyone with no reason to look does not find out — and there is no reason until somebody misses a message.

Where this comes from

The cause does not lie in bad software. It lies in the shape of the whole thing: email is a protocol around which four decades' worth of separate procedures have grown — sender authorisations in the DNS, signatures via an additional service, scoring by the recipient, delivery via one more service, collection via a third.

Each of these parts works on its own and knows only as much about the next as it has to. Which is exactly why each can fail on its own without the chain snapping: the message goes on its way, just unsigned, unverified or unscored. A system whose parts treat each other this politely loses the ability to say when one of them is missing.

If you have ever wondered why practically everyone has handed their email to a handful of large providers: that is the answer. Not because running it yourself is too hard, but because it demands sustained attention nobody wants to devote to a by-product.

Every incident described here comes from building this site and its infrastructure in August 2026. They are listed deliberately unvarnished, self-inflicted ones included.