菜单
Choose and configure an email service provider. Use when setting up email for a new project, comparing providers, migrating between providers, or adding failover.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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.
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.
| name | provider-setup |
| description | Choose and configure an email service provider. Use when setting up email for a new project, comparing providers, migrating between providers, or adding failover. |
| license | MIT |
Choose an email service provider and configure it properly so your emails get delivered reliably.
domain-authentication - set up SPF, DKIM, DMARC before sendingemail-warmup - ramp volume gradually after provider setupbounce-handling - process delivery failures from webhook eventssender-reputation - monitor and protect your sending reputationBest for: AI agents and autonomous systems that send email.
Best for: Developer-first teams, startups, TypeScript/React stacks.
Best for: Teams where transactional email delivery is mission-critical.
Best for: High-volume senders (100K+/month) already on AWS with engineering resources.
Best for: Teams needing marketing + transactional in one platform (legacy choice).
Best for: Apps needing strong inbound email parsing, or EU data residency.
Best for: Enterprise senders at 1M+/month who need deep deliverability analytics.
| Need | Recommendation |
|---|---|
| Transactional only (receipts, alerts, auth) | Postmark or Resend |
| Marketing only (newsletters, campaigns) | Dedicated marketing platform (Mailchimp, ConvertKit, Loops) |
| Mixed but transactional is critical | Two providers: one for transactional, one for marketing. Never mix. |
| Mixed and cost-sensitive | SendGrid Pro (use Subusers to separate) or SES with Configuration Sets |
| Monthly volume | Recommendation | Why |
|---|---|---|
| Under 10K | Managed provider (Resend, Postmark) | Cost difference vs SES is negligible. Save the operational overhead. |
| 10K-100K | Still managed | $50-100/month buys you deliverability management and support. |
| 100K-1M | SES becomes compelling | Saves $50-500/month if you have engineering resources. Use a managed provider as failover. |
| 1M+ | SES or SparkPost | Per-email cost difference is significant at this scale. Need dedicated IPs regardless. |
If you're reading this and just need an answer:
Shared IP is fine when:
Dedicated IP is important when:
Critical rule: A dedicated IP with insufficient volume (under ~50K/month) will hurt your deliverability. ISPs see low-volume IPs as suspicious. You need consistent daily sending to keep a dedicated IP warm.
Never send from your root domain. Use a subdomain to isolate sending reputation from your main domain.
Root domain: example.com (website, corporate email)
Transactional: mail.example.com (receipts, auth, notifications)
Marketing: news.example.com (newsletters, campaigns)
If your sending reputation takes a hit, your root domain and corporate email are unaffected.
This is the most important structural decision. Mixing transactional and marketing email on the same domain or IP is the number one deliverability mistake.
Marketing email gets spam complaints. Spam complaints lower your domain/IP reputation. Lower reputation means your password reset emails land in spam.
How providers handle separation:
Every provider can notify you about delivery events via webhooks. At minimum, handle these three:
| Event | Action |
|---|---|
| Hard bounce | Suppress the address immediately. Never send to it again. |
| Spam complaint | Suppress the address immediately. Investigate the cause. |
| Soft bounce | Track count. After 3-5 soft bounces over multiple days, suppress. |
Without webhooks, you're blind. You won't know about bounces until users complain, and you'll keep sending to dead addresses, which tanks your reputation.
Webhook security:
If email is critical to your product, don't rely on a single provider. Every provider has outages.
| Error type | Fail over? | Why |
|---|---|---|
| Rate limited (429) | Yes | Temporary, another provider can handle it |
| Server error (5xx) | Yes | Provider is having issues |
| Network error | Yes | Provider unreachable |
| Auth failure (401/403) | No | Your credentials are wrong, another provider won't help |
| Validation error (422) | No | Your payload is malformed, fix it |
Order providers by weight (primary gets highest weight). On a retryable failure, try the next provider. Track consecutive failures per provider - after a threshold (e.g., 3 in a row), deprioritize that provider. Reset the counter on any success.
Switching providers without losing deliverability requires a gradual transition.
Both providers can coexist in DNS without conflict:
; SPF - include both during transition
mail.example.com TXT "v=spf1 include:_spf.resend.com include:spf.postmarkapp.com -all"
; DKIM - different selectors, no conflict
resend._domainkey.mail.example.com CNAME ...
pm1._domainkey.mail.example.com CNAME ...
; DMARC - unchanged
_dmarc.mail.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
If your sending reputation gets damaged, it affects everything - your website, your internal email, all of it. Always use a subdomain.
Marketing email gets complaints. Complaints lower reputation. Your password reset emails end up in spam. Use separate subdomains and ideally separate providers.
You have no idea whether emails are being delivered. You keep sending to dead addresses. Your bounce rate climbs. Your reputation drops. Set up webhooks from day one.
Your provider goes down. Password resets, 2FA codes, order confirmations - all stopped. Even if you don't actively use a second provider, have the integration configured and tested.
A dedicated IP that doesn't send enough email (~50K+/month) looks suspicious to ISPs. Low-volume senders are better off on a well-managed shared IP pool.
Without signature verification, anyone who discovers your webhook URL can feed it fake events - marking real addresses as bounced, suppressing legitimate recipients, or triggering false complaints in your system.