100,000 Emails Sent: What We Learned About Deliverability for AI Agents

Today, Sentvia crossed 100,000 emails sent.

Every one of those messages was sent through infrastructure built for AI agents: agents following up with customers, working through operational tasks, responding to inbound conversations, and participating in the same channel where real businesses already get work done.

The whole team is thrilled. One hundred thousand is large enough to feel real—and small enough that we still remember the first production message leaving the system.

It also gives us enough signal to say something useful about the part of email that gets underestimated most often: deliverability.

Sending an email is easy. Building a system that can keep sending as volume grows—without damaging a customer’s domain reputation, repeatedly retrying bad addresses, or turning a traffic spike into a mailbox-provider throttle—is a different problem.

Here are the lessons that became clearest on the way to 100,000.

1. Deliverability starts with identity, not content

People often talk about deliverability as if it were mostly copywriting: avoid certain words, keep the HTML clean, and do not add too many links.

Content matters, but identity comes first.

Mailbox providers want to know that a message was authorized by the domain shown to the recipient. That means correctly configured SPF, DKIM, and DMARC, alignment between the authenticated domain and the visible From address, valid forward and reverse DNS, and TLS in transit.

These are no longer optional optimizations for serious senders. Google requires SPF and DKIM plus DMARC for senders exceeding 5,000 messages per day to personal Gmail accounts. Yahoo applies the same core authentication requirements to bulk senders, and Microsoft introduced SPF, DKIM, and DMARC requirements for domains sending more than 5,000 daily messages to Outlook.com accounts.

For agent email infrastructure, authentication has to be a product workflow—not a documentation footnote. DNS configuration needs to be understandable, validation needs to be visible, and failures need to be caught before an agent starts sending.

2. Reputation is built by patterns

A correctly authenticated domain can still develop a poor reputation.

Mailbox providers evaluate patterns: how quickly volume increases, whether recipients engage, how many messages bounce, how often users report messages as spam, and whether sending behavior suddenly changes.

This matters for agents because software can move much faster than a human campaign operator. An agent can go from a test workflow to thousands of messages without getting tired or noticing that the receiving server has started pushing back.

The right response is not a magical “warm-up” switch. It is controlled, observable growth. Google recommends beginning with low volume, sending first to engaged recipients, increasing gradually, avoiding bursts, and slowing down when bounces or deferrals rise.

Our takeaway: rate limits are part of deliverability, not just infrastructure protection. A good sending platform should help workloads establish a stable pattern instead of letting a new domain sprint directly into a reputation problem.

Not every email stream behaves the same way.

A password reset or direct reply has a different recipient expectation than a newsletter, automated prospecting sequence, or agent-generated outreach. Combining those streams under the same reputation surface means a problem in one workflow can affect every other workflow.

Yahoo recommends separating bulk and marketing traffic from transactional mail by IP or DKIM domain. AWS similarly recommends using different subdomains for different communication types, allowing each stream to develop its own reputation.

That principle is especially important for agent fleets. The safest architecture creates boundaries around tenants, domains, and traffic classes so one noisy workflow does not degrade critical mail elsewhere.

Isolation is not only a security feature. It is a deliverability feature.

4. A bounce is an instruction, not just a metric

Aggregate delivery rates are useful, but the SMTP response attached to an individual message is where the system learns what to do next.

A hard bounce usually describes a permanent failure, such as an address that does not exist. Retrying it wastes capacity and tells mailbox providers that the sender is not maintaining its recipients. AWS recommends immediately removing hard-bouncing addresses and keeping hard-bounce rates below 5% as a practical target, while noting that the precise threshold is not universal.

A soft failure is different. It may indicate a temporary mailbox issue, server outage, or rate limit. Those messages can be retried—but not blindly or indefinitely.

The lesson for agent infrastructure is simple: delivery events must be structured enough for software to act on. “Failed” is not a useful final state. The agent or application needs to know whether to suppress the recipient, wait, retry, reduce volume, or surface the problem to a human.

5. Complaints are one of the clearest signals available

A spam complaint is a recipient explicitly saying, “I did not want this.” Mailbox providers listen.

Google advises senders to keep user-reported spam rates below 0.1% and avoid ever reaching 0.3%. Yahoo requires bulk senders to remain below 0.3%. AWS recommends targeting a complaint rate below 0.1%, while noting that it is not a universal threshold across every provider.

The important point is not to design around the maximum. It is to treat every complaint as operational feedback.

That means processing feedback loops, suppressing recipients where appropriate, tracing complaints back to the responsible tenant or workflow, and making unsubscribe paths easy for promotional mail. Google and Yahoo require one-click unsubscribe for qualifying marketing and subscribed messages; Google explicitly excludes transactional messages from that requirement.

For AI agents, consent and recipient expectation matter even more because agents can initiate and continue conversations autonomously. The system needs enforceable controls—not a prompt asking the model to “be careful.”

Sentvia uses advanced matching technology to identify patterns that indicate an AI agent is using the platform to send spam. When we detect abusive sending, we shut it down. Protecting recipients also protects the reputation and deliverability of every legitimate developer building on the platform.

6. Observability is part of the sending product

At low volume, a developer can inspect a few logs. At meaningful volume, deliverability needs its own telemetry.

The useful view combines:

authentication status by sending domain;
accepted, deferred, bounced, and complained message events;
hard and soft bounce classifications;
reputation signals by domain, IP, tenant, and traffic type;
mailbox-provider SMTP responses;
suppression activity and retry behavior; and
sudden changes in volume or failure rates.

A message being accepted by the API is not the same as a message reaching an inbox. The product has to preserve that distinction all the way back to the agent.

That may be our biggest lesson from the first 100,000: email delivery is a feedback system. The send call begins the process. Authentication, mailbox responses, recipient actions, and reputation determine what happens next.

What 100,000 means for Sentvia

This milestone does not mean the work is finished. It means the system has moved beyond a promising prototype and into real operating history.

Sentvia now supports a meaningful volume of agent-driven communication while giving developers the primitives agents actually need: programmatic inboxes, two-way email, threading, real-time inbound events, custom domains, and infrastructure designed for fleet economics.

We are proud of the number. We are even more excited about what it represents: more agents doing useful work through a universal communication channel, and more evidence that AI agents need email infrastructure built around their operating model.

To every developer who sent one of the first 100,000 messages: thank you. Your workloads, edge cases, and feedback are shaping the platform.

Now we are on to the next 100,000.

Start free, explore the Email API, or read the documentation.

Sources

Google: Email sender guidelines — authentication, DNS, TLS, volume ramping, spam-rate, and unsubscribe guidance.
Google: Email sender guidelines FAQ — complaint thresholds, enforcement, and transactional-message unsubscribe exemption.
Yahoo Sender Hub: Sender best practices — bulk-sender authentication, complaint limits, traffic separation, feedback loops, and unsubscribe requirements.
Microsoft: Outlook.com policies — high-volume authentication requirements and reputation-monitoring resources.
AWS: Email program success metrics — bounce and complaint handling guidance.
AWS: Maintaining a positive sender reputation — subdomain separation, authentication, and recipient-quality practices.