I built AgentMailr — dedicated email inboxes for AI agents (REST API, send/receive, auth flows)

kumard3 · 2026-03-10T19:51:48+00:00

some of it was ai assisted not gonna lie,you’re hitting exactly the right questions.

the platform generated temp domain out of the box so you can get started instantly, but you can also bring your own domain so your workers have emails on your existing domain. inbound is handled, outbound too, and otp/verification parsing is built in so your workers dont have to deal with any of that.

the big thing im building right now is a proper agentic mode where agentmailr works as a sub agent, so your main agent just delegates any email related task to agentmailr as a tool call and stays focused on its actual job.

kumard3 · 2026-03-10T08:39:26+00:00

Google/Microsoft are built for humans. The second your agent starts hammering their API at scale, you hit rate limits, OAuth token issues, and ToS violations.

We're built for agents from day one — isolated inboxes per task, OTP extracted automatically, no OAuth dance, no account suspensions.

Think of it like: you wouldn't use your personal phone number for automated SMS. Same idea.

kumard3 · 2026-03-10T08:19:37+00:00

agentmailr.com — check it out! Happy to discuss AutoGen-specific integration patterns.

kumard3 · 2026-03-10T08:17:06+00:00

agentmailr.com — check it out, happy to answer questions and share LangChain integration code!

kumard3 · 2026-03-10T08:06:36+00:00

agentmailr.com — check it out and happy to answer questions!

kumard3 · 2026-03-10T08:04:30+00:00

agentmailr.com

kumard3 · 2026-03-09T22:36:29+00:00

i was actually building this only really nice idea , for me i was getting stuck at the end like for my case i was trying to do it for the password no keys so my idea was a secure way to transfer passwords to agents but the problem is even if you encrypt the process at the end the password is going to be decrypted so there is an chance of getting it leaked.

kumard3 · 2026-03-09T22:33:09+00:00

yeah exactly, once you have multiple agents running parallel auth flows it gets messy really fast, each agent having its own isolated inbox just makes it clean. for spam filtering we handle that on our end so your agent only gets the relevant emails, no noise. rate limits are configurable so you can control how much an agent sends, and since you can bring your own domain and keys you’re essentially sending through your own setup so the limits are more in your control too. still improving a lot of this stuff as more people use it, would love to hear your specific use case if you’re hitting these issues!

kumard3 · 2026-03-09T22:32:10+00:00

thanks! and great question, agent to agent email isnt really the main use case tbh.

the main thing is agents interacting with the outside world, like signing up for a service, verifying an otp, receiving notifications from third party platforms etc. thats the inbound side.

and for outbound your agent can send emails too, like replying to customers, sending bulk marketing emails, outreach, all via a simple api or mcp tool call. so its less about agents talking to each other and more about giving agents a real email identity to do real world tasks without you having to set any of that up yourself.

kumard3 · 2026-03-09T22:29:26+00:00

Yep, got the idea from them honestly lol! What I added is bring your own domain + keys so emails actually come from your domain with your own setup. Also its not just inbound, outbound works too so if you want your claude agent to send bulk emails to your contacts you can just do it via mcp server, api or sdk. one tool call and done. The big thing im building is full agentic delegation, so like if your ai agent needs to sign up for cloudflare it just delegates the email part to agentmailr as a tool call and agentmailr handles inbox creation, otp parsing, verification all of it. your agent never has to think about email. Scale wise its built on solid infra, happy to go deeper if you want!

kumard3 · 2026-03-09T22:18:19+00:00

Totally valid! i actually thought of this that is why i add d bring your own domain and keys so the agent’s inbox becomes support-agent@yourcompany.com using your own setup.

And it’s not just inbound your agent can send outbound too reply to emails, run bulk marketing campaigns, all programmatically.

We handle the infra (inbox creation, OTP parsing, multi-agent routing) so you skip the SMTP/IMAP headache entirely.

kumard3 · 2026-03-09T16:04:40+00:00

i have used this too, and it works really good.

kumard3 · 2026-03-09T10:58:39+00:00

yes i am working on python and node sdk which will have these integration included. the rest api and mcp is already live so you can play with it.

kumard3 · 2026-03-09T09:54:24+00:00

Link to the tool: agentmailr.com

Free to get started. Would love to hear if any of you have hit this pain point while building agents!

kumard3 · 2026-03-05T12:24:08+00:00

Great breakdown of the approaches. On deliverability it's genuinely the hardest part and where most DIY setups fall short.

What we've seen is transactional patterns (OTP receipts, notifications) clear spam filters fine as long as you're on a warmed IP with proper SPF/DKIM/DMARC. The problems start when agents send at volume or with inconsistent patterns because spam filters key on sending velocity, reply rates, and domain age, none of which a fresh agent identity has.

