agentleFS
chunkydotdevchunkydotdev/email-skills/skills/inbox/inbox-providers/SKILL.md

inbox-providers

Skill5 starsChanged 34 days agoMITView on GitHub

Choose and configure an agent-native inbox provider for AI agents that send and receive email. Use when giving an AI agent its own email address, setting up two-way agent email communication, comparing agent inbox platforms, or adding guardrails to autonomous email workflows.

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Sending: Create inboxes via API, send and receive through them.

    line 73
  2. Distinctive:

    If you're building a quick prototype or your agent only sends occasional transactional email, a traditional ESP is fine.

    line 160
  3. Distinctive:

    When a send is blocked, the response includes the reason.

    line 208
  4. Distinctive:

    Every inbound email is scanned for prompt injection patterns before the agent sees it.

    line 244
  5. Distinctive:

    Before any email leaves, scan for canary token leakage, injected content, and anomalous patterns.

    line 253
  6. Distinctive:

    Start at the lowest trust level your use case allows.

    line 269
  7. Distinctive:

    Every inbound email is untrusted input.

    line 285
  8. Distinctive:

    When an agent inbox provider blocks a send (rate limit, suppression, cooldown), the agent should accept the decision and move on.

    line 289
  9. Distinctive:

    If your agent keeps sending to addresses that bounce, ISPs treat your domain as a spam source.

    line 305

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Inbox Providers

Choose an agent-native inbox provider so your AI agent can send, receive, and manage email with built-in guardrails.

When to use this skill

  • Giving an AI agent its own email address for autonomous communication
  • Choosing between agent-native inbox providers (Molted Email, AgentMail, LobsterMail, etc.)
  • Setting up two-way email for an agent (not just sending, but receiving and acting on replies)
  • Adding policy enforcement or guardrails to agent email workflows
  • Comparing agent-native providers vs building on top of traditional ESPs
  • Protecting agents from prompt injection, over-sending, or reputation damage

Related skills

  • provider-setup - traditional ESP selection (Resend, Postmark, SES, SendGrid) for human-managed sending
  • email-security - prompt injection detection, content sanitization, canary tokens
  • inbound-processing - MIME parsing, header extraction, webhook processing for inbound email
  • reply-classification - categorizing reply intent (interested, OOO, objection, etc.)
  • rate-limiting - volume controls that protect sender reputation
  • domain-authentication - SPF, DKIM, DMARC setup before sending
  • suppression-lists - managing bounces, complaints, and opt-outs

What is an inbox provider?

Traditional email providers (Resend, Postmark, SES, SendGrid) are sending APIs. You configure DNS, manage API keys, and call an endpoint to send email. Some offer inbound webhooks, but the core product is a pipe that delivers messages.

Agent-native inbox providers are different. They give your agent a full mailbox - send, receive, read, search, thread, and reply - with guardrails built into the infrastructure. The agent is the primary user, not a human operating a dashboard.

The distinction matters because agents fail differently than humans:

Failure modeHuman senderAI agent
Over-sendingUnlikely (manual process)Common (no fatigue, no judgment)
Hitting suppressed addressesChecks suppression listDoesn't know the list exists unless enforced
Sending duplicate emailsNotices they already sentNo memory between invocations
Following malicious instructionsReads criticallyTreats email content as potential instructions
Managing reputationMonitors dashboardsHas no concept of sender reputation
Handling bouncesReads bounce notificationsKeeps sending to dead addresses

Traditional ESPs assume a human is making decisions. Agent-native providers enforce those decisions at the infrastructure layer so the agent can't make mistakes that damage deliverability.


Provider landscape (2026)

Molted Email

