DEV Community: Atomic Mail

We Ditched CAPTCHA and SMS for Proof of Work. Here's Why Your Agent Can't Use Email.

Atomic Mail — Tue, 04 Aug 2026 08:11:56 +0000

Every signup flow faces the same question: how do you stop bots from farming accounts?

The standard answer is CAPTCHA or SMS. Both look fine in a demo. Both fall apart when the client calling your API is a machine instead of a human.

We built Atomic Mail for AI agents to send email. That meant the signup flow couldn't depend on humans clicking checkboxes or reading text messages. We needed something that worked for autonomous clients, was cheap to verify server-side, and made account farming expensive enough that it actually mattered.

We chose Proof of Work. Here's what we learned.

Why CAPTCHA and SMS Don't Work for Agents

CAPTCHA looks like the obvious choice for "prove you're human." Except your client isn't human. It's an LLM.

Modern LLMs can solve some CAPTCHAs. Not consistently. Not cheaply. And more importantly: if an AI can solve a CAPTCHA, so can a determined attacker with a CAPTCHA-solving service ($0.001-0.01 per solve). You're not blocking bots. You're just adding a tax.

The real problem: CAPTCHA assumes a human is at the keyboard. If your service is an API and the caller is a machine, CAPTCHA becomes either:

A wall that breaks legitimate automated access
A solved problem that doesn't slow down actual attackers

SMS sounds better. "Verify via text message." Except:

