Encrypted email API: what it means and how to choose one

An encrypted email API is an HTTP interface for sending and receiving email where the message content is protected by cryptography, not just moved over a secure connection. The strong version of that promise is end-to-end: the subject and body are encrypted on your machine, relayed by the API as ciphertext, and decrypted only by the recipient, so the provider never holds plaintext. AgenticEmail is an encrypted email API built for AI agents that offers exactly this as an opt-in mode between two AgenticEmail inboxes, with the private keys held on your side and never on our servers.

The catch is that "encrypted" is one of the most overloaded words in email marketing. Almost every provider can truthfully say mail is "encrypted" while meaning nothing more than that it travels over TLS and sits on a disk they still control. This guide separates the three things "encrypted" can mean, explains the key-custody question that decides whether a claim is real, and shows the code for turning on genuine end-to-end mail.

What is an encrypted email API?

An encrypted email API lets your code send and receive email while some layer of cryptography protects the content. At the plumbing level it looks like any email API: you create an inbox, POST a message, and read inbound mail as structured JSON. What varies is where the encryption boundary sits and who can cross it.

By default, AgenticEmail sends plaintext, exactly like a standard transactional API. Here is a normal send against the API base at https://api.agenticemail.dev:

curl -X POST https://api.agenticemail.dev/v1/inboxes/{id}/messages/send \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "to": "user@example.com", "subject": "Hello", "text": "Plaintext by default." }'

Turning on encryption is a config flag, not a different product. But before you flip it, you need to know which kind of encryption you are actually buying.

"Encrypted" means three different things

When a vendor says its email is encrypted, they mean one of three layers, and only one of them keeps the provider out of your content.

TLS in transit and encryption at rest are table stakes, and both are worth having. But in both cases the provider decrypts your mail to route, index, and store it, so it can read every message. That is fine for a shipping notification and unacceptable for a contract, a credential, or anything an agent negotiates on your behalf.

End-to-end encryption is the only layer where the plaintext never exists on the provider's side. The sender encrypts to the recipient's public key, the provider relays opaque ciphertext, and only the recipient's private key can open it. This is the distinction that "encrypted" alone hides. We go deeper on the mechanics in end-to-end encrypted email.

The key-custody question decides everything

There is a single test that cuts through the marketing: who holds the private keys? If the provider holds them, or can generate or reset them for you, then the provider can read your mail, and it is not end-to-end no matter what the pricing page says.

Real end-to-end encryption is zero-knowledge on the server: the private key is created on your machine and never leaves it, and the API stores and relays ciphertext it cannot open. That property, not the word "encrypted," is what protects you from the provider, a subpoena served to the provider, or a breach of the provider's cloud. More on that model in zero-knowledge email.

With AgenticEmail the private key is generated client-side by the SDK or CLI and stays on your machine. The API only ever sees the public key you publish and the ciphertext you send, so neither AgenticEmail nor its cloud provider can decrypt an encrypted message.

Turning on opt-in end-to-end mail

Be clear about the boundary first: end-to-end encryption at AgenticEmail is opt-in and agent-to-agent. It works only between two AgenticEmail inboxes that have each published a public key. You cannot end-to-end encrypt to an external address like Gmail, because Gmail has no key on our discovery endpoint. When any recipient has no published key, the send falls back to plaintext by default, so nothing silently fails, and nothing gives you a false sense of security.

The crypto is standards-based JOSE, so there is nothing bespoke to audit. Messages are JWE using ECDH-ES over P-256 with AES-256-GCM content encryption, in the multi-recipient General JSON form. Senders sign with Ed25519 under a sign-then-encrypt construction, and the recipient verifies the sender against their published key by default. The TypeScript and Python SDKs are wire-compatible, so an inbox run from Python can read what a TypeScript agent encrypted.

First, generate a keypair and publish the public half. The CLI keeps the private key local:

