Email API for AI agents: what sending actually needs
An email API for AI agents has to work without a person in the loop, except where you want one. That means onboarding with no dashboard or API key, DNS the agent can set up itself, the cost known before every send, spending limits only a human can raise, approval built in for broadcasts, errors that explain the fix, safe retries, events it can pull, and an MCP server. Below is each requirement, why it matters, and the question to ask any provider.
We build SendForAI, a sending API designed around these requirements, so we're biased. The questions in each section work for evaluating any provider, including ones we compete with.
First: does your agent need an inbox or a sender?
Search for "email for AI agents" and you'll find two different kinds of product under one name:
| Inbox API | Sending API | |
|---|---|---|
| What the agent gets | Its own email address and mailbox | The ability to send from your product's domain |
| Typical jobs | Read replies, negotiate, handle a support thread, sign up for services | Sign-in links, receipts, alerts, onboarding emails, newsletters |
| Direction | Two-way: receive, thread, reply | Mostly one-way, with delivery, bounce and complaint events |
| What matters most | Receiving, parsing, conversation state | Deliverability, cost, spend control, approval |
If your agent needs a mailbox of its own, an inbox API is the right tool and SendForAI isn't one. We don't receive email. The rest of this page is about sending, where an agent acts on behalf of your product and the stakes are your domain's reputation and your money.
Nine things an agent needs from a sending API
| Requirement | Ask any provider | How SendForAI does it |
|---|---|---|
| Sign up without a person | Can my agent go from nothing to a working sender using only API calls and DNS? | No API keys. The agent generates a keypair, publishes the public key at _sendforai.<domain>, and signs requests. The first signed request creates the account. |
| Set up DNS for itself | Can my agent publish the records, or only read them? | sfa.dns.setup() (MCP: setup_dns) publishes the identity, DKIM, MAIL FROM and DMARC records on Vercel DNS or Cloudflare. The token stays on the agent's machine. |
| Know the cost before it sends | Does the API tell me what a send will cost before I send it, and what it did cost after? | dry_run returns the exact cost, recipients and lint warnings. Every real send returns a cost object, and GET /v1/account shows the balance and budget left. |
| Hard spend limits a human controls | Can I cap spend so an agent can't raise the cap itself? | max_cost_usd caps any single request. A monthly budget ($20 by default) caps usage; agents can lower it, and raising it returns a link only a person can approve. |
| Human approval for the risky parts | Can a send wait for a human, and can the agent hand that human a link? | Broadcasts are created as awaiting_approval and return an approval_url. Adding credit works the same way: the agent gets a checkout link to hand over. |
| Errors that say what to do | Do errors explain how to fix them, in words a model can act on? | Every error carries a fix field, e.g. a domain that isn't set up returns the exact DNS record to publish. |
| Safe retries | If my agent retries the same send, will the customer get it twice? | Pass idempotency_key and a retry returns the original result instead of sending again. |
| Events it can pull | Can my agent check deliveries and bounces without hosting a webhook? | GET /v1/events?cursor= returns deliveries, bounces, complaints and account events; keep the cursor between runs. |
| Tools, not just an SDK | Is there an MCP server, and does it cover setup and billing as well as sending? | The @sendforai/mcp server (local, or hosted at sendforai.com/mcp) exposes sending, broadcasts, contacts, domains, DNS setup, budgets and credit. /llms.txt explains everything in one page. |
1. Sign up without a person
An agent can't click a verification email, solve a CAPTCHA or copy a key out of a dashboard. Every human step in onboarding is a place the agent stops and waits.
2. Set up DNS for itself
DKIM, SPF and DMARC records are where most email setups stall. An agent that already has a DNS token should be able to finish the job.
3. Know the cost before it sends
Agents plan. A price that only shows up on next month's invoice can't be part of the plan.
4. Hard spend limits a human controls
An agent in a loop can send a lot of email. The person responsible needs a ceiling the agent can't raise on its own.
5. Human approval for the risky parts
Emailing your whole list is the action you most want a person to see first. Approval should be part of the API, not a policy you hope the agent follows.
6. Errors that say what to do
"400 Bad Request" makes an agent guess. A precise next step lets it recover without a person.
7. Safe retries
Agents retry after timeouts. Without idempotency, a retry is a duplicate email to a customer.
8. Events it can pull
Many agents run as scripts or jobs with no public URL, so webhooks have nowhere to land.
9. Tools, not just an SDK
Claude, Cursor and other MCP clients use tools directly. A good MCP server turns the whole API into actions the model can take.
What this looks like in practice
An agent planning a send first asks what it would cost, then sends with a ceiling and a retry key:
const plan = await sfa.emails.send({ from, to, subject, markdown, dry_run: true });
// plan.cost -> { emails: 1, billed_usd: 0, included_remaining: 9831,
// note: "Included in this sending month. 9831 of 10000 included emails remain this month." }
const sent = await sfa.emails.send({
from, to, subject, markdown,
max_cost_usd: 0.01, // refuse anything pricier
idempotency_key: "signup-482", // a retry returns this result, never a second email
});When something needs a person, the API says so and hands the agent the link:
402 balance_required
{ "fix": "Ask your operator to add credit: POST /v1/account/topup returns a checkout link. ..." }
201 broadcast created
{ "status": "awaiting_approval", "approval_url": "https://sendforai.com/approve/..." }Where SendForAI is not the right fit
- Your agent needs its own inbox. We send; we don't receive or thread replies.
- You want a visual editor or template gallery. SendForAI takes Markdown, HTML or text through the API. There's no drag-and-drop builder.
- You need a long track record today. SendForAI is in early access: payments run in test mode and our Amazon SES production access is under review, so sending is limited to verified addresses for now.
If those fit, start with the quickstart or point your agent at /llms.txt. Pricing is on one page, and if you're comparing, see Resend pricing and Amazon SES pricing.
FAQ
What is the difference between an email inbox API and an email sending API for agents?
An inbox API gives an agent its own mailbox, so it can receive mail, read threads and reply as itself. A sending API lets an agent send email on behalf of a product or person, like sign-in links, receipts and newsletters from your domain. Many agents need one of the two, some need both.
Can an AI agent send email without an API key?
With SendForAI, yes. The agent proves it controls a domain by publishing a public key in DNS and signs each request with the matching private key. There is no key to create in a dashboard or paste into a config.
How do I stop an agent from overspending on email?
Use per-request caps and a monthly budget the agent can't raise. On SendForAI, max_cost_usd refuses any send above your cap, and usage per month stops at the budget (default $20) until a person approves a higher one.
Should an AI agent send newsletters automatically?
Usually only with a person in the loop. Sending to a whole list is the highest-risk action in email: one mistake reaches everyone and hurts your sender reputation. Broadcasts that wait for approval let the agent do the work and a person make the call.
What does an email API for AI agents cost?
SendForAI is $0 to build and test (unlimited simulated sends, 25 real emails a day to your own domains), $5 in months you send to anyone else, which includes 10,000 emails, then $0.11 per 1,000 at cost.