Best for: Teams that need policy enforcement and governance on agent email. Agents that send outbound sequences, lifecycle emails, or handle inbound reply workflows.

  • Approach: Policy-first. Every email passes through 10+ policy checks (deduplication, cooldowns, suppression, consent, rate limits, risk budgets) before it hits the wire. The agent calls one endpoint; Molted handles the rest.
  • Sending: Multi-provider delivery with automatic failover across Resend, Postmark, and SES. Provider health monitoring and weighted routing.
  • Inbound: Intent classification for replies, prompt injection scanning, thread linking, and event streaming via SSE.
  • Security: Content sanitization, Unicode normalization, canary tokens for data exfiltration detection, injection pattern scoring across 10 categories.
  • Governance: Approval queues for high-risk sends, email humanization (AI rewrites agent drafts for natural tone), outcome attribution tracking business results per email.
  • Pricing: Starter $9.99/month (3,000 emails, 1 mailbox), Growth $39.99/month (10,000 emails, unlimited mailboxes), Enterprise custom. 14-day free trial on all plans.
  • Weaknesses: Opinionated about how email should work. Policy-first means the platform will block sends that violate rules, which is the point but can surprise agents not designed for rejection handling.
  • Website: molted.email

AgentMail

Best for: Teams that need many inboxes fast, or are building agents where email is the identity layer. Two-way conversational agents that need to read, search, and reply.

  • Approach: Inbox-as-identity. Every agent gets its own email inbox via API. Built for two-way conversations, not just sending. Positions email as the identity and communication layer for AI agents.
  • Sending: Create inboxes via API, send and receive through them. Auto-configured SPF, DKIM, DMARC per inbox.
  • Inbound: Semantic search across all inboxes, automatic labeling with user-defined prompts, structured data extraction from unstructured emails.
  • Integrations: Official SDKs for Python, TypeScript, Go, and CLI. MCP server for Claude Desktop, Cursor, Windsurf. Native integration with LangChain, LlamaIndex, CrewAI.
  • Safety: Agent inboxes capped at 10 emails/day unless authenticated by a person. Rate limits on unusual activity. Bounce rate monitoring. Keyword sampling on new accounts.
  • Pricing: Free (3 inboxes), Developer $20/month (10 inboxes), Startup (dedicated IPs), Enterprise (white-label, EU hosting, BYOC). Pricing based on email volume, not inbox count.
  • Weaknesses: Less policy enforcement depth compared to Molted. Safety guardrails focus on abuse prevention rather than deliverability governance. Newer platform (launched August 2025).
  • Website: agentmail.to

LobsterMail

Best for: Agents that need to self-provision their own inbox without human setup. OpenClaw and framework-native workflows.

  • Approach: Agent-first provisioning. The agent can create its own inbox with no prior human configuration - LobsterMail.create() handles account signup automatically.
  • Security: Inbound email scanned across six injection categories (boundary manipulation, system prompt override, data exfiltration, role hijacking, tool invocation, encoding tricks). SDK exposes safeBodyForLLM() for safe content access.
  • Integrations: TypeScript/JavaScript SDK. Ships as an MCP server for Claude Desktop, Cursor, Windsurf. Works with OpenClaw, LangChain, CrewAI, AutoGen.
  • Pricing: Free (1,000 emails/month), Builder $9/month (10 inboxes, 5,000 emails/month, 500 outbound/day).
  • Weaknesses: Newer and smaller than AgentMail. Less documentation on deliverability management. Agent self-provisioning means less human oversight by design.
  • Website: lobstermail.ai

MailMolt

Best for: Teams that want graduated trust - start agents sandboxed and increase autonomy over time.

  • Approach: Progressive trust. Agents start in sandbox mode and earn autonomy through four levels.
  • Trust levels:
    1. Sandbox - receive only, no sending
    2. Supervised - agent drafts emails, human approves
    3. Trusted - send within specific domains or limits
    4. Autonomous - full sending capabilities
  • Key idea: Agents earn trust over time, like human team members. New agents can't damage your reputation because they can't send until verified.
  • Pricing: Free during beta.
  • Weaknesses: Early stage (launched February 2026). Progressive trust model adds friction for agents that need to send immediately.
  • Website: mailmolt.com

How to choose

By primary need

NeedRecommendation
Policy enforcement and deliverability protectionMolted Email
Many inboxes, email-as-identity for agentsAgentMail
Agent self-provisioning, no human setupLobsterMail
Graduated trust with human oversightMailMolt
Just sending (no inbound, no agent autonomy)Traditional ESP (see provider-setup skill)

