Taking Back Control of Email — and Making It Better

24 August 2026

Buy a domain, sign up for Microsoft 365 or Google Workspace, create some mailboxes, and that’s that.

It works. Usually.

But it also means handing an increasingly important part of your organisation to one of a very small number of enormous providers — and accepting their decisions about cost, privacy, features and how your data should be handled.

At The Cuckoo Camp, I’ve taken a rather different approach.

And it isn’t because I’ve never had to run email the conventional way.

More than twenty years of email

I’ve spent more than twenty years working with email systems in one form or another.

That has included traditional corporate mail infrastructure, administering Microsoft Exchange in large educational and business environments; the interesting middle ground of open but still proprietary platforms such as Zarafa and Kopano; and, increasingly, the cloud platforms that came to dominate the market — Microsoft 365 and Google Workspace.

They’ve all had advantages. They’ve all had disadvantages. And I’ve watched the industry move from organisations operating their own infrastructure towards effectively renting one of their most important communications systems from a handful of multinational companies.

Having seen email from all of those perspectives, I kept coming back to the same thought:

We can do this better.

Not necessarily bigger. Not by trying to recreate Microsoft 365.

Better suited to the organisations we actually work with.

Two years of doing it for real

This isn’t a newly launched experiment.

The Cuckoo Camp’s independent email service has now been in production for more than two years, providing real email services to a small group of clients.

The original platform was deliberately fairly conventional. It used established technologies such as Roundcube for webmail and the familiar IMAP and SMTP protocols supported by practically every desktop and mobile email application.

And it worked.

That’s important, because the work we’ve been doing recently hasn’t been about rescuing a failing service.

It’s the opposite.

Two years of operating the platform gave us the opportunity to see what worked well, what created unnecessary administration and, perhaps most importantly, what we would do differently if we were designing it today.

So we’ve been doing exactly that.

We’ve gradually built a new generation of the platform around the existing service, introducing and testing components individually and migrating functions as they became ready.

Without taking the mail service down to do it.

A modern mail service without the tech giants

The objective is straightforward: provide the things people expect from a modern hosted email service without requiring Microsoft or Google to sit in the middle of it.

The new platform provides email, modern webmail, contacts and calendars, with automatic configuration for compatible applications.

A user shouldn’t need to know what an IMAP server is, which port SMTP submission uses, or what any of the other alphabet soup means.

Enter an email address and password and, wherever the application supports the appropriate standards, the platform can tell it where everything lives.

Underneath that simplicity is a considerably more sophisticated system.

Modern webmail — while keeping open standards

One of the most visible changes is our move towards Bulwark, a modern open-source webmail application built around JMAP.

JMAP is a newer internet standard designed to provide a much better foundation for modern mail applications than continually extending protocols originally designed for a very different era of computing.

For the person actually using it, the important bit is much simpler:

Webmail feels like a modern application.

Traditional email isn’t going anywhere, though.

IMAP and SMTP remain available for applications that use them. CalDAV and CardDAV provide standards-based calendar and contact synchronisation.

That’s an important principle behind the platform.

We’re not escaping somebody else’s proprietary ecosystem by creating a Cuckoo Camp proprietary ecosystem instead.

Your email remains email.

Use our webmail because it’s good — not because we’ve made it impossible to use anything else.

Encryption where it matters

The new platform also gives us considerably stronger options for protecting the contents of email.

Connections between users and the platform are encrypted, as are connections between mail systems wherever the receiving system supports modern secure transport.

But transport encryption is only part of the picture.

The new stack also supports encryption at rest, protecting stored mailbox data rather than simply leaving message contents unencrypted on disk.

And where the confidentiality requirements justify it, the platform supports end-to-end encrypted email — protecting the content for its intended recipient rather than merely encrypting the connections between the systems carrying it.

Those distinctions matter.

“Encrypted email” is sometimes used as a wonderfully vague marketing phrase. Encryption in transit, encryption of stored data and genuine end-to-end encryption address different risks.

A properly designed platform should understand the difference.

Built for resilience

Another major improvement has been separating the different jobs involved in handling email.

