Atmosphere Mail: A Cooperative Email Reputation Layer for atproto#

I moved to atproto because I wanted to own my social graph. The whole self-hosted PDS movement is built on the same instinct: the internet works better when it isn't controlled by a handful of companies.

And then we send email through Gmail.

The problem#

Email is the one piece of infrastructure where self-hosting still effectively requires permission from the big providers. Gmail and Microsoft control something like 75% of the email management market between them, and their spam filters are black boxes that reward volume and punish small senders by default. Perfect SPF, DKIM, and DMARC configuration doesn't help, and neither does years of clean sending history. If the server is small, it's suspicious.

As of November 2025, Gmail now rejects non-compliant bulk sender messages at the SMTP level instead of routing them to spam. They never arrive.

So most people end up dependent on a provider like Proton, Google, Postmark, or SES, and that dependency carries real risk. If Proton decides it doesn't like something about your mail, or Google bans your account, you can lose access to your email irrevocably. Years of correspondence, contacts, business records, gone. Not because you did anything wrong with your server, but because you were reliant on someone else's infrastructure and someone else's rules.

The usual advice in the self-hosting community is to accept this and route through a relay service. That works, but it just shifts the dependency. There should be another path: stop trying to do it alone.

Why atproto changes the math#

The atproto community already has the pieces to build a cooperative email reputation system. They just haven't been connected yet.

PDS operators are already technical, already self-hosting, already controlling their domains, and already carrying cryptographic identity through DIDs. The trust bootstrapping problem that killed PGP's Web of Trust barely applies here because the starting population is a federated community that shares infrastructure and norms.

atproto has the right primitives too. DIDs provide persistent, cryptographically-bound server identities. Domain handles prove domain control via DNS, which is the same mechanism email authentication uses. The labeling system lets anyone publish signed attestations about any DID. Custom lexicons allow new record types that any PDS can store and any indexer can consume.

But the strongest argument for cooperation is volume. A typical PDS operator sends maybe 5 to 50 emails a day: verification codes, password resets, notifications. Google Postmaster Tools doesn't even display reputation metrics until a domain sends around 250 messages per day. Below that threshold, you're flying blind: Gmail is making decisions about your mail, but you can't see what those decisions are or why. No individual operator will ever hit that number. Fifty operators pooling transactional email through a shared relay gets to 250 to 2,500 emails a day, which is enough to get visibility into your own reputation and enough to start building it deliberately. The math only works collectively.

How it works#

There are three layers.

Attestation is the trust layer. A custom lexicon (something like community.email.attestation) lets PDS operators publish signed records about their mail server setup: domain, MX records, DKIM key fingerprints, membership status. A cooperative labeling service checks the DNS configuration and applies labels to member DIDs like verified-mail-operator, clean-sender, or probation. These labels are signed, public, and auditable. Any atproto service can consume them via subscribeLabels.

This is similar to VBR (Vouch By Reference, RFC 5518), except VBR assumed a handful of commercial vouching authorities. This replaces them with a cooperative of peers.

Relay is the sending layer. New members route outbound email through a shared SMTP relay pool: a small cluster of Stalwart or Maddy instances on providers like Linode or Hetzner, which block port 25 by default but will unblock it on request once proper DNS authentication is configured. Each member signs with their own DKIM domain, so domain reputation builds independently even on shared IPs. The relay pool handles IP warming, volume management, and the cold-start problem that makes individual self-hosting so difficult.

As members build their own domain reputation over time, they can start sending directly from their own infrastructure while staying in the cooperative for attestation and monitoring. The relay is training wheels, not a cage.

Enforcement keeps the whole thing clean. ROOST's Osprey, an open-source rules engine that processes over 50 million events per day across production environments including Bluesky's Trust & Safety, fits here naturally. It's event-agnostic: feed it JSON events, write rules in its DSL, and it outputs verdicts. The osprey-atproto package already demonstrates the pattern of firehose to Kafka to rules engine to effector to label actions.

For email, the pipeline is: SMTP events (sends, bounces, complaints) flow into Kafka, get evaluated by Osprey rules, and come out as reputation labels on member DIDs plus MTA-level enforcement like throttling or suspension. Bounce rate over 5% triggers a warning. Spam complaints over 0.1% trigger probation. Repeated violations mean suspension from the shared relay.

Everything is transparent. Members can see exactly why their status changed and what needs fixing. The investigation UI gives the governance committee tools to review edge cases.

What this isn't#

This doesn't replace SMTP, involve a blockchain, or petition Google for special treatment.

Gmail's reputation system is behavioral. If the cooperative sends clean mail and recipients on Gmail open it, reply to it, and don't mark it as spam, Gmail's algorithm figures that out on its own. No permission needed, just enough real engagement from real people that the system notices.

Let's Encrypt didn't beat the paid certificate authorities. They made the question "should I encrypt?" irrelevant by making it free and automatic. That's the model here.

Why now#

The atproto ecosystem is reaching the size where this becomes practical. Self-hosted PDS deployment keeps getting easier. IndieSky is coordinating independent PDS operators and funding infrastructure projects. NorthSky is running cooperative PDS hosting in Canada. The independent operator community is small but growing and motivated.

Gmail's November 2025 enforcement changes actually help. Bulk senders now face SMTP rejection if SPF, DKIM, and DMARC aren't configured correctly, and the requirements are tightening for everyone. If all that setup is mandatory anyway, joining a cooperative that also handles reputation is barely any extra work. And every time the big providers tighten the rules, more operators start looking for alternatives.

The infrastructure exists too. ROOST's Osprey and the atproto labeling system provide enforcement and attestation without building from scratch. What's needed is event models, rules, and integration glue, not a new framework.

The plan#

