Does Your Agent Need a New Inbox? Attaching Email to the Infrastructure You Already Run

There's a new category of product appearing at the moment: agentic mail systems, email infrastructure built specifically for AI agents. The claim is that agents are a new kind of email user, so they need their own inboxes and own APIs. Every time one of these launches, the same question gets asked. Does your agent really need an inbox of its own, and what does agent-specific email infrastructure actually offer over a traditional inbound email provider?

Our answer, most of the time, is that it doesn't need one. Look at what these platforms promise to handle and the list is a familiar one: parsing the message, extracting attachments, pulling structured data out of whatever arrives. None of that is a new problem. CloudMailin has been giving software an email address since 2010, receiving production mail at the SMTP boundary and handing it to applications as structured data, across billions of messages. "How do I give my agent email?" is the newest version of the question we started CloudMailin to answer: how do I give this piece of software email? The answer hasn't changed. It's an address that routes to infrastructure you control, using your own domain, your own application and your own storage.

What agents did change is how software wants to consume mail once it arrives, and that's what this post is about. A CloudMailin address today has three access architectures behind it: the normalized webhook that POSTs each message to your application as clean JSON, own-bucket storage, where a copy of every message and attachment lands in an S3, Azure, or Google Cloud Storage bucket that belongs to you, and a hosted MCP server that lets an agent work with your mail flow directly. The first two have been around for years, only the MCP server is new. We'll go through each of them below, and when to use each one.

Software has had an email address for sixteen years

The framing "email for agents" implies that agents introduced a new problem, but we don't think they did. An agent that reads support@ needs exactly what a ticketing system needed in 2010: an address people can write to, and the message delivered somewhere useful in a form code can trust.

The hard parts of providing that sit underneath the consumer-facing API rather than in it. Real mail deviates from the specifications in ways you only learn by handling production traffic for years: encodings that are declared incorrectly, headers the RFCs say shouldn't exist, and a single sentence of content wrapped in forty kilobytes of markup. Then there's abuse: the moment an address exists it starts receiving spam, and the senders adapt when they're blocked. Underneath both of those are the delivery semantics: what happens when the receiving application is down, when to retry, when to bounce, and how a sender learns their message was refused.

We've got a post coming soon that goes through what raw email actually looks like once you're standing in front of production traffic, and what it costs to hand it to a language model unparsed.

That's the layer CloudMailin has been operating since 2010. We've handled billions of messages, held uptime at 99.99%, and assessed spam scoring and sender authentication at the SMTP boundary the whole time, and the operation now sits behind a SOC 2 Type 2 examination. None of that is agent technology, but an agent gets all of it the moment it consumes mail through this infrastructure.

What agents changed is the final hop. The new requirement is access to messages in a form that suits a model, whether that's structured fields for a pipeline, a corpus at rest the agent can process on its own schedule, or a conversational interface for interactive work. Those are three different consumption patterns, and rather than pick one for you, we support all three. First, though, the mail has to be flowing.

Getting mail flowing: your domain, or a forwarded address

There are two ways to route mail into CloudMailin, depending on how much you want to change.

Forward a single address. Keep everything where it is and forward one address (support@, invoices@, ap@) from wherever it's hosted today to your CloudMailin address. No DNS changes, nothing migrates, and the mail starts flowing in minutes.

Point MX at us. With a custom domain (a paid-plan feature), the MX records for a domain, or better a dedicated subdomain, point at CloudMailin and we receive all mail for it: catch-all by default, wildcards across subdomains, or a pattern that constrains which addresses are accepted. This is where agent designs get interesting, because addresses under a domain are free and unlimited. An address per agent, per customer, or per task (agent-1234@mail.example.com) is just a pattern rule, with no provisioning API to call, and every address under the domain routes into the same pipeline. Your agent operates under your own brand, at your own domain.

Either way, the next question is how the mail reaches your software. There are three architectures.

Architecture one: JSON Webhook

The webhook is the original push architecture, and push matters even more for agents than it did for applications. An agent polling an inbox in a loop is burning tokens just checking whether anything has arrived. With a webhook, mail arrives and your endpoint is called, with no polling anywhere in the design.

