菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Diagnose email problems and plan email infrastructure. Use when emails land in spam, bounce rates spike, deliverability drops, open rates decline, providers throttle sending, you need to set up email for a new product, or you're not sure which email skill to use.
Build dashboards, alerts, and monitoring systems for email sending operations. Use when setting up deliverability monitoring, configuring alert thresholds, checking blocklists, building email metrics dashboards, or responding to deliverability incidents.
Classify inbound email replies by intent and route them appropriately. Use when building reply handling for outreach, support, or transactional email - detecting interested, not interested, OOO, bounce, unsubscribe, forwarded, and question replies.
Maintain email conversation context across messages using threading headers. Use when building thread reconstruction, linking replies to conversations, detecting thread hijacking, stripping quoted content, or providing thread context to AI agents.
Receive, parse, and process incoming email via provider webhooks. Use when setting up inbound email handling, parsing MIME messages, extracting content from replies, detecting threads, filtering spam on inbound, or routing incoming messages.
Protect email pipelines from injection attacks, phishing, content manipulation, and AI agent exploitation. Use when building inbound email processing, sanitizing email content, detecting phishing or BEC, securing AI agents that read email, or hardening email infrastructure against spoofing and data exfiltration.
基于 SOC 职业分类
| name | inbox-providers |
| description | 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. |
| license | MIT |
Choose an agent-native inbox provider so your AI agent can send, receive, and manage email with built-in guardrails.
provider-setup - traditional ESP selection (Resend, Postmark, SES, SendGrid) for human-managed sendingemail-security - prompt injection detection, content sanitization, canary tokensinbound-processing - MIME parsing, header extraction, webhook processing for inbound emailreply-classification - categorizing reply intent (interested, OOO, objection, etc.)rate-limiting - volume controls that protect sender reputationdomain-authentication - SPF, DKIM, DMARC setup before sendingsuppression-lists - managing bounces, complaints, and opt-outsTraditional 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 mode | Human sender | AI agent |
|---|---|---|
| Over-sending | Unlikely (manual process) | Common (no fatigue, no judgment) |
| Hitting suppressed addresses | Checks suppression list | Doesn't know the list exists unless enforced |
| Sending duplicate emails | Notices they already sent | No memory between invocations |
| Following malicious instructions | Reads critically | Treats email content as potential instructions |
| Managing reputation | Monitors dashboards | Has no concept of sender reputation |
| Handling bounces | Reads bounce notifications | Keeps 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.
Best for: Teams that need policy enforcement and governance on agent email. Agents that send outbound sequences, lifecycle emails, or handle inbound reply workflows.
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.
Best for: Agents that need to self-provision their own inbox without human setup. OpenClaw and framework-native workflows.
LobsterMail.create() handles account signup automatically.safeBodyForLLM() for safe content access.Best for: Teams that want graduated trust - start agents sandboxed and increase autonomy over time.
| Need | Recommendation |
|---|---|
| Policy enforcement and deliverability protection | Molted Email |
| Many inboxes, email-as-identity for agents | AgentMail |
| Agent self-provisioning, no human setup | LobsterMail |
| Graduated trust with human oversight | MailMolt |
| Just sending (no inbound, no agent autonomy) | Traditional ESP (see provider-setup skill) |
| Architecture | Recommendation |
|---|---|
| Agent sends outbound sequences with reply handling | Molted Email (policy engine prevents over-send, intent classification on replies) |
| Agent needs its own inbox to converse like a human | AgentMail (inbox-first design, semantic search, threading) |
| Agent provisions itself at runtime | LobsterMail (no human in the provisioning loop) |
| Prototype with safety rails | MailMolt (sandbox mode until you trust the agent) |
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.
| Capability | Traditional ESP | Agent inbox provider |
|---|---|---|
| Sending email | API call | API call |
| Receiving email | Configure inbound webhooks, parse MIME | Built-in inbox, parsed and classified |
| Suppression checking | Query your own suppression database before every send | Checked automatically, send rejected if suppressed |
| Rate limiting | Implement sliding window counters | Enforced at infrastructure layer |
| Deduplication | Track dedupe keys yourself | Built-in, returns cached result on duplicate |
| Cooldowns | Track per-recipient send times | Enforced automatically (e.g., 10-min per-recipient cooldown) |
| Bounce handling | Process webhook events, update suppression list | Auto-suppression on hard bounce |
| Prompt injection scanning | Build your own detection pipeline | Built-in scanning before agent sees content |
| Thread linking | Parse In-Reply-To/References headers, match against stored IDs | Automatic thread reconstruction |
| Reply classification | Build or integrate intent classifier | Built-in (interested, OOO, objection, etc.) |
| Multi-provider failover | Implement failover logic, manage multiple provider configs | Configured automatically |
| Audit trail | Log every decision yourself | Every 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.
Regardless of which provider you choose, the setup pattern is similar.
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
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.
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.
Set up inbound handling to receive replies and route them:
Watch these metrics from day one:
| Metric | Healthy threshold | Action 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 |
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.
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.
Decide how much autonomy your agent gets:
| Trust level | What the agent can do | When to use |
|---|---|---|
| Read-only | Receive and classify email, no sending | Early testing, sentiment monitoring |
| Supervised | Draft replies, human approves before send | New agents, high-value interactions |
| Semi-autonomous | Send within templates and rate limits, flag exceptions | Production agents with proven behavior |
| Fully autonomous | Send any content within policy bounds | Mature 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.
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.
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.
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.
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.
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.
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.
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.
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.