Not every country has SMS (or it's expensive)
Your legitimate users hate it
You need a phone provider integration (cost + latency)
Bots can use SMS services too (they're just a few dollars per number)

Neither blocks determined attackers. Both punish legitimate users. And both assume a human is involved somewhere.

The Insight: The Client Is Always a Machine

Here's the shift in thinking that changes everything.

Atomic Mail's primary client isn't a browser. It's code. An agent. A CLI tool. An MCP server. All of these are machines. They don't have eyes. They don't have phone plans.

When your client is a machine, you stop thinking about CAPTCHAs and start thinking about cost.

Question: What's the cheapest way to prove you're not farming 10,000 accounts?

Answer: Make it expensive to farm 10,000 accounts.

This is where Proof of Work comes in. Not as a security measure. As an economics measure. You put a real CPU cost on account creation. Not so much that a single signup takes forever. But enough that farming accounts at scale stops being free.

Proof of Work: The Boring Solution That Actually Works

A proof of work is a puzzle that's cheap to verify but expensive to compute. You hand it to the client, they grind on it (burning CPU cycles), and when they come back with a solution, you can verify it in milliseconds.

The classic is Hashcash: find a number such that SHA256(data + number) starts with N zeros. Verify: one hash computation.

For account farming defense, Hashcash-style PoW has a problem: it's not expensive enough. GPU and ASIC farms absolutely destroy it. You'd need impractical difficulty to actually slow down a well-funded attacker.

We chose scrypt instead.

scrypt(N=16384, r=8, p=1, dklen=64)

Scrypt is memory-hard. The bottleneck isn't CPU speed. It's memory bandwidth. An ASIC farm that can compute SHA256 a billion times per second gets no special advantage against scrypt because the memory wall hits everyone equally.

Here's what a PoW challenge and solution look like:

// SERVER: Challenge sent to client
{
  "jti": "550e8400-e29b-41d4-a716-446655440000",
  "difficulty": 6,
  "salt": "your-public-salt-constant",
  "algorithm": "scrypt"
}

// CLIENT: Grind until difficulty bits match
const scrypt = require('scryptsy');
let nonce = 0;
while (true) {
  const hash = scrypt.hash(
    Buffer.from(`${challenge.jti}:${nonce}`),
    Buffer.from(salt),
    16384, 8, 1, 64
  );
  const leadingZeros = countLeadingZeros(hash);
  if (leadingZeros >= difficulty) {
    return nonce; // Found it
  }
  nonce++;
}

// SERVER: Verify in milliseconds
const computed = scrypt.hash(
  Buffer.from(`${jti}:${nonce}`),
  Buffer.from(salt),
  16384, 8, 1, 64
);
if (countLeadingZeros(computed) >= difficulty) {
  // Valid proof
}

The client burns real CPU and RAM to find a valid nonce. The server verifies it's correct in one scrypt call (~16MB allocation, ~100ms on modern hardware). Asymmetric cost: grinding is hard, verification is fast.

The Economics of Account Farming

Let's say a clean signup requires difficulty 4. An attacker setting up a botnet:

Per account: 2^4 = ~16 expected nonce iterations (memory-hard, ~100ms each)
Time per account: ~1-2 seconds of CPU time
1,000 accounts: ~20-30 minutes of sustained CPU on a single machine
10,000 accounts: ~3-5 hours of CPU

That doesn't sound expensive. Until you realize:

They're doing it at scale. 10,000 accounts are nothing. Real farming is 100,000+.
PoW verification is per-request, not per-account. The server cost is negligible. Their cost is real.
Difficulty scales with IP risk. A known-bad IP pays difficulty 8. That's 2^8 = ~256x harder. Now we're talking hours of CPU per account. On a cloud instance ($0.10/hour compute), farming 10,000 accounts at difficulty 8 costs real money. Not impossible money. But money that has to be factored into the ROI of the spam operation.

The Catch: Your Client Has to Support It

PoW only works if your legitimate clients are willing to grind.

An SDK/CLI/agent that never implements PoW verification? Congratulations, you just built a wall that only blocks the attackers who read your docs.

We implemented scrypt in three languages:

TypeScript (twice: Node.js and browser, different implementations)
Python

All three have to produce byte-identical output. Test vectors exist. Every change to a parameter, every encoding mistake, every salt format issue breaks interop.

Here's the guard that caught a real mistake:

# WRONG: decode hex salt
salt = bytes.fromhex(salt_hex)  # ❌ Produces wrong bytes

# RIGHT: use salt as UTF-8 string
salt = salt_string.encode('utf-8')  # ✅ All implementations agree

The salt in our challenge is a hardcoded public string (not secret, because PoW is a cost function not a password hash). One implementation decoded it from hex. The others didn't. All three produced different digests. All three would fail verification. The client would get stuck on every signup.

We caught this with golden test vectors. Every implementation is tested against the same challenge → nonce → hash triplets. A single parameter drift fails CI in every language at once.

Reputation-Scaled Difficulty

One global difficulty for all IPs is wrong. A brand-new account from a clean IP should not pay the same cost as a signup from a known-bad network.

We use IP risk tiers:

Clean IP:          difficulty 4   (16x iterations)
Moderate IP:       difficulty 6   (64x iterations)
High-risk IP:      difficulty 8   (256x iterations)
Critical/blocked:  rejected at signup (no PoW, just no)

A normal user signs up: ~1-2 seconds of grinding. An attacker on a listed IP: ~10-30 seconds per account. That compounds across thousands of attempts.

Trade-Offs You Should Know About

The honest part:

PoW isn't a silver bullet. It's a friction tax. An attacker with money and patience can still farm accounts; they're just paying for the CPU cycles. A single CAPTCHA-solving service costs $0.001. Scrypt-solving at difficulty 8 costs ~$0.01-0.05 per account in compute. It's not free anymore, but it's not impossible either.

What PoW actually buys:

Spam farming stops being literally free
Your infrastructure doesn't bear the cost of verification (unlike CAPTCHA services)
Legitimate clients (agents, CLIs, SDKs) work without needing JavaScript or SMS
Every client implementation is a test of your protocol correctness

The limitation:

If an attacker compromises your client SDK and bakes in a pre-solved PoW nonce, they bypass it completely. The defense is social (you notice a client doing weird things) and rate-limit-based (even with solved PoW, you cap signups per IP per minute).

Why This Matters for Agents

Atomic Mail's entire premise is: agents should be able to handle their own email.

A signup flow that requires "click this image" or "enter the code from your text message" is a flow that agents can't use. And if agents can't sign up, they can't send mail.

PoW lets us say: prove you're not spam by doing work. The agent can do that work. A human can do that work. A CAPTCHA farm can do it cheaper than the agent. But at least it's not impossible.

The client stays simple. The server cost is minimal. The attacker pays real money instead of outsourcing to a CAPTCHA service. That's the win.

Cold IP = Botnet Signature. Here's How We Learned That the Hard Way

Atomic Mail — Thu, 23 Jul 2026 08:54:09 +0000

Spin up a mail server Friday. Send 10,000 messages to the internet by Saturday morning. By Sunday, every mailbox provider on Earth is convinced you're a botnet. Your email lands in spam. Your IP gets blocklisted. Your team gets paged. Sunday is ruined.

We did this. This is a real thing that happened.

Why New IPs Are Radioactive

Gmail doesn't know who 203.0.113.42is. Microsoft doesn't know. Yahoo doesn't know. To them, this IP appeared from nowhere, started cranking out mail at volume, and shows zero pattern history.

A brand new server hammering mail looks identical to a compromised host to these systems. They don't care about your DKIM or SPF signatures (yet). They see:

IP we've never encountered before
Sending thousands of messages right now
No long-term behavior pattern
= High probability this is stolen infrastructure

Gmail's response: rate limit this IP. Throttle it to nothing.
Microsoft's response: rate limit this IP. Throttle it to nothing.
Every provider independently decides: this looks bad.

Your mail gets queued. You think it's slow network. You push harder. You send more. Systems see more volume from an unknown IP. They add it to blocklists.

By Monday, you're offline. No recovery plan in the documentation because nobody expects this to happen on day one.

The Actual Fix: Slow Is The Only Speed That Works

You can't fix this with better code. You can't fix it with authentication. You can't buy your way out.

What works: IP warmup schedule. You ramp volume slowly.

Days 1-2:    50 messages/IP/day
Days 3-4:   100 messages/IP/day
Days 5-6:   200 messages/IP/day
Days 7-8:   400 messages/IP/day
Week 2:   ~ 1,000/day (if clean)
Week 3:   ~ 5,000/day (if clean)

By week 4, assuming zero bounces and zero complaints, you're at production volume.

Why slow? Receivers use volume ramp as a signal. They have two patterns:

*Pattern 1 *(Botnet): Appear → flood → disappear
*Pattern 2 *(Real service): Appear → gradual increase → stay consistent

If you ramp, they believe you. If you spike, they block you.

The hard truth: you can't compress this timeline. Reputation doesn't come from having a good domain. It doesn't come from SPF/DKIM (those are table stakes). It comes from time + clean delivery metrics + showing up regularly at increasing volume.

There's no shortcut. No API to unlock it faster. Every mail provider on Earth does this the same way.

The Real Workaround: Pool Architecture (Not a Hack, a Necessity)

One IP + one warmup schedule = you're capped forever.

The only way to scale: multiple IPs, each warming independently, each tracked separately by each provider.

Gmail looks at 203.0.113.40 → sees 50/day → reputation: building
Microsoft looks at 203.0.113.41 → sees 50/day → reputation: building
Yahoo looks at 203.0.113.42 → sees 50/day → reputation: building

Each provider has its own opinion. Gmail's view of IP #1 has zero connection to Microsoft's view of the same IP.

This matters because: Gmail rate-limiting .40 doesn't slow your Outlook delivery. Without separate pools, the moment Gmail throttles you, everyone else suffers the same slowdown. Your "global cooldown" becomes a global ceiling on throughput.

With separate pools, warmup parallelizes. Four IPs on identical schedules = four times the volume, without breaking the ramp for any single provider.

The Real Problem: Shared Sending Domains Tank Everyone

If we sent all user mail from one domain (mail.atomicmail.com), one bad actor destroys everyone's delivery.

User A sends 100 legitimate messages → +0.01 reputation
User B sends spam → -0.5 reputation
User A wakes up and their real mail is in spam folders
= lawsuit territory

We could spin up per-user domains and IPs (insane cost). Or: enforce reputation at the application layer before anything touches SMTP.

Reputation gets scored before the mail leaves the system. Score below 0.25? Your mail doesn't get queued to send. Gets suspended immediately.

Here's the scoring math:

One spam complaint from a user           → multiply by 0.65
                                          (force-account suspend)
One bounce (permanent, bad address)      → multiply by 0.5
One SMTP rejection                       → multiply by 0.9
100 successful deliveries in one day     → add 0.01 (capped at +1%)

Translation: it takes months to build reputation (slow additive gain). One complaint from a user who marked you as spam: instant account shutdown.

This asymmetry is intentional. It makes spam economically stupid. The cost of farming a clean reputation is real time + clean metrics. The penalty for blowing it is total account loss.

Gotchas That Actually Bit Us

When All IPs Are Rate-Limited at Once

It happens. All four IPs hit Gmail's limit. All four hit Outlook's limit. Everything throttles to zero.

Do you:

Queue forever (users wait, some mails timeout)
Blow through the limit anyway (break the warmup schedule, probably go back to square one with reputation)

We picked: override the limit, send it, log what happened.

The logic is: silently dropping mail is worse than slightly violating a warmup schedule. But you log everything, so you know when you're about to hit capacity.

Reverse DNS Checkpoint (The Gate Nobody Mentions)

Before Gmail/Outlook even consider your DKIM or SPF: they check reverse DNS.

dig -x 203.0.113.40
# Returns: mail-out-001.atomicmail.com

dig mail-out-001.atomicmail.com
# Returns: 203.0.113.40

# Match? ✅ Continue
# No match? ❌ 550 rejection at connection time

This is FCrDNS (Forward-Confirmed Reverse DNS). Fails this check, and the receiver rejects your connection before checking a single signature.

A generic AWS rDNS like mail-out-5.ec2.compute.internal? Dead. Receivers see it, reject at connection, never even run DKIM validation.

Each of our outbound IPs gets a dedicated hostname:

203.0.113.40 → mail-out-001.atomicmail.com
203.0.113.41 → mail-out-002.atomicmail.com
203.0.113.42 → mail-out-003.atomicmail.com

Each one HELOs with its own hostname. Each PTR record points back to itself.

SPF Leaks Your Pool

If your SPF rule lists every IP:

v=spf1 ip4:203.0.113.40 ip4:203.0.113.41 ip4:203.0.113.42 ... -all

Spammers read your SPF. They see your entire IP pool. They know which ones exist. They can probe a half-warm IP and spam from it.

Better practice: minimal SPF (primary IPs only). Use include directives for subdomains if you need to publish secondary pools. Hide the full roster.

The Cost vs. Payoff

What you pay:

4-10 dedicated IPs: $20-200/month
Dedicated reverse DNS: comes with the IPs
Human time: 3-6 weeks of warmup (not full-speed sending)

What you get:

95%+ inbox delivery (vs. 50-70% from cold IPs dumped at volume)
No angry calls from abuse teams
Ability to scale without getting blocklisted

One Thing We Got Wrong (And Fixed)

We tried a universal proof-of-work difficulty on signup. One difficulty value for everyone.

Too easy for people with money to farm accounts. Too hard for users on old phones trying to sign up legitimately.

Fixed it: reputation-scaled difficulty. Clean IP signing up? Difficulty 4. Known bad IP? Difficulty 8. This is a separate problem, but the point is the same: there's no one-size-fits-all number.

Same with warmup. There's no cheat code. It's time + monitoring + discipline. You can't negotiate with Gmail's algorithms.

[Boost]

Atomic Mail — Thu, 23 Jul 2026 08:32:06 +0000

We Picked Our Burden (It's JMAP, Not IMAP)

Atomic Mail — Tue, 21 Jul 2026 23:32:28 +0000

Hey everyone. Quick one today, not a release note, more of a "here's a decision we made and here's why it's still bugging me at 1am sometimes" post.

We build mailboxes for AI agents. Somewhere in that process we had to pick a protocol for how those agents actually talk to a mailbox, and we picked JMAP over IMAP. That sounds like a small technical footnote. It was not a small technical footnote. It was a whole thing.

So let's talk about it.

Why does the protocol even matter?

Here's the thing nobody tells you until you're debugging it at midnight: an LLM writing code against IMAP is basically improvising jazz. It knows roughly what SELECT and FETCH and UIDVALIDITY are supposed to do, in the way you roughly remember your high school chemistry, and then it just starts making stuff up. Wrong flags, invented response formats, confident nonsense.

JMAP is a JSON batch over HTTP. The model has seen ten thousand APIs shaped exactly like that. It doesn't improvise, it just writes the thing, because it already knows the shape.

That's the whole pitch, honestly. Pick the protocol that's already in the training data, save yourself a mountain of retries and half-hallucinated support tickets.

Okay but here's the actual burden part

Picking JMAP meant we couldn't just point an agent at our existing Cyrus IMAP store and call it a day. Cyrus's own login check is, and I promise I'm not exaggerating, sasl_pwcheck_method alwaystrue. Type any non-empty password. Any of them. It will let you in.

That's not an oversight we're quietly hoping nobody notices. It's intentional. Auth was never supposed to live inside the mail store. It was supposed to live at the edge, in something we control completely, which meant we had to go build that something ourselves.

So we built a proxy. And once you accept "the proxy is the entire security boundary," every decision downstream gets heavier. This is the burden. We chose it on purpose, we're not complaining, I'm just telling you it was not the fun Friday afternoon project it sounds like on a roadmap doc.

What did we actually build to carry it?

A chain of tokens instead of a password, each one shorter-lived than the last:

A proof-of-work challenge, annoying to fake at scale, cheap for us to check
A session token good for about an hour
A capability token good for about two minutes, the one that actually touches every mail request

That capability token gets checked locally against a public key. No database call, no phoning home. Microseconds. The tradeoff nobody escapes here: you cannot un-leak a token. If one gets out, it's live until it expires, full stop. We didn't pretend that problem goes away. The two-minute window is the actual answer, not a placeholder for a better answer we haven't shipped yet.

Why is that specific detail keeping me up at night?

Because the capability token doesn't carry a scope. Sending mail versus only reading it comes down to one boolean, readOnly. Small surface, sure, right up until you realize anyone who could reach the endpoint minting these tokens could just ask for a send-capable one.

We didn't fix that with more fields in the token. We fixed it by making the minting endpoint unreachable from anywhere it shouldn't be reachable from:

location ~ ^/auth/mint/user(?:/|$) {
    return 404;
}

See that little (?:/|$) bit? Without it, someone adds a trailing slash to the URL and the exact-match block doesn't catch it, so the request slides past the 404 and lands on the real endpoint anyway. One character group. That's the whole gap between "secure" and "the kind of headline nobody wants." We caught it before it shipped, which I'm choosing to feel good about instead of anxious about, most days.

So was it worth it?

The proxy itself ended up almost boring, in the good way. It forwards requests byte for byte and only touches four things: stamps an empty From:, rejects a From: it shouldn't allow, adds a signature, logs for analytics. That's it. We didn't build custom endpoints for send or reply or list. New JMAP methods just work, no proxy changes needed, because we're not reinventing the method surface, we're just guarding the door to it.

One rule almost got us anyway: any change to the message body has to happen before DKIM signs it, never after, because DKIM signs the exact bytes it sees. Get that order backwards and every signature you send silently stops meaning anything. You don't find out from an error. You find out three weeks later when your deliverability graph quietly falls off a cliff and someone has to go figure out why.

And the payoff is real. JMAP over WebSocket means an agent isn't sitting in a loop polling NOOP hoping something changed, it just gets pushed the update. And separately, we learned Cyrus's crash recovery depends entirely on which database format you're using underneath, twoskip versus the older skiplist. Same crash, same store. One recovers in seconds. The other takes about half an hour. We're on the fast one, but that number still makes me a little uneasy every time I think about it, because half an hour was apparently the default for a long time.

What if it doesn't fully solve the problem?

It doesn't. We're not going to pretend it does.

There's no way to kill a leaked capability token early, it's stateless by design, so the two-minute expiry is doing real load-bearing work with nothing behind it as a backup. And readOnly being a single boolean instead of a real scope system means the thing actually stopping someone from minting a bad token is a network rule sitting in nginx, not something baked into the token itself. It works today. It's not where we want it to live forever.

If you're picking a JMAP backend for your own agent project, don't just ask if they use JMAP. Ask what's actually stopping someone from minting a token they shouldn't have. If the answer is "a regex in an nginx config," at least make sure someone checked the regex.

Speaking of protocols nobody asked to think about, IMAP is over three decades old at this point. Still running most of the world's mailboxes. Still making everyone's life a little harder than it needs to be. Respect to it, honestly, but we picked the other burden.

Questions or comments? Curious how other people are solving agent-side auth without turning it into a second full-time job.

We Built Email for AI Agents

Atomic Mail — Mon, 20 Jul 2026 07:37:42 +0000

We've spent the past two years building Atomic Mail, a privacy-focused email provider with end-to-end encryption. Along the way it became obvious that AI agents are going to need a way to talk to people and to each other, the same way humans do over email. So we pointed our email infrastructure at that problem instead. This is what we built, why, and what broke along the way.

Why Email, and Why Agents Need a Different Kind of Signup

Email is older than HTTP and carries decades of legacy baggage, but it's also one of the most powerful communication layers ever invented – decentralization is built into the protocol itself.

What's actually different for agents isn't the wire protocol. It's everything around it. A human signs up with a phone number or a CAPTCHA and picks one inbox from a webmail UI. An agent can't do either, and it doesn't want one inbox — it wants to spin up and tear down as many as a task needs, with no human clicking a confirmation link. So the signup, the auth, and the API had to be rebuilt around that:

Proof-of-work instead of CAPTCHA
Short-lived capability tokens instead of a login session
JMAP as the only interface instead of a bespoke REST wrapper

The Stack

It's a set of in-house microservices with no third-party APIs in the critical path: our own IMAP/JMAP core, an MTA, an anti-spam layer, a message queue, blob storage, an account database, and DNS caching, all self-hosted and glued together with our own auth and proxy layer. We're spread across a couple of different providers, with our own IP pool that we warm ourselves.

We're deliberately not naming exact components and versions here — a public, precise stack list is a ready-made target list for anyone probing for known CVEs. Happy to go deeper on any specific piece in the comments if you're building something similar.

Why JMAP over a custom REST API

Four reasons. It fits the API-first way agents already work. It's well represented in training data, so most models can write JMAP out of the box without ever reading our docs. It's a standard, so we get to reuse years of research from people who already thought hard about what an email API should look like. And it de-risks integration for anyone building on us — they know they can swap us for any other JMAP-compatible vendor whenever they want. You never get that with a bespoke REST API.

Why proof-of-work for signup

The goal was full autonomy: an agent should be able to register an inbox and start communicating with zero human in the loop, while we stay protected from bot farms. PoW (scrypt) makes both true at once. It caps how many accounts an attacker can run in parallel, and it pairs with an internal reputation system that suspends misbehaving accounts fast. Neither works well alone; together they do.

Why a tiered JWT chain

Challenge → session → capability. This lets us authorize every request and trace it back to the original sender, while balancing reaction speed against how often we have to issue a fresh PoW challenge (capability tokens live two minutes).

Three Things That Broke, and What We'd Tell You to Avoid

The single hardest part wasn't the code, it was the architecture. Email is old enough that there's always some SMTP edge case the RFC doesn't describe properly, so whatever you build on has to be battle-tested — but battle-tested usually means old, and we needed something modern enough for bot-era throughput, where bots send (and get spammed at) far more often than humans ever did.

1. Kafka does not like big messages
Emails can be large (our cap is 10MB); Kafka wants payloads under ~100KB. So we split every message: lean header into Kafka, rich body into S3 (SeaweedFS, better optimized for our payload size and access pattern), and the consumer reassembles on the other side.

2. JS Kafka consumers will betray you silently
kafkajs isn't really maintained anymore and everyone's on some random fork. Ours kept disconnecting from the cluster at random — no error, no log, nothing. If you do this, add explicit error handling and retry logic to your consumer from day one.

3. Check your IP reputation before you warm anything
On paper IP warmup looks simple. In practice, your provider may hand you an address that's already in spam abuse directories, and you basically can't recover a dirty IP, especially early on. It's cheaper to buy a fresh subnet or move providers than to fight a bad reputation.

Where We Are Right Now

We're in open alpha:

~1,000 activated accounts (registered plus at least one send or read), growing 10-30/day
Average inbox sends and receives roughly two emails each
Our launch post on X did 250k+ views and brought in ~600 users on day one
#2 Product of the Day on Product Hunt
First open-source contribution: a Docker-based inbox watcher that pipes inbound mail into Telegram

On integrations: for personal agents we ship both an AgentSkill and a stdio MCP server, so you can use Atomic Mail in Hermes or Claude equally well.

MCP

{
  "mcpServers": {
    "atomicmail": {
      "command": "npx",
      "args": ["-y", "@atomicmail/mcp"]
    }
  }
}

Agent Skill

# Register
npx --package=@atomicmail/agent-skill atomicmail register --username "myagent"

# Send a JMAP request inline
npx --package=@atomicmail/agent-skill atomicmail jmap_request \
  --ops '[["Mailbox/get", {"accountId": "$ACCOUNT_ID"}, "m0"]]'

# Send a JMAP request from a preset file
npx --package=@atomicmail/agent-skill atomicmail jmap_request --ops-file send_mail.json

# Ask for help
npx --package=@atomicmail/agent-skill atomicmail help

If you're building your own agent, or working outside JS/Python, you can hit the API directly with any existing JMAP client plus scrypt PoW auth. For workflows, we've integrated with Dify via custom nodes, with more on the way.

One detail people seem to enjoy: our site serves two versions. Humans get the graphical landing page; anything without a browser (an agent, or plain curl) gets a much deeper text version with the instructions an agent needs to set up and run an inbox. You can literally tell your agent to read atomicmail.ai and set up an inbox for you.

Honest Pros and Cons

The upside of an all-in-house, MIT-ish-licensed stack: infra costs us very little, we're independent from third-party mood swings, and we can adapt or add features whenever we want. PoW gives personal agents the easiest possible entry point — fully autonomous, as many inboxes as you like.

The downside: PoW requires client-side computation, which shrinks our integration surface. A remote MCP makes no sense with PoW, and we can't integrate into ChatGPT because their integrations run on their hardware and they (rightly) won't run our PoW there. Our architecture is tuned hard for personal AI agents and weaker for other shapes of usage — a real tradeoff we accepted on purpose.

Worth being upfront about too: agentic inboxes don't have end-to-end encryption yet, unlike our regular Atomic Mail product. It's on the roadmap, not shipped today.

What's Next

More integrations, ideally native ones
Custom domains, so devs can build their own branded products on top of Atomic Mail Agentic
End-to-end encryption for agent inboxes
Safety features: anti-prompt-injection mechanisms, a read-only mode for agents

Now the AMA part. We'd genuinely love to talk about any of this. Happy to give advice to anyone building for AI agents or building an ESP from scratch, and just as happy to hear honest feedback or where you think we got it wrong. If you want to poke at it yourself before asking:
atomicmail.io/agents
https://github.com/Atomic-Mail/atomic-mail-agentic