By architecture

ArchitectureRecommendation
Agent sends outbound sequences with reply handlingMolted Email (policy engine prevents over-send, intent classification on replies)
Agent needs its own inbox to converse like a humanAgentMail (inbox-first design, semantic search, threading)
Agent provisions itself at runtimeLobsterMail (no human in the provisioning loop)
Prototype with safety railsMailMolt (sandbox mode until you trust the agent)

Quick decision

  • You need guardrails more than anything: Molted Email. The policy engine is the product. Your agent can't over-send, hit suppressed addresses, or skip cooldowns.
  • You need lots of inboxes: AgentMail. Volume-based pricing, not per-inbox. Create hundreds of inboxes via API.
  • You want zero setup: LobsterMail. Agent provisions its own inbox programmatically.
  • You're not sure you trust your agent yet: MailMolt. Start sandboxed, upgrade to autonomous when ready.

Agent inbox provider vs traditional ESP

You can build agent email on traditional ESPs. Many teams do. But you'll be reimplementing features that agent-native providers handle at the infrastructure layer.

What you'd need to build yourself on a traditional ESP

CapabilityTraditional ESPAgent inbox provider
Sending emailAPI callAPI call
Receiving emailConfigure inbound webhooks, parse MIMEBuilt-in inbox, parsed and classified
Suppression checkingQuery your own suppression database before every sendChecked automatically, send rejected if suppressed
Rate limitingImplement sliding window countersEnforced at infrastructure layer
DeduplicationTrack dedupe keys yourselfBuilt-in, returns cached result on duplicate
CooldownsTrack per-recipient send timesEnforced automatically (e.g., 10-min per-recipient cooldown)
Bounce handlingProcess webhook events, update suppression listAuto-suppression on hard bounce
Prompt injection scanningBuild your own detection pipelineBuilt-in scanning before agent sees content
Thread linkingParse In-Reply-To/References headers, match against stored IDsAutomatic thread reconstruction
Reply classificationBuild or integrate intent classifierBuilt-in (interested, OOO, objection, etc.)
Multi-provider failoverImplement failover logic, manage multiple provider configsConfigured automatically
Audit trailLog every decision yourselfEvery send decision logged with reason

If you're building a quick prototype or your agent only sends occasional transactional email, a traditional ESP is fine. If your agent sends at scale, handles replies, or operates autonomously, the build-vs-buy calculation tips toward an agent inbox provider quickly.

When to stick with a traditional ESP

  • Your agent only sends transactional email (receipts, auth codes) with no reply handling
  • You already have email infrastructure with suppression lists, rate limiting, and bounce processing
  • Your volume is low enough that guardrails aren't critical (under 100 emails/day)
  • You need features agent-native providers don't offer yet (dedicated IPs, advanced analytics, marketing automation)

Setting up an agent inbox

Regardless of which provider you choose, the setup pattern is similar.

1. Create the mailbox

Most providers offer API-based inbox creation:

# Molted Email (via CLI)
npx @molted/cli auth signup
npx @molted/cli send --to user@example.com --subject "Hello" --text "First email"

# AgentMail (via SDK)
# Create inbox via API, get back an email address

# LobsterMail (agent self-provisions)
# Agent calls LobsterMail.create(), inbox is ready

2. Configure your domain

For production use, set up a custom sending domain. All providers require domain verification with DNS records (SPF, DKIM, DMARC). See the domain-authentication skill for details.

Using a provider's shared domain (e.g., your-agent@agentmail.to) works for testing but limits deliverability and professionalism.

3. Handle the send response

Agent inbox providers return structured responses that tell your agent what happened and why. Design your agent to handle rejections gracefully:

Possible responses:
  - accepted    -> email queued for delivery
  - blocked     -> policy violation (rate limit, suppression, cooldown, etc.)
  - rejected    -> validation error (bad address, missing fields)

When a send is blocked, the response includes the reason. Your agent should not retry a blocked send - the policy exists to protect your reputation.

4. Process inbound email