Phase 0 is pure atproto work. Define the community.email.attestation lexicon. Deploy a labeler that checks DNS configuration for PDS operator domains and applies verification labels. No email infrastructure needed yet, and useful on its own.

Phase 1 is the relay. Stand up a few mail server instances on Linode or Hetzner. Onboard 20 to 50 founding PDS operators. Start IP warming with their combined transactional volume. Each operator signs with their own DKIM domain. Basic abuse monitoring from day one.

Phase 2 hooks up Osprey. Connect SMTP event streams to Kafka. Write the reputation rules. Deploy the labeler as an automated enforcement system. Build the feedback loop so problems lead to throttling, notification, and a clear path back to good standing.

Phase 3 packages a lightweight mail server (Maddy runs at about 15 MB of RAM with zero port conflicts against a PDS) as a Docker sidecar. Operators who want local inbound mail add one container to their docker-compose. DNS gets configured automatically.

Phase 4 builds the community allowlist. An AppView indexes attestation records from the firehose and turns them into DNSBL-compatible zone files. Any MTA that supports DNS-based lookups (Postfix, rspamd, SpamAssassin) can use it natively.

Security, privacy, and what's honest about the trust model#

The email authentication layer (SPF, DKIM, DMARC, MTA-STS, DANE) is industry standard. DKIM means messages are cryptographically signed by the sending domain. TLS in transit is mandatory. The mail servers this builds on (Stalwart, Maddy) are modern, actively maintained, and support the full authentication stack. None of this is weaker than what Gmail or Proton does at the protocol level.

The shared relay is where it gets nuanced. Routing outbound mail through cooperative infrastructure means the relay operators can see mail metadata: sender, recipient, timestamps, message size. This is the same trust model as using Postmark or SES or any other relay service, just with a co-op instead of a company. It's not worse than the status quo for anyone already using a third-party relay, but it's not zero-trust either. Members need to trust the relay operators, which is part of why democratic cooperative governance matters here.

The more interesting question is around reputation data. Today, atproto labels are public. If a member gets a probation label on their DID, the entire network can see it. That transparency is great for accountability, but it means sending reputation becomes public information. For some operators that's fine. For others it could be a problem.

This is where atproto's Permissioned Data work becomes directly relevant. The Spring 2026 atproto roadmap, published in late March, announced Permissioned Data as a major protocol focus for the summer. Multiple teams are working on implementations in parallel, including Blacksky, NorthSky, and Habitat, and a sketch design from the Bluesky protocol team is being discussed at ATmosphereConf in Vancouver. Permissioned Data means non-public records with access control, stored on the PDS but not broadcast through the public relay. Only authorized parties can access them.

For Atmosphere Mail, this opens up a layered approach. Public labels could be limited to positive signals: verified-member, cooperative-participant. These are things members would want visible. Detailed reputation data (bounce rates, complaint metrics, warnings, probation status) could live in Permissioned Data, accessible only to cooperative members and the enforcement system. This gives the cooperative the internal visibility it needs to maintain sending quality while keeping sensitive operational data out of the public network.

This work isn't production-ready yet, so the initial implementation would need to be thoughtful about what goes in public labels versus what stays in cooperative-internal systems. But the protocol is moving in exactly the right direction for this use case, and building with Permissioned Data in mind from the start means the cooperative can adopt it as soon as it ships.

On the E2EE front, Germ has already launched as the first end-to-end encrypted messenger on atproto, using MLS (Messaging Layer Security, an IETF standard). The Bluesky team has signaled that on-protocol DMs and E2EE group chat will follow after Permissioned Data ships. For cooperative governance communications (voting, dispute resolution, sensitive member discussions), E2EE channels built on these same primitives would be a natural fit.

Risks#

Gmail might not care. The cooperative could work well for member-to-member delivery and still struggle with Gmail inbox placement. The realistic floor is "much better than going it alone," and the ceiling depends on how far the ecosystem scales.

Governance will be hard. One bad actor spamming through the shared relay poisons everyone's reputation. Strict vetting and fast ejection aren't optional. Postmark proves this model works commercially, but making it work cooperatively is the open question.

Abuse moves faster than enforcement. A single spam run from a shared IP can damage reputation in minutes. The Osprey rules pipeline handles detection and labeling, but the relay itself needs real-time rate limiting and automatic suspension at the MTA level before the rules engine even sees the event. This has to be right from day one.

Microsoft is the other gatekeeper. The doc focuses on Gmail, but Outlook.com and M365 use different reputation mechanics and their Smart Network Data Services program is less transparent. A cooperative that solves Gmail delivery but not Microsoft solves half the problem. Both need to be addressed in parallel.

It might stay small. A few hundred self-hosters vouching for each other matters to those people but is invisible to Gmail. Whether that's enough depends on how the atproto ecosystem grows. That bet looks better every month, but it's still a bet.

None of this is a reason not to build it, just a reason to go in with clear expectations.

How it pays for itself#

Members pay a small monthly fee, enough to cover relay infrastructure, DNS, monitoring, and abuse management.

The value proposition is what Postmark and Mailgun already sell: emails that actually arrive. The difference is collective ownership. Members control the infrastructure, the reputation, and the governance, and if someone leaves, their domain reputation goes with them.

Surplus goes back into infrastructure, not shareholder returns. If it outgrows membership fees, organizations like NLnet and the Sovereign Tech Fund exist for exactly this kind of project.

Get involved#

The research is done and the technical approach is viable. What's missing are the people: PDS operators, mail server ops, atproto developers, and anyone who cares about cooperative governance. If that's you, reach out. The first real milestone is a lexicon spec and a relay with twenty operators behind it.

If I'm wrong about something here, I'd rather know now than after standing up the first relay.

Author#

Scott Lanoue (@scottlanoue.com)