Each message reaches your application as a single normalized HTTP POST: decoded headers, UTF-8 plain and html bodies, attachments as structured entries, and the SMTP envelope (sender, remote IP, TLS, SPF results, and spam scoring when you enable it) as fields your code can branch on before a model ever sees the message. A trimmed example:

{
  "envelope": { "from": "kate@acme.com", "to": "support@yourapp.example" },
  "headers": { "subject": "Password reset not working" },
  "plain": "Hi, I tried resetting my password twice and it still won't...",
  "attachments": []
}

(What you filter out of untrusted mail before it reaches a context window is a topic of its own.) The parsing happens on our side before the POST is made.

CloudMailin receives email for your own domain or a forwarded address and delivers each message to your application as normalized JSON: decoded headers, UTF-8 bodies, structured attachments, and the authenticated SMTP envelope.

Your endpoint also stays in charge. Return a 2xx and the message is delivered. Return a 4xx and it's rejected during the SMTP conversation itself, so the sender gets a real bounce from their own mail server. Return a 5xx, or be unreachable, and delivery is retried. That contract means whatever sits behind your endpoint (including an agent pipeline) decides whether to accept the message while the sending server is still connected, which is something a polling-based design can't offer.

This is the architecture for agents that process mail: triage, extraction, routing, anything that runs on every message as it arrives.

Architecture two: a copy of every message in your own bucket

The second architecture is the one we find people are most surprised we've had all along: CloudMailin can write your mail directly into cloud storage you own, so the system of record for your email is a bucket in your own account rather than a mailbox hosted by us or anyone else.

The feature started with serverless rather than agents. We began delivering attachments straight to customer buckets a decade ago, as webhooks moved off servers with disks and into Lambda functions and their relatives. Most serverless functions are limited to a few megabytes per request, so a message carrying a 30 MB attachment simply couldn't reach the code that was meant to process it. Delivering the file to the customer's own storage, and handing the function a URL in place of the bytes, solved this problem. Customers then kept finding uses for the bucket that had nothing to do with payload limits: audit trails, retention, backup, feeding document pipelines. The feature grew to match, and today it takes two forms. Neither replaces the webhook, which is still the canonical source, though technically you can point it at anything that returns a 200 and work from events on the storage bucket instead:

Attachments straight to your storage. Configure an attachment store and every attachment is delivered to your own bucket (AWS S3, Azure Blob Storage, Google Cloud Storage, or any S3-compatible store) before the webhook fires. The payload then carries a url for each attachment instead of embedded content, so a 30 MB invoice PDF never transits your web tier. Your pipeline fetches it from your own bucket when it's ready to.

The full message to your storage. Configure the full email store and the entire message lands in your S3, Azure, or Google Cloud Storage bucket (as the raw original, or as the same parsed JSON the webhook delivers) and the webhook still fires with a store_url in the envelope pointing at the stored object. Your endpoint can acknowledge in milliseconds and leave the heavy lifting to whatever reads the bucket.

For agent architectures, this is probably the most powerful of the three. A bucket of parsed, structured messages in your own cloud account is a corpus: an agent (or a fleet of serverless functions, or a batch job, or an indexing pipeline) can read it on its own schedule, with credentials and access controls you issued, re-process the last six months when your prompts improve, and build whatever memory or search on top of it your product needs. If you want your agent to have a "memory" of its correspondence, this is a way to build one that you own. Retention, residency, deletion, and lifecycle are your bucket policies. Email becomes data in your infrastructure, governed like the rest of it, which makes compliance conversations far more straightforward. You grant CloudMailin write access to the bucket, and the objects, along with everything that happens to them afterwards, are yours.

The flip side: nothing is indexed

We make a fairly big deal of not holding on to your mail and of delivering it into storage you own instead, so it's worth being honest about the other side of that. Because a message lands in your bucket rather than in a database we run, it is not indexed. There is no content search across what you've received (only the metadata) and no way to read the body of the email on our side. The webhook tells your application what arrived, the bucket holds the objects, and looking anything up by what it says is work you do.

That work is actually pretty simple. As each message arrives you insert the content into a database, a search index, or a vector store, and you have search over your own data. Plenty of people build exactly that, and it's a well-worn path once parsed JSON is already landing where you want it. It just isn't something we do or host for you today.