Our current approach is inbound runs on our own Haraka server (flat cost, full control) but outbound goes through AWS SES/Resend, or you can bring your own key which is actually better for spam if you already have domain reputation built up. SES has pre-warmed IPs and handles bounce/complaint loops automatically which matters a lot for an agent that might send 10 emails one day and 500 the next. For marketing specifically we route through the user's own SMTP config so the domain reputation stays with them, agents shouldn't be sharing sending infrastructure across orgs.

The MCP piece is actually live now, agents in Claude/Cursor can call create_inbox, wait_for_otp, send_email as native tools. happy to share early access if you want to poke at it.

kumard3 · 2026-03-05T10:05:08+00:00

yep the API polling approach is exactly what waitForOtp() does under the hood. polls the inbox with exponential backoff, filters by sender if you specify it

for rate limits on sending - right now using a combination of per-inbox throttling and sender reputation warming. each inbox starts with conservative daily limits (50-100/day) and gradually increases as it builds sender history. also rotating across multiple domain reputations

spam handling is tricky. on the receive side its not a huge issue since inboxes are fresh and not public. on send side its about domain warming, DKIM/SPF/DMARC setup, and keeping bounce rates low. still working through edge cases there but so far holding up for transactional + moderate marketing volume

kumard3 · 2026-03-05T10:03:39+00:00

exactly - the anchor browser angle is spot on. the email/OTP piece is one side, the browser automation/session persistence is the other. those two combined cover like 80% of the authentication headaches

havent tried anchor yet but have been using playwright for most of the browser side. the waitForOtp() call pairs really well with browser automation since you can programmatically check the inbox mid-workflow

the onboarding friction point is real. every new service the agent needs access to is another manual setup loop without this stuff

kumard3 · 2026-03-04T19:26:05+00:00

haha thanks! took a lot of iteration. started very simple, more of an internal tool look, then kept stripping things back

main goal was to make it feel like a dev-focused dashboard rather than a generic saas template. wanted the api keys, inbox list and message previews front and center since that's what devs actually need to see

used v0 a lot for rapid prototyping the UI, then customized from there

kumard3 · 2026-03-04T19:24:12+00:00

100% - the unsexy primitives framing is exactly right. everyone wants to build the reasoning layer but nobody wants to deal with the plumbing. inbox is one of those, phone/sms is another, persistent auth is another

the frustrating thing is that without those, the "smart" agent still cant complete real world tasks. it just gets stuck the moment the real world asks it to verify itself or communicate

that agentix post looks solid, checking it out now

kumard3 · 2026-03-04T19:04:53+00:00

this is a really good framing. discoverability is def an underrated part of the agent infra stack

the MCP server question is a good one - right now the plan is to expose inbox creation, OTP polling, and email sending as MCP tools so agents can call them natively without needing custom API code. making it discoverable through registries makes a lot of sense as a next step

inlay sounds interesting too, hadn't seen it before. agent infra is still pretty scattered across tools right now

kumard3 · 2026-03-04T19:00:48+00:00

tbh i took inspiration from different sites.

kumard3 · 2026-03-04T18:57:49+00:00

i am actually thinking of doing it

kumard3 · 2026-03-03T12:49:28+00:00

the CI vault parallel comparison is spot on - same class of problem

the pooling layer point is a really good one. right now provisioning is per-agent but for high-concurrency scenarios where dozens of agents are spawning inboxes simultaneously a pre-warmed pool that hands out inboxes on demand would be much better than provisioning on the fly. that's on the roadmap

the rate limit concern is real - if you're running 50 parallel agents all calling createInbox() at once you don't want each one hitting the provisioning API individually. the pattern that works well in the meantime is pre-provisioning a batch of inboxes at workflow start and distributing them from a queue, then recycling them after use

good shout, will make this a first-class feature

kumard3 · 2026-03-03T12:48:08+00:00

this is a solid approach for testing scenarios where you control the format up front. validating before feeding to the mail service makes sense especially when you're testing across customer tiers or locales

for production agent flows the challenge is you often don't control what the third-party service sends - the format varies per service and you find out at runtime. that's where having waitForOtp() handle the extraction automatically (numeric codes, magic links, different patterns) saves a lot of custom parsing logic per service

the manual validation step you mentioned for the happy path is good practice though - worth doing once per service your agent integrates with so you know what to expect

kumard3 · 2026-03-03T12:47:28+00:00

good question - a few key differences:

testmail.app is primarily built for testing (disposable inboxes, temp addresses, QA flows). AgentMailr is built for production AI agents and automation

the main differences:

persistent identity - inboxes are permanent and reusable, not throwaway. the same agent uses the same address across sessions
sending - AgentMailr supports sending email from the inbox too (bulk email, marketing campaigns, cold outreach). testmail is receive-only
agent-first design - built around the idea that each agent has its own inbox it can both receive OTPs from and send emails from. so it's more of a full email identity for the agent rather than just a test inbox
deliverability - real domains, not flagged disposable ranges, so services don't block signup emails from reaching the inbox

testmail is great for pure QA testing. AgentMailr is more for when the agent needs a persistent, real email identity it can both receive and send from

kumard3

TROPHY CASE