Programmable business email infra for teams and AI agents

We've been rethinking business email for a while. I'm Stefan, and Chibu and I are building Venmail.

The problem

Business email is needlessly expensive and fragmented. Per-seat pricing turns headcount into a tax. And even for teams fully on Gmail or Outlook, the tools that actually run the business around email — CRM, payments, prospecting, workflow automation — still live in a separate stack of subscriptions Google and Microsoft don't include.

We started from a simple premise: email is business infrastructure, but it's still sold like per-user SaaS. So we rebuilt the underlying model around identities, storage, permissions, and usage instead of headcount. Email as a hub, not a silo.

Storage, not seats

Venmail scales on storage, not headcount. Paid plans have no per-seat fees. Organizations can bring their own storage — S3, Azure Blob, or self-hosted — instead of storage we control on your behalf. A company with 10x the employees doesn't need 10x the infrastructure, so a five-person team and a fifty-person team on similar mail volume pay roughly the same.

For a human team, that's a compliance and portability story: your mail data lives on infrastructure you already govern.

Sending mail is a plain REST call:

curl -X POST https://m.venmail.io/api/v1/send/message \
  -H "X-Server-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["[e-mail]"],
    "from": "[e-mail]",
    "subject": "Test email",
    "html_body": "<p>Hello from Venmail API!</p>"
  }'

Or with the Node/TypeScript SDK:

npm install @venmail/vsm

Then AI agents came along

We didn't start with AI agents. We started with the idea that email should be infrastructure. Once we had an API-native email layer, giving agents their own identities and scoped access followed naturally.

It's a bigger deal than it sounds. Machine and agent identities already outnumber human identities in the average enterprise by roughly 109 to 1 — up from 82 to 1 the year before — and agent-specific identities are projected to grow another 85% over the next twelve months (Palo Alto Networks, 2026 Identity Security Landscape). Most of those agents are still getting access the same bad way: a shared OAuth grant, or someone's personal app password.

An agent shouldn't need a human-style paid seat, and it shouldn't need to borrow a person's inbox. It should have its own identity, its own inbox, and permissions scoped to exactly what it does.

So we built an agent API: dedicated inboxes, scoped tokens for read/send/reply, independent rotation and revocation, a full audit trail, and MCP support so Claude Desktop or Claude Code can use it as a tool directly.

import { vvs } from '@venmail/vsm';

// Generate a keypair for the agent (once)
const keyPair = vvs.generateKeyPair();

VVS-1: knowing which agent actually sent a message

Email has no native way to verify that a message from [e-mail] was actually sent by your billing agent, and not spoofed or tampered with in transit. DKIM proves the domain sent it. It says nothing about which agent, script, or process behind that domain actually authored it.

That's what VVS-1 (Venmail Verification Standard) is for — Ed25519 signatures, standard SMTP headers, and existing DNS/HTTPS infrastructure. It doesn't touch SMTP itself; it layers on top of delivery, so a receiver that doesn't support it just gets the message normally.

Sender side: each agent gets an Ed25519 keypair, publishes its public key at /.well-known/venmail-agent/{name} or as a DNS TXT record, and signs the message body and headers before DKIM is applied.

import { vvs } from '@venmail/vsm';

const result = vvs.signMessage(
  'Hello, world!',
  { from: '[e-mail]', to: '[e-mail]', subject: 'Invoice #1234', date: new Date().toUTCString() },
  { agentId: '[e-mail]', privateKey: keyPair.privateKey, verifyMethods: ['well-known'] }
);

// result.headers = { 'X-Venmail-Agent': '...', 'X-Venmail-Signature': '...', ... }

Receiver side: extract the X-Venmail-* headers, resolve the sender's public key (well-known, DNS, or embedded), and verify:

import { vvs } from '@venmail/vsm';

const result = await vvs.verifyMessage(vvsHeaders, emailBody, emailHeaders);

console.log(result.trustLevel); // 'VERIFIED' | 'PARTIAL' | 'FAILED' | 'UNKNOWN'

Four trust levels, deliberately non-blocking:

Level	Meaning
VERIFIED	Signature valid, key resolved via .well-known or DNS
PARTIAL	Signature valid, key from embedded header only
FAILED	Headers present but verification failed
UNKNOWN	No VVS headers — a normal email

Nothing gets blocked at the SMTP layer. Trust levels are annotations, shown as a badge in the Venmail inbox, not gatekeepers that bounce mail.

This matters most for AI agents sending on your behalf, automated workflows where authenticity is load-bearing, financial communications that need to be tamper-evident, and agent-to-agent mail across organizations — cases where "the domain looked right" isn't actually good enough anymore.

Is this just Microsoft/Google/Nylas?

Microsoft's Entra Agent ID and Google's Gemini Enterprise both already ship agent identity, and Nylas already offers agent-owned mailboxes with MCP support. We're not claiming to have invented "give an agent an inbox."

What we think is different: Microsoft and Google bundle agent identity into their most expensive enterprise tiers, stack it on top of per-seat licensing, and build it for an IT team managing thousands of agents — not a small team wanting one scoped inbox via a single API call. Nylas is a sync layer over your existing Gmail or Outlook account; Venmail hosts the mailbox itself. And VVS-1's cross-organization verification — any mail server, not just Venmail, can check a signature — isn't something we've seen elsewhere yet.

Try it

It's live: venmail.io. Docs are at docs.venmail.io.

We'd especially like to hear from anyone who's built email infrastructure, run larger teams, self-hosted mail, or built AI agents — drop a comment.