It's a gap we find interesting. We have a project in our labs exploring this exact option: a searchable index derived from the store you already own, so retrieval arrives without your mail moving into a mailbox of ours.

Architecture three: a hosted MCP server

The first two architectures have been available for years. This one is new, because the work it serves is new: some agent work is a conversation rather than a pipeline. What arrived at support@ this morning? Did our endpoint accept all of it? Did the password reset actually reach kate@acme.com? For that, the same account has a hosted MCP server at mcp.cloudmailin.com. It's a full part of the product and gets the same treatment as any other production surface we run.

The entire client-side integration is one URL. Point Claude, Cursor, VS Code, or anything else that speaks MCP at https://mcp.cloudmailin.com/mcp, and the first connection opens a CloudMailin sign-in in your browser. It uses OAuth 2.1 with PKCE, so there is no API key to paste into a config file, nothing to leak from your dotfiles, and no secret to rotate later. Read and send are separate scopes you approve explicitly. Only account owners and admins can authorize a grant at all, and every grant is listed on your account page and revocable immediately.

The server currently has six tools, covering the things an agent actually needs: which addresses exist, what arrived and whether your application accepted it (including the HTTP status your endpoint returned), whether a sending domain is fully verified (SPF, DKIM, and Return-Path checked individually, with the exact missing DNS records handed back), whether what you sent was delivered, and the ability to send something new. sendEmail takes markdown and builds proper HTML and plain-text parts, because asking a language model to hand-assemble multipart MIME rarely ends well. And because the server is hosted, new tools appear for every connected client the moment we ship them, with no reinstall and no re-approval.

In practice this makes email operations something you can simply ask about. An agent can resolve support@ to an address, report that your webhook returned a 500 for two messages around 6am, confirm the receipt went out through your verified domain, and walk you through the one DNS record still missing on mail.acme.com, all in one conversation, without an API integration or a polling loop. Setup snippets for every major client are on the MCP page.

How the three fit together

The three architectures aren't tiers, and you don't pick one at signup. Most real systems end up using more than one:

A support automation might use all three in one afternoon: the webhook feeds the triage pipeline, the bucket keeps the durable copy the compliance team asked for, and the MCP server is how you ask "did anything bounce today?" while you're building it. What we don't offer is a hosted mailbox with threads and labels held on our side, or the search over it covered above. That's deliberate: in every architecture above the system of record is yours, whether that's your application's database or your own bucket.

When the agent replies, it can reply as you too. Outbound goes through your own verified sending domains (SPF, DKIM, and Return-Path each checked individually, with any missing DNS records reported) so the answer comes from support@yourcompany.com, on a domain your customers already know, rather than from a platform address.

What about truly structured data?

There's a fair question left: what about the step beyond parsing? The webhook hands your application decoded headers, clean bodies, and attachment entries, but the fields your workflow actually keys on (the invoice number, the order reference, the ticket priority) are still inside the text. Schema-style extraction is a headline feature of the agentic mail platforms, so it's reasonable to ask why it isn't part of our pipeline.

The answer is that this is something the AI itself handles really well. We believe in giving the model clean, reliable input and the tools to make its own decisions, and extraction is exactly that kind of decision. The structure you want is almost always unique to your use case: an accounts payable agent and a support triage agent pull completely different fields from the same message. We think that logic is best handled inside the agent, where you can see it, version it, and improve it. Paired with the bucket, that also means you can re-run an improved extraction over everything you've already received.

The boring answer

So our answer to the question agentic mail systems raise (what does agent-specific email infrastructure offer over an existing provider?) is that we think the premise is the wrong way around. Email infrastructure for software has existed for sixteen years, and agents are simply its newest consumers. Every wave before them (webmail, phones, SaaS) plugged into the same protocol and found the infrastructure already there. Agents have three ways in: a webhook when they process mail, a bucket when they need the full archive, and an MCP server when they need a conversation. The parsing, the abuse handling, the delivery semantics, and the uptime are already taken care of.

A free CloudMailin account is enough to walk through all three: point an address at your application (or a request bin) and look at the payload your agent would consume, or connect the MCP server and ask it what arrived today. And if you're designing an agent around email right now, tell us what it needs. Most of what's described above was built because customers asked for it, and we expect the next features will be too.