Set up inbound handling to receive replies and route them:

  1. Webhook or polling - receive notifications when email arrives
  2. Content extraction - provider parses MIME, extracts clean text/HTML
  3. Safety scanning - injection detection before agent processes content
  4. Intent classification - categorize the reply (interested, OOO, objection, unsubscribe, etc.)
  5. Thread linking - associate the reply with the original conversation
  6. Agent action - your agent decides what to do based on intent and context

5. Monitor and adjust

Watch these metrics from day one:

MetricHealthy thresholdAction if exceeded
Bounce rate< 2%Audit your recipient list, check for stale addresses
Complaint rate< 0.1%Review content, check opt-in quality, reduce frequency
Block rate (policy)< 5%Agent is hitting guardrails too often - adjust its behavior
Delivery rate> 95%Investigate provider issues, check DNS, review content

Safety architecture for agent email

Giving an AI agent email access is fundamentally different from giving a human email access. The agent reads untrusted content into its context window, where it can influence behavior. Design for this.

Defense in depth

Layer 1: Infrastructure guardrails The inbox provider enforces rate limits, suppression, deduplication, and cooldowns. The agent can't bypass these even if instructed to by malicious email content.

Layer 2: Inbound scanning Every inbound email is scanned for prompt injection patterns before the agent sees it. High-risk content is quarantined. Medium-risk content is flagged.

Layer 3: Content isolation The agent reads sanitized, extracted content - not raw email. Hidden text, invisible Unicode, zero-width characters, and HTML tricks are stripped at the infrastructure layer.

Layer 4: Action boundaries The agent's email capabilities are scoped. It can reply to threads and send pre-approved templates. It cannot forward to arbitrary addresses, export contact lists, or escalate its own permissions.

Layer 5: Outbound scanning Before any email leaves, scan for canary token leakage, injected content, and anomalous patterns. If the agent was manipulated, catch it before the email sends.

Layer 6: Human oversight High-risk actions (first email to a new contact, large batch sends, emails mentioning money or credentials) route through an approval queue for human review.

Trust model

Decide how much autonomy your agent gets:

Trust levelWhat the agent can doWhen to use
Read-onlyReceive and classify email, no sendingEarly testing, sentiment monitoring
SupervisedDraft replies, human approves before sendNew agents, high-value interactions
Semi-autonomousSend within templates and rate limits, flag exceptionsProduction agents with proven behavior
Fully autonomousSend any content within policy boundsMature agents with strong guardrails

Start at the lowest trust level your use case allows. Increase autonomy as you build confidence in the agent's behavior.


Common mistakes

Using a personal inbox instead of an agent inbox

Giving your agent access to your Gmail or Outlook account means it reads your personal email, can send as you, and any mistakes damage your personal reputation. Use a dedicated agent inbox on a subdomain so failures are isolated.

No guardrails on sending

A traditional ESP won't stop your agent from sending 10,000 emails in a loop. Without rate limits, suppression checking, and deduplication at the infrastructure layer, a single bug can destroy your domain reputation in hours.

Trusting inbound email content

Every inbound email is untrusted input. If your agent reads raw email content and acts on it, attackers can manipulate its behavior through prompt injection. Always scan and sanitize before the agent processes content. See the email-security skill for detection patterns.

Ignoring the send response

When an agent inbox provider blocks a send (rate limit, suppression, cooldown), the agent should accept the decision and move on. Agents that retry blocked sends in a loop waste resources and signal a design problem.

Skipping domain authentication

Sending from a provider's shared domain works for testing but tanks deliverability in production. Set up your own domain with SPF, DKIM, and DMARC before going live. See the domain-authentication skill.

No human oversight path

Even fully autonomous agents need an escalation path. Wire transfers, legal requests, credential-related emails, and anomalous patterns should route to a human. Design the escape hatch before you need it.

Provisioning too many inboxes without warming

Creating 100 agent inboxes and immediately sending from all of them triggers spam filters. New domains and IPs need gradual volume increases. See the email-warmup skill for warmup schedules.

Not handling bounces

If your agent keeps sending to addresses that bounce, ISPs treat your domain as a spam source. Ensure your provider auto-suppresses hard bounces, or build this yourself if using a traditional ESP.


References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.