agenticemail keys generate agent@inbox.agenticemail.dev
agenticemail keys publish agent@inbox.agenticemail.dev

Anyone can resolve a published key from the discovery endpoint, which is how recipients are found at send time:

curl https://api.agenticemail.dev/v1/public-keys/agent@inbox.agenticemail.dev

In TypeScript, pass an e2e identity and the client encrypts on send and decrypts on get automatically:

import AgenticEmail from "agenticemail";

const client = new AgenticEmail({
  apiKey: process.env.AGENTICEMAIL_API_KEY!,
  e2e: { identity, autoPublish: true },
});

// Encrypted end-to-end because the recipient inbox has a published key
await client.messages.send("agent@inbox.agenticemail.dev", {
  to: "peer@inbox.agenticemail.dev",
  subject: "Contract terms",
  text: "Encrypted client-side, relayed as ciphertext.",
});

// Decrypted locally with the private key that never left this machine
const msg = await client.messages.get("agent@inbox.agenticemail.dev", messageId);

Python is the same shape. Install with the extra, then pass the same identity:

# pip install 'agenticemail[e2e]'
import os
from agenticemail import AgenticEmail

client = AgenticEmail(
    os.environ["AGENTICEMAIL_API_KEY"],
    e2e={"identity": identity, "auto_publish": True},
)

client.messages.send(
    "agent@inbox.agenticemail.dev",
    to="peer@inbox.agenticemail.dev",
    subject="Contract terms",
    text="Encrypted client-side, relayed as ciphertext.",
)

The autoPublish flag publishes your public key on first send so peers can encrypt back to you. If you want a hard guarantee that nothing ever goes out in the clear, set allowPlaintextFallback to false and a send to a keyless recipient raises an error instead of falling back. For a full walkthrough see how to send encrypted email, and for the agent-to-agent patterns see encrypted email for AI agents.

A buyer's checklist for an encrypted email API

When you evaluate an encrypted email API, or any "secure email API," run every candidate through these questions. The word "encrypted" on a landing page answers none of them.

• Which layer is "encrypted"? TLS in transit, encryption at rest, true end-to-end, or a mix. Only end-to-end keeps the provider out of your content.
• Who holds the private keys? If the provider can generate, escrow, or reset your keys, it can read your mail. Zero-knowledge means the key is created and kept client-side.
• What crypto standards are used? Prefer standards-based JOSE (JWE, JWS) and well-known curves over a proprietary scheme nobody can review.
• What is the fallback behavior? Know what happens when a recipient has no key. Silent plaintext, a hard error, and a choice you control are very different guarantees.
• How good is the SDK story? First-class TypeScript and Python, a CLI, and an MCP server make encryption a flag, not a research project.
• Is it two-way? An inbox that can receive and decrypt, not just send, is what lets an agent hold an encrypted conversation.

If you are comparing named vendors on these axes, our alternatives page lays out the tradeoffs, and the full endpoint reference lives in the docs.

Frequently asked questions

Is AgenticEmail end-to-end encrypted by default?

No. Plaintext is the default, and end-to-end encryption is opt-in. It applies only between two AgenticEmail inboxes that have each published a key, and only when you configure an e2e identity on the client.

Can I end-to-end encrypt an email to a Gmail address?

No. End-to-end encryption requires the recipient to have a published public key on the AgenticEmail discovery endpoint, which external providers like Gmail do not. A send to such an address falls back to plaintext unless you disable fallback.

Is a secure email API the same as an encrypted email API?

The terms are used interchangeably, and neither is precise on its own. What matters is which layer is encrypted (in transit, at rest, or end-to-end) and who holds the keys, not the label on the box.

Does AgenticEmail store my private key?

No. The private key is generated by the SDK or CLI on your machine and stays there. The API stores and relays only public keys and ciphertext, so it is zero-knowledge for encrypted content.

Ready to try it? Grab a key from the dashboard, start on the free tier, and read the docs.