Incoming and outgoing messages pass through a dedicated UK-based mail gateway before reaching the main mailbox platform. This creates a useful boundary between the public internet and the systems actually holding users’ mail.

Individual components can be maintained, upgraded or ultimately replaced without redesigning everything around them.

That’s one lesson which twenty years of administering other people’s infrastructure tends to reinforce:

Avoid creating a single magic box on which everything depends.

We’ve demonstrated that principle during this upgrade.

Rather than scheduling a dramatic migration weekend, crossing our fingers and replacing everything at once, the new infrastructure has been introduced alongside the live service.

Mail continued to flow while the platform underneath it evolved.

Security that increasingly looks after itself

A surprising amount of running a good email service happens somewhere users never see: DNS.

SPF, DKIM and DMARC help other mail systems establish whether a message claiming to come from your domain really did.

MTA-STS helps protect email while it’s travelling between servers. TLS certificates establish the identity of servers and encrypt connections made by users and applications.

Historically, operating all of this across multiple domains meant maintaining a rather tedious collection of DNS records, signing keys and certificates.

We’ve now automated much of it.

The platform can automatically publish and maintain the appropriate mail-related DNS configuration for the domains it hosts. Cryptographic signing keys can be managed automatically. TLS certificates are obtained using secure DNS-based validation and renewed automatically.

Our primary service domain now uses an automatically managed certificate covering the services beneath it, meaning changes to the infrastructure don’t require somebody to remember to rebuild a certificate manually.

Automation isn’t just about saving administration time.

Every repetitive manual task you eliminate is also one fewer opportunity to make a mistake.

Cloudflare at the edge — but not in your mailbox

We’ve also changed how the web-facing parts of the platform reach the internet.

Services such as webmail, automatic account discovery and the newer mail, calendar and contacts interfaces can make use of Cloudflare at the web edge, while the actual email infrastructure remains independently operated.

That’s an intentional distinction.

We’ll use third-party infrastructure where it provides a genuine advantage. We don’t need to surrender the entire service — and all the data stored within it — in order to benefit from it.

The mailbox platform remains ours. The mail gateways remain under our control. Where data lives and how the system operates remain decisions we can make.

Not anti-cloud — pro-choice

Having administered Exchange, Zarafa/Kopano, Microsoft 365, Google and now our own platform, I’m certainly not going to claim that there’s one universally correct way to run email.

Microsoft 365 can be an excellent choice. So can Google Workspace. For some organisations, they are absolutely the right answer.

But “sign up for Microsoft 365” shouldn’t be the only answer.

Cloud platforms exchanged one collection of problems for another. They removed much of the burden of maintaining servers, but introduced recurring per-user costs, dependence on enormous third parties, changing product strategies and a steadily growing concentration of organisational data in the hands of a few providers.

The experience of running all of those different generations of mail system is one of the reasons The Cuckoo Camp platform exists.

We’ve been able to take ideas that worked well in corporate systems, lessons learned from open platforms, the convenience people now expect from cloud services, and the flexibility offered by modern open standards.

Then build something appropriate for the people we actually support.

What this means for our clients

Most clients don’t need to know about JMAP, DNS challenges, DKIM signing, mail gateways or any of the other work that’s gone into the platform.

In fact, that’s rather the point.

What they should see is professional email using their own domain; modern webmail; synchronised contacts and calendars; straightforward account configuration; strong authentication and encryption; infrastructure built predominantly around open standards; and somebody they can actually speak to when something isn’t working.

This isn’t a theoretical exercise in whether independently operated email could work.

We’ve already been doing it successfully for more than two years.

The difference is that we’ve now taken everything learned from those two years — combined with more than twenty years of experience administering corporate, open and cloud email systems — and applied it to the next generation of the service.

There will be more improvements. There always are.

But this is an important milestone.

We didn’t rebuild the platform because the old one failed.

We rebuilt it because it succeeded, because running it showed us where it could be better, and because decades of working with other people’s approaches to email have left me convinced of something fairly simple:

We can do it better.

← Back to blog