Email in your own cloud storage: how bring-your-own-storage works

Bring-your-own-storage (BYOS) email is email hosting in which a service receives, authenticates and encrypts your messages, then writes them into storage you own — an S3 bucket in your own cloud account, a Cloudflare R2 bucket, a WebDAV server in your basement, even a Git repository. The provider keeps the parts that have to live on the public internet: MX records, SPF, DKIM and DMARC verification, spam filtering, sending reputation. The stored bytes land in your account, on your billing relationship, in the region you picked.

Nobody searches for the phrase yet. I am naming it anyway, because the arrangement is real, more than one team is now building it, and neither “encrypted email” nor “self-hosted email” describes what it does.

Why does BYOS email exist?

Because encryption and custody are two different problems, and the industry mostly solved the first one. Zero-access providers encrypt incoming mail so that they cannot read it, which is a genuine advance and I don’t want to undersell it. The ciphertext still sits on their disks, in their datacenter, under their corporate jurisdiction, reachable only through their account system.

That residue matters in ways encryption cannot touch. A suspended account takes your archive with it even though the bytes are perfectly safe. Jurisdiction follows the company rather than the hardware: the US CLOUD Act, in force since 2018, obliges a US-incorporated provider to produce data it controls no matter which country the disks are in. Acquisitions, repricing and shutdowns all resolve the same way — you negotiate from a position where someone else is holding twelve years of your correspondence.

Storage custody is the other half. Move the bytes into an account you own, and “can they read it” and “can they keep it from me” stop being the same question.

What changes in practice when mail lives in your own storage?

Four things get concretely easier: backup, migration, jurisdiction, and surviving your provider.

Backup stops being a feature you wait for. Object versioning, lifecycle rules into a cold tier, a nightly rclone sync to a second provider — the same tooling you already point at everything else in that bucket. No export job, no support ticket.

Migration becomes a re-point instead of an extraction. The archive doesn’t move when you change routing providers; only the thing writing into it does.

Jurisdiction turns into something you specify rather than something you accept. It is two choices, not one: the region the bytes physically occupy, and the country where the storage operator is incorporated. Region is not jurisdiction — an EU region run by a US company is still reachable under US law — and BYOS lets you set both.

If the routing service disappears next month, you lose an interface, not a decade of mail. That asymmetry is the entire argument.

Is BYOS email the same as self-hosting a mail server?

No, and the difference is the ops burden. Self-hosting means you run the SMTP stack yourself: Postfix or a container equivalent, Dovecot, a spam engine, certificate renewal, blocklist monitoring, reverse DNS, IP warm-up, and the steady trickle of small work that keeps mail flowing. BYOS moves the storage and leaves the mail server with someone whose job it is.

The split follows the failure modes. Losing your data is permanent; a badly tuned spam filter is a Tuesday. Outbound deliverability especially is decided by other people’s reputation systems — a fresh IP on a small block gets greylisted or refused by large receivers regardless of how correct your configuration is, and no amount of skill makes a cold IP warm quickly.

Control of the data without running the daemon. For most people who tried self-hosting and gave up, that was the part they actually wanted.

What does BYOS email not solve?

Transport metadata, spam, deliverability, and the trust you place in whoever runs the routing. None of them improve because your archive moved.

SMTP negotiates in the open between hops. Envelope addresses, timestamps and the path a message took are visible to every relay that handles it. Storage custody changes where a message rests, not how it travelled.

Filtering needs to read the message, so it happens in the routing service, before encryption at rest. There is a moment when your plaintext exists in someone else’s memory. A provider that filters your spam and also claims to never see your mail is describing something that cannot work.

Your correspondents’ copies aren’t yours either. You own your archive; the copy sitting in their Gmail is Google’s business.

Custody also transfers responsibility along with power. A permissive bucket policy publishes your mail. A deleted bucket deletes your mail. Nobody is going to restore it from the backup you didn’t take.

What should you check before pointing mail at your own storage?

Four questions, in the order I would ask them.

Who holds the encryption key, and who holds the bytes? These are separate. A service can write ciphertext into your bucket while keeping the key on its own servers so it can render your mailbox in a browser — a defensible design, but not the same thing as holding both.

What happens when your storage is unreachable? Expired credentials and rate limits are normal operating conditions. The answer you want is that the receiving edge refuses to acknowledge delivery until the message is stored, so the sending server’s own queue retries. The answer you don’t want is a silent drop.

What will the bucket actually cost you? Per-request charges and egress fees, not the per-gigabyte headline, are what make small-object workloads expensive.

Is the on-disk layout documented? If the only software that can read your archive is the provider’s own, you own the bytes and not the mail. I would check that one first.