Back to Details

sales-transactional-email

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Transactional Email Delivery

事务性邮件投递

Help the user with transactional/triggered email — from provider selection and template design through API integration, SMTP relay, deliverability, and monitoring. This skill is tool-agnostic but includes platform-specific guidance for SendGrid, Postmark, Mailgun, Brevo, Customer.io, Mailchimp/Mandrill, and Amazon SES.
为用户提供事务性/触发式邮件相关帮助——覆盖从服务商选型、模板设计到API集成、SMTP中继、送达率优化和监控的全流程。本技能不绑定特定工具，但包含SendGrid、Postmark、Mailgun、Brevo、Customer.io、Mailchimp/Mandrill和Amazon SES等平台的专属指引。

Step 1 — Gather context

步骤1 — 收集上下文信息

Ask the user:
  1. What type of transactional email do you need help with?
    • A) Order confirmations / receipts / shipping notifications
    • B) Password resets / account verification / 2FA
    • C) Welcome emails / onboarding sequences triggered by signup
    • D) Billing / invoice / subscription notifications
    • E) Alert / notification emails (activity, mentions, reminders)
    • F) Provider selection — choosing the right transactional email service
    • G) Delivery issues — emails not arriving, going to spam, delayed
    • H) API/SMTP integration — connecting your app to a provider
    • I) Template design — building reusable transactional templates
    • J) Monitoring & analytics — tracking delivery, opens, bounces
    • K) Something else — describe it
  2. What's your current setup?
    • A) No provider yet — starting from scratch
    • B) Using SendGrid
    • C) Using Postmark
    • D) Using Mailgun
    • E) Using Brevo (Sendinblue)
    • F) Using Customer.io
    • G) Using Mailchimp / Mandrill
    • H) Using Amazon SES
    • I) Using another provider
    • J) Using my own SMTP server
  3. What's your volume?
    • A) Low (< 1K emails/day)
    • B) Medium (1K-50K/day)
    • C) High (50K-500K/day)
    • D) Very high (500K+/day)
If the user's request already provides most of this context, skip directly to the relevant step. Lead with your best-effort answer using reasonable assumptions (stated explicitly), then ask only the most critical 1-2 clarifying questions at the end.
向用户询问以下信息：
  1. 你需要哪类事务性邮件的相关帮助？
    • A) 订单确认/收据/物流通知
    • B) 密码重置/账户验证/双因素认证(2FA)
    • C) 欢迎邮件/注册触发的入职引导序列
    • D) 账单/发票/订阅通知
    • E) 提醒/通知邮件（活动、提及、待办提醒）
    • F) 服务商选型——选择合适的事务性邮件服务
    • G) 投递问题——邮件未送达、进入垃圾邮件、投递延迟
    • H) API/SMTP集成——将你的应用与服务商对接
    • I) 模板设计——搭建可复用的事务性邮件模板
    • J) 监控与分析——追踪投递、打开、退信数据
    • K) 其他——请描述具体需求
  2. 你当前的配置是怎样的？
    • A) 还未选择服务商——从零开始搭建
    • B) 使用SendGrid
    • C) 使用Postmark
    • D) 使用Mailgun
    • E) 使用Brevo（原Sendinblue）
    • F) 使用Customer.io
    • G) 使用Mailchimp / Mandrill
    • H) 使用Amazon SES
    • I) 使用其他服务商
    • J) 使用自建SMTP服务器
  3. 你的邮件发送量级是多少？
    • A) 低（每日<1000封）
    • B) 中（每日1000-5万封）
    • C) 高（每日5万-50万封）
    • D) 极高（每日50万封以上）
如果用户的请求已经提供了大部分上下文信息，可以直接跳转到相关步骤。 先基于合理假设（需明确说明假设内容）给出你能力范围内的最优解答，最后仅询问1-2个最关键的补充问题即可。

Step 2 — Strategy and approach

步骤2 — 策略与方案

Transactional vs marketing email

事务性邮件 vs 营销邮件

Transactional emails are triggered by a user action or system event — they're expected and usually 1:1. They don't require marketing consent (CAN-SPAM exemption) but must be genuinely transactional.
TransactionalMarketing
Order confirmationPromotional campaign
Password resetNewsletter
Shipping notificationProduct announcement
Account verificationRe-engagement campaign
Invoice / receiptDiscount / sale notification
Key principle: Keep transactional and marketing email on separate sending infrastructure (different IPs/domains) so marketing reputation issues don't affect transactional delivery.
事务性邮件由用户操作或系统事件触发，是用户预期接收的、通常为一对一发送的邮件。它们不需要获得营销类同意（符合CAN-SPAM豁免要求），但必须是真实的事务性内容。
事务性邮件营销邮件
订单确认推广活动
密码重置时事通讯
物流通知产品发布公告
账户验证召回活动
账单/收据折扣/促销通知
核心原则：事务性邮件和营销邮件要使用独立的发送基础设施（不同IP/域名），避免营销邮件的信誉问题影响事务性邮件的投递。

Provider selection framework

服务商选型框架

FactorSendGridPostmarkMailgunBrevoCustomer.ioSES
Best forScale + marketing comboDeliverability-firstDeveloper flexibilityAll-in-one + marketingBehavior-triggeredRaw volume + cost
DeliverabilityGoodExcellent (98.7%)GoodGoodGoodGood (self-managed)
Pricing modelPer emailPer emailPer emailVolume tiersPer profilePer email (cheapest)
Free tier100/day100/month1K/month (trial)300/dayNone62K/month (from EC2)
SMTP relayYesYesYesYesNoYes
REST APIYesYesYesYesYesYes
TemplatesDynamic (Handlebars)HandlebarsHandlebarsUI builder + APILiquidBasic
Inbound parsingYesYesYesYesNoYes
WebhooksYes (Event Webhook)Yes (7 types)Yes (8 events)YesYesSNS notifications
选型维度SendGridPostmarkMailgunBrevoCustomer.ioSES
适用场景大规模发送+营销组合需求优先保障送达率开发者灵活度需求一体化+营销需求行为触发场景原始发送量+成本优先
送达率良好优秀（98.7%）良好良好良好良好（自主管理）
定价模式按邮件数量计费按邮件数量计费按邮件数量计费量级阶梯定价按用户profile计费按邮件数量计费（最低）
免费额度每日100封每月100封每月1000封（试用）每日300封无每月6.2万封（从EC2发送）
SMTP中继支持支持支持支持不支持支持
REST API支持支持支持支持支持支持
模板能力动态模板（Handlebars）HandlebarsHandlebarsUI搭建器+APILiquid基础能力
入站解析支持支持支持支持不支持支持
Webhook能力支持（事件Webhook）支持（7种类型）支持（8种事件）支持支持SNS通知

Template best practices

模板最佳实践

  1. Keep it simple — transactional emails should be clear, not flashy
  2. Include essential info above the fold — order number, tracking link, action button
  3. Use dynamic parameters — never hardcode user-specific data
  4. Test across clients — Outlook, Gmail, Apple Mail render differently
  5. Include plain-text fallback — some recipients/clients need it
  6. Brand consistently — logo, colors, footer, but don't over-design
  1. 保持简洁——事务性邮件应该清晰明了，无需花哨设计
  2. 核心信息放在首屏——订单号、追踪链接、操作按钮等
  3. 使用动态参数——永远不要硬编码用户专属数据
  4. 跨客户端测试——Outlook、Gmail、Apple Mail的渲染逻辑不同
  5. 提供纯文本 fallback 版本——部分收件人/客户端需要纯文本内容
  6. 保持品牌一致性——统一logo、配色、页脚，但不要过度设计

Deliverability for transactional email

事务性邮件送达率优化

  1. Dedicated sending domain — use 
    mail.example.com
    or 
    notify.example.com
    , not your main domain
  2. Authenticate everything — SPF, DKIM, DMARC (p=quarantine or p=reject)
  3. Dedicated IP — at 50K+/month volume, get a dedicated IP and warm it
  4. Separate streams — keep transactional and marketing on different IPs/subdomains
  5. Monitor bounces — suppress hard bounces immediately, track soft bounce patterns
  6. Watch complaint rates — transactional should be near 0% complaints
  1. 专属发送域名——使用
    mail.example.com
    或
    notify.example.com
    ，不要使用主域名
  2. 全链路身份验证——配置SPF、DKIM、DMARC（策略设置为p=quarantine或p=reject）
  3. 专属IP——月发送量达到5万封以上时，申请专属IP并完成IP预热
  4. 独立发送流——事务性邮件和营销邮件使用不同IP/子域名发送
  5. 监控退信情况——立即拉黑硬退信地址，追踪软退信规律
  6. 关注投诉率——事务性邮件的投诉率应该接近0%

Step 3 — Platform-specific guidance

步骤3 — 平台专属指引

In Brevo

Brevo 平台

  • API endpoint: 
    POST https://api.brevo.com/v3/smtp/email
  • Auth: 
    api-key
    header
  • Templates: Create in Brevo UI, reference via 
    templateId
    with 
    params
    object
  • SMTP relay: 
    smtp-relay.brevo.com:587
    (STARTTLS), login = account email, password = SMTP key
  • Webhooks: Create via API — events: delivered, opened, clicked, hardBounce, softBounce, unsubscribed, complaint, blocked
  • Free tier: 300 emails/day (transactional included)
  • Dedicated IP: Available on paid plans, configure in Settings → Senders, Domains & Dedicated IPs
  • Strength: All-in-one — transactional + marketing + CRM in one platform. Good for teams that don't want separate tools.
  • Platform skill: 
    /sales-brevo
  • API 端点: 
    POST https://api.brevo.com/v3/smtp/email
  • 鉴权方式: 
    api-key
    请求头
  • 模板: 在Brevo UI中创建，通过
    templateId
    和
    params
    对象引用
  • SMTP 中继: 
    smtp-relay.brevo.com:587
    （STARTTLS），登录名=账户邮箱，密码=SMTP密钥
  • Webhook: 通过API创建——支持事件：送达、打开、点击、硬退信、软退信、取消订阅、投诉、被拦截
  • 免费额度: 每日300封邮件（包含事务性邮件）
  • 专属IP: 付费套餐可用，在设置 → 发件人、域名与专属IP中配置
  • 优势: 一体化平台——事务性邮件+营销+CRM集成，适合不想使用多套工具的团队
  • 平台专属技能: 
    /sales-brevo

In Iterable

Iterable 平台

  • API endpoint: 
    POST https://api.iterable.com/api/email/target
    (US) or 
    https://api.eu.iterable.com/api/email/target
    (EU)
  • Auth: 
    Api-Key
    header
  • How it works: Create a triggered campaign in Iterable, then fire via API with recipient email, campaign ID, and personalization data fields. Triggered campaigns are the mechanism for transactional email — there's no separate transactional API.
  • Templates: Handlebars templating with dynamic variables, conditional blocks, and Catalog data for product recommendations
  • Webhooks: System webhooks for delivery events (send, open, click, bounce, complaint). Configure at Integrations > System Webhooks.
  • No SMTP relay: Iterable is API-only — no SMTP gateway option
  • Strength: Best when you're already using Iterable for marketing engagement and want transactional email in the same platform. Triggered campaigns share the same template engine and analytics as marketing campaigns.
  • Limitation: Enterprise pricing (MAU-based). Triggered campaigns are the same mechanism as marketing triggers — no separate SLA tier for transactional. No SMTP for legacy apps.
  • Platform skill: 
    /sales-iterable
  • API 端点: 
    POST https://api.iterable.com/api/email/target
    （美国区）或 
    https://api.eu.iterable.com/api/email/target
    （欧盟区）
  • 鉴权方式: 
    Api-Key
    请求头
  • 使用逻辑: 在Iterable中创建触发式活动，然后通过API传入收件人邮箱、活动ID和个性化数据字段触发发送。触发式活动是事务性邮件的实现载体，没有单独的事务性API
  • 模板: 支持Handlebars模板，包含动态变量、条件块、可用于商品推荐的Catalog数据
  • Webhook: 系统Webhook支持投递事件（发送、打开、点击、退信、投诉），在集成 > 系统Webhook中配置
  • 无SMTP中继: Iterable仅支持API调用，没有SMTP网关选项
  • 优势: 适合已经使用Iterable做营销触达，希望在同一平台管理事务性邮件的团队。触发式活动和营销活动共享相同的模板引擎和分析能力
  • 局限性: 企业级定价（按月活用户计费）。触发式活动和营销触发使用相同机制，没有事务性邮件专属SLA。传统应用无法使用SMTP对接
  • 平台专属技能: 
    /sales-iterable

In Braze

Braze 平台

  • API endpoint: 
    POST https://rest.iad-XX.braze.com/transactional/v1/campaigns/{campaign_id}/send
    (instance-specific URL)
  • Auth: Bearer token (
    Authorization: Bearer YOUR_REST_API_KEY
    )
  • How it works: Create a Transactional Email Campaign in the Braze dashboard, then trigger via API with recipient and personalization data. Transactional campaigns are separate from marketing Campaigns/Canvas.
  • Templates: Liquid templating (not Handlebars) with Connected Content for real-time external data at send time
  • SLA guarantees: 99.9% uptime SLA. Transactional sends are prioritized over marketing messages in Braze's infrastructure.
  • Webhooks: Currents streaming for delivery events (send, delivery, open, click, bounce, spam) — streams to data warehouse (Snowflake, S3, etc.), not individual webhook URLs
  • No SMTP relay: Braze is API-only for transactional — no SMTP gateway option
  • Strength: Best when you're already using Braze for marketing engagement and want transactional email in the same platform with unified user profiles and analytics.
  • Limitation: Enterprise pricing (MAU-based). Overkill if you only need transactional email. No SMTP relay for legacy apps.
  • Platform skill: 
    /sales-braze
  • API 端点: 
    POST https://rest.iad-XX.braze.com/transactional/v1/campaigns/{campaign_id}/send
    （实例专属URL）
  • 鉴权方式: Bearer token（
    Authorization: Bearer YOUR_REST_API_KEY
    ）
  • 使用逻辑: 在Braze后台创建事务性邮件活动，然后通过API传入收件人和个性化数据触发发送。事务性活动和营销活动/Canvas相互独立
  • 模板: 使用Liquid模板（非Handlebars），支持发送时实时拉取外部数据的Connected Content能力
  • SLA 保障: 99.9% uptime SLA。在Braze基础设施中，事务性邮件发送优先级高于营销消息
  • Webhook: 通过Currents数据流推送投递事件（发送、送达、打开、点击、退信、垃圾邮件投诉）——数据流同步到数据仓库（Snowflake、S3等），不支持单独的Webhook URL配置
  • 无SMTP中继: Braze事务性邮件仅支持API调用，没有SMTP网关选项
  • 优势: 适合已经使用Braze做营销触达，希望在同一平台管理事务性邮件、统一用户画像和分析数据的团队
  • 局限性: 企业级定价（按月活用户计费）。如果仅需要事务性邮件功能性价比太低。传统应用无法使用SMTP对接
  • 平台专属技能: 
    /sales-braze

In GetResponse (MAX only)

GetResponse 平台（仅MAX版本）

  • API endpoint: 
    POST https://api.getresponse.com/v3/transactional-emails
    (retail) or 
    POST https://api3.getresponse360.com/v3/transactional-emails
    (MAX)
  • Auth: 
    X-Auth-Token: api-key {your-api-key}
    header. MAX users must also include 
    X-Domain
    header.
  • How it works: Send transactional emails via API with recipient, subject, and HTML content. Transactional emails are separate from marketing newsletters and autoresponders.
  • Important: Transactional email is only available on MAX/Enterprise plans. Users on Free, Starter, Marketer, or Creator plans cannot send transactional email through GetResponse — they must use a separate provider (SendGrid, Postmark, Mailgun, etc.).
  • Rate limits: Same as marketing API — 30,000 calls/10 min, 80 calls/sec, max 10 simultaneous.
  • No SMTP relay: GetResponse transactional is API-only.
  • Strength: Convenient if you're already on GetResponse MAX for marketing and want transactional in the same platform with unified contact data.
  • Limitation: MAX-only pricing makes this impractical unless you're already on MAX for other reasons. No separate SLA tier for transactional delivery. Limited template engine compared to SendGrid/Postmark.
  • Platform skill: 
    /sales-getresponse
  • API 端点: 
    POST https://api.getresponse.com/v3/transactional-emails
    （零售版）或 
    POST https://api3.getresponse360.com/v3/transactional-emails
    （MAX版）
  • 鉴权方式: 
    X-Auth-Token: api-key {your-api-key}
    请求头。MAX用户还需要传入
    X-Domain
    请求头
  • 使用逻辑: 通过API传入收件人、主题、HTML内容发送事务性邮件。事务性邮件和营销 newsletter、自动回复相互独立
  • 重要提示: 事务性邮件仅MAX/企业版套餐可用。免费版、Starter、Marketer、Creator套餐用户无法通过GetResponse发送事务性邮件，需要使用其他独立服务商（SendGrid、Postmark、Mailgun等）
  • 频率限制: 和营销API相同——每10分钟3万次调用，每秒80次调用，最多10个并发请求
  • 无SMTP中继: GetResponse事务性邮件仅支持API调用
  • 优势: 适合已经使用GetResponse MAX做营销，希望在同一平台管理事务性邮件、统一联系人数据的用户
  • 局限性: 仅MAX版本可用，若非因其他需求已使用MAX版本，性价比太低。没有事务性投递专属SLA。相比SendGrid/Postmark模板能力有限
  • 平台专属技能: 
    /sales-getresponse

In SendGrid

SendGrid 平台

  • API endpoint: 
    POST https://api.sendgrid.com/v3/mail/send
  • Auth: Bearer token
  • Templates: Dynamic templates with Handlebars (
    {{variable}}
    )
  • SMTP relay: 
    smtp.sendgrid.net:587
  • Webhooks: Event Webhook — delivered, open, click, bounce, dropped, deferred, spam report
  • Free tier: 100 emails/day forever
  • Strength: Scale + ecosystem. Good for teams also using Twilio for SMS.
  • Platform skill: 
    /sales-sendgrid
  • API 端点: 
    POST https://api.sendgrid.com/v3/mail/send
  • 鉴权方式: Bearer token
  • 模板: 支持Handlebars动态模板（
    {{variable}}
    ）
  • SMTP 中继: 
    smtp.sendgrid.net:587
  • Webhook: 事件Webhook——支持送达、打开、点击、退信、丢弃、延迟、垃圾邮件投诉
  • 免费额度: 永久每日100封
  • 优势: 大规模发送能力+完善生态，适合同时使用Twilio发送短信的团队
  • 平台专属技能: 
    /sales-sendgrid

In Postmark

Postmark 平台

  • API endpoint: 
    POST https://api.postmarkapp.com/email
  • Auth: 
    X-Postmark-Server-Token
    header
  • Templates: Handlebars with layouts (shared headers/footers)
  • Message Streams: Separate transactional and broadcast streams (enforced)
  • SMTP relay: 
    smtp.postmarkapp.com:587
  • Webhooks: 7 types — delivery, bounce, spam complaint, open, click, subscription change, inbound
  • Free tier: 100 emails/month
  • Strength: Best deliverability (98.7% inbox placement). Opinionated — enforces transactional/broadcast separation. Sender vetting on signup.
  • Platform skill: 
    /sales-postmark
  • API 端点: 
    POST https://api.postmarkapp.com/email
  • 鉴权方式: 
    X-Postmark-Server-Token
    请求头
  • 模板: 支持带布局的Handlebars模板（可共用页眉/页脚）
  • 消息流: 强制分离事务性和广播消息流
  • SMTP 中继: 
    smtp.postmarkapp.com:587
  • Webhook: 7种类型——送达、退信、垃圾邮件投诉、打开、点击、订阅变更、入站邮件
  • 免费额度: 每月100封
  • 优势: 行业领先的送达率（98.7%收件箱到达率），设计理念清晰，强制分离事务性/广播流，注册时会对发件人进行资质审核
  • 平台专属技能: 
    /sales-postmark

In Mailgun

Mailgun 平台

  • API endpoint: 
    POST https://api.mailgun.net/v3/{domain}/messages
  • Auth: Basic auth with 
    api:key-xxx
  • Templates: Handlebars
  • SMTP relay: 
    smtp.mailgun.org:587
  • Webhooks: 8 event types — accepted, delivered, opened, clicked, unsubscribed, complained, bounced, failed
  • Strength: Developer-friendly with flexible routing and inbound parsing. Good for complex email processing.
  • Platform skill: 
    /sales-mailgun
  • API 端点: 
    POST https://api.mailgun.net/v3/{domain}/messages
  • 鉴权方式: 基础鉴权，账号为
    api
    ，密码为
    key-xxx
  • 模板: 支持Handlebars
  • SMTP 中继: 
    smtp.mailgun.org:587
  • Webhook: 8种事件类型——接收、送达、打开、点击、取消订阅、投诉、退信、发送失败
  • 优势: 对开发者友好，支持灵活的路由和入站解析，适合复杂邮件处理场景
  • 平台专属技能: 
    /sales-mailgun

In Customer.io

Customer.io 平台

  • API endpoint: Transactional Messages API
  • Templates: Liquid templating
  • Strength: Behavior-triggered transactional messages tied to customer journey data. Best when you need transactional email + marketing automation with unified customer profiles.
  • Platform skill: 
    /sales-customerio
  • API 端点: 事务性消息API
  • 模板: 支持Liquid模板
  • 优势: 基于用户旅程数据的行为触发事务性消息，适合需要同时使用事务性邮件+营销自动化、统一用户画像的场景
  • 平台专属技能: 
    /sales-customerio

In Mailchimp / Mandrill

Mailchimp / Mandrill 平台

  • Mandrill is Mailchimp's transactional email add-on ($20/mo + per-email)
  • API endpoint: 
    POST https://mandrillapp.com/api/1.0/messages/send
  • Templates: Mandrill templates with merge tags
  • Strength: Good if you're already on Mailchimp for marketing and want one vendor.
  • Platform skill: 
    /sales-mailchimp
  • Mandrill是Mailchimp的事务性邮件附加组件（20美元/月 + 按邮件数量计费）
  • API 端点: 
    POST https://mandrillapp.com/api/1.0/messages/send
  • 模板: 带合并标签的Mandrill模板
  • 优势: 适合已经使用Mailchimp做营销，希望使用同一服务商的用户
  • 平台专属技能: 
    /sales-mailchimp

In SendPulse

SendPulse 平台

  • API endpoint: 
    POST https://api.sendpulse.com/smtp/emails
    with 
    subject
    , 
    from
    , 
    to
    , 
    html
    , and optional 
    attachments
  • Auth: OAuth 2.0 — exchange 
    client_id
    + 
    client_secret
    for a 1-hour access token. Static API key also supported.
  • Delivery tracking: 
    GET /smtp/emails/{id}
    for per-message status, 
    GET /smtp/bounces
    for bounce list, 
    GET /smtp/unsubscribe
    for unsubscribes
  • Webhooks: 
    smtp_delivered
    , 
    smtp_opened
    , 
    smtp_clicked
    , 
    smtp_bounced
    , 
    smtp_unsubscribed
  • SDKs: PHP, Python, Ruby, Java, Node.js, C#, Go
  • Free tier: 12,000 transactional emails/month
  • Dedicated IP: Available on higher-tier paid plans
  • Strength: Generous free tier for transactional email with broad SDK support. Good for startups and mid-volume senders who want quick integration without per-email pricing pressure.
  • Limitation: OAuth token expiry (1 hour) adds complexity vs. static API keys. Less specialized in transactional delivery than Postmark or SendGrid.
  • Platform skill: 
    /sales-sendpulse
  • API 端点: 
    POST https://api.sendpulse.com/smtp/emails
    ，需传入
    subject
    、
    from
    、
    to
    、
    html
    和可选的
    attachments
    参数
  • 鉴权方式: OAuth 2.0——使用
    client_id
    + 
    client_secret
    换取有效期1小时的访问令牌，也支持静态API密钥
  • 投递追踪: 调用
    GET /smtp/emails/{id}
    查询单条消息状态，
    GET /smtp/bounces
    获取退信列表，
    GET /smtp/unsubscribe
    获取取消订阅列表
  • Webhook: 支持
    smtp_delivered
    、
    smtp_opened
    、
    smtp_clicked
    、
    smtp_bounced
    、
    smtp_unsubscribed
    事件
  • SDK: 支持PHP、Python、Ruby、Java、Node.js、C#、Go
  • 免费额度: 每月1.2万封事务性邮件
  • 专属IP: 高阶付费套餐可用
  • 优势: 事务性邮件免费额度高，SDK支持全面，适合希望快速集成、没有按邮件数量计费压力的初创公司和中等量级发件人
  • 局限性: OAuth令牌1小时有效期，相比静态API密钥复杂度更高。事务性投递的专业性弱于Postmark或SendGrid
  • 平台专属技能: 
    /sales-sendpulse

In Amazon SES

Amazon SES 平台

  • API: AWS SDK or SMTP interface
  • Auth: AWS IAM credentials
  • Cheapest at scale: ~$0.10 per 1,000 emails
  • Strength: Raw cost efficiency at high volume. Requires more self-management (reputation monitoring, bounce handling, suppression lists).
  • Weakness: No built-in template UI, no analytics dashboard — you build everything yourself or use a wrapper service.
  • API: 支持AWS SDK或SMTP接口
  • 鉴权方式: AWS IAM凭证
  • 大规模场景成本最低: 每1000封邮件约0.1美元
  • 优势: 高量级场景下成本优势显著，需要更多自主管理能力（信誉监控、退信处理、拉黑列表管理）
  • 劣势: 没有内置模板UI，没有分析看板——所有能力都需要自行开发或对接封装服务

Step 4 — Actionable guidance

步骤4 — 可落地指导

Integration checklist

集成检查清单

  1. Choose API or SMTP — API is faster and more reliable; SMTP is easier for legacy apps
  2. Set up authentication — API key or credentials for your chosen provider
  3. Create templates — design templates in the provider's UI, reference by ID in API calls
  4. Implement sending — API call or SMTP send from your application code
  5. Set up webhooks — track delivery, bounces, complaints, opens/clicks
  6. Handle errors — retry logic for 5xx errors, suppress on hard bounces
  7. Monitor — track delivery rates, bounce rates, complaint rates daily
  1. 选择API或SMTP——API速度更快、更可靠；SMTP更适合传统应用对接
  2. 配置鉴权——为你选择的服务商配置API密钥或凭证
  3. 创建模板——在服务商UI中设计模板，在API调用中通过ID引用
  4. 实现发送逻辑——在应用代码中调用API或通过SMTP发送邮件
  5. 配置Webhook——追踪投递、退信、投诉、打开/点击事件
  6. 错误处理——5xx错误配置重试逻辑，硬退信地址立即拉黑
  7. 监控——每日追踪投递率、退信率、投诉率

Key metrics to track

需追踪的核心指标

MetricHealthy rangeAction if outside
Delivery rate> 98%Check bounces, verify addresses at signup
Bounce rate< 2%Suppress hard bounces, validate emails
Complaint rate< 0.01%Ensure emails are genuinely transactional
Open rate40-80% (transactional)Check subject lines, preview text
Time to inbox< 10 secondsCheck provider status, API latency
指标健康范围超出范围应对措施
投递率> 98%排查退信原因，注册时验证邮箱地址有效性
退信率< 2%拉黑硬退信地址，验证邮箱有效性
投诉率< 0.01%确保邮件是真实的事务性内容
打开率40-80%（事务性邮件）优化主题行、预览文本
收件箱耗时< 10秒检查服务商状态、API延迟

Gotchas

注意事项

  1. Don't mix transactional and marketing on the same IP/domain — marketing reputation problems will tank transactional delivery. Use separate subdomains and ideally separate IPs.
  2. "Transactional" has a legal definition — CAN-SPAM exempts transactional emails from opt-out requirements, but the email must be primarily transactional. An order confirmation with a 50% coupon at the top is marketing, not transactional.
  3. SMTP is not real-time — SMTP queues add latency. For time-sensitive emails (2FA codes, password resets), use the REST API for faster delivery.
  4. Webhooks can fail silently — if your webhook endpoint is down, you'll miss delivery/bounce events. Implement webhook logging and alerting.
  5. Template rendering varies by client — Outlook uses Word's rendering engine. Always test templates in Litmus or Email on Acid, especially for layout-heavy designs.
  1. 不要在同一个IP/域名下混合发送事务性和营销邮件——营销邮件的信誉问题会严重影响事务性邮件的投递，使用独立子域名，最好使用独立IP
  2. "事务性"有法律定义——CAN-SPAM豁免了事务性邮件的退订要求，但邮件必须主要是事务性内容。顶部带有50%折扣优惠券的订单确认属于营销邮件，不属于事务性邮件
  3. SMTP不是实时的——SMTP队列会增加延迟，对于时效性强的邮件（2FA验证码、密码重置），使用REST API获取更快的投递速度
  4. Webhook可能静默失败——如果你的Webhook端点宕机，你会丢失投递/退信事件，需要配置Webhook日志和告警
  5. 不同客户端的模板渲染逻辑不同——Outlook使用Word的渲染引擎，一定要在Litmus或Email on Acid中测试模板，尤其是布局复杂的设计

Related skills

相关技能

  • /sales-iterable
    — Iterable platform help (triggered campaigns for transactional email, Studio journeys, cross-channel)
  • /sales-braze
    — Braze platform help (transactional email API, Canvas Flow, cross-channel orchestration)
  • /sales-brevo
    — Brevo platform help (transactional email, marketing, CRM)
  • /sales-sendgrid
    — SendGrid platform help
  • /sales-postmark
    — Postmark platform help
  • /sales-mailgun
    — Mailgun platform help
  • /sales-customerio
    — Customer.io platform help
  • /sales-mailchimp
    — Mailchimp/Mandrill platform help
  • /sales-getresponse
    — GetResponse platform help (transactional email on MAX plan, marketing automation, webinars)
  • /sales-sendpulse
    — SendPulse platform help (SMTP transactional email, marketing automation, chatbots)
  • /sales-deliverability
    — Cross-platform email deliverability (SPF/DKIM/DMARC, warmup, reputation)
  • /sales-email-marketing
    — Opt-in marketing email strategy (not transactional)
  • /sales-integration
    — Connect email tools with CRM and other systems
  • /sales-do
    — Not sure which skill to use? The router matches any sales objective to the right skill. Install: 
    npx skills add sales-skills/sales --skills sales-do
  • /sales-iterable
    — Iterable平台帮助（事务性邮件触发式活动、Studio旅程、跨渠道触达）
  • /sales-braze
    — Braze平台帮助（事务性邮件API、Canvas Flow、跨渠道编排）
  • /sales-brevo
    — Brevo平台帮助（事务性邮件、营销、CRM）
  • /sales-sendgrid
    — SendGrid平台帮助
  • /sales-postmark
    — Postmark平台帮助
  • /sales-mailgun
    — Mailgun平台帮助
  • /sales-customerio
    — Customer.io平台帮助
  • /sales-mailchimp
    — Mailchimp/Mandrill平台帮助
  • /sales-getresponse
    — GetResponse平台帮助（MAX套餐事务性邮件、营销自动化、webinar）
  • /sales-sendpulse
    — SendPulse平台帮助（SMTP事务性邮件、营销自动化、聊天机器人）
  • /sales-deliverability
    — 跨平台邮件送达率优化（SPF/DKIM/DMARC、IP预热、信誉管理）
  • /sales-email-marketing
    — 许可式营销邮件策略（非事务性）
  • /sales-integration
    — 邮件工具与CRM等其他系统的对接
  • /sales-do
    — 不确定使用哪个技能？路由会将任意销售目标匹配到合适的技能。安装命令：
    npx skills add sales-skills/sales --skills sales-do

Examples

示例

Example 1: Choosing a transactional email provider

示例1：选择事务性邮件服务商

User says: "We're a SaaS startup sending about 5K transactional emails/day — order confirmations, password resets, and activity notifications. What provider should we use?" Skill does: Evaluates volume (medium), use cases (standard transactional), and likely needs (reliability, good deliverability, reasonable cost). Recommends Postmark for best deliverability or SendGrid for more flexibility. Compares pricing at 150K/month volume. Result: Clear recommendation with reasoning, cost comparison, and setup next steps
用户提问: "我们是SaaS初创公司，每天发送约5000封事务性邮件——订单确认、密码重置和活动通知。应该选哪个服务商？" 技能处理: 评估量级（中等）、使用场景（标准事务性）、潜在需求（可靠性、高送达率、合理成本），推荐优先保障送达率的Postmark或灵活度更高的SendGrid，对比15万封/月量级的成本 结果: 给出带理由的清晰推荐、成本对比和下一步搭建步骤

Example 2: Debugging delivery delays

示例2：排查投递延迟问题

User says: "Our password reset emails are taking 30+ seconds to arrive via SMTP through Mailgun" Skill does: Identifies SMTP queuing as likely cause. Recommends switching to REST API for time-sensitive emails. Shows Mailgun API example for password reset. Suggests monitoring with webhooks. Result: Root cause identified, API migration code provided, monitoring setup
用户提问: "我们通过Mailgun的SMTP发送的密码重置邮件需要30秒以上才能送达" 技能处理: 定位SMTP队列是可能的原因，建议时效性邮件切换到REST API，提供密码重置场景的Mailgun API示例，建议使用Webhook监控 结果: 定位根本原因，提供API迁移代码，给出监控配置方案

Example 3: Setting up transactional email in Brevo

示例3：在Brevo中搭建事务性邮件

User says: "How do I send order confirmation emails through the Brevo API with dynamic order data?" Skill does: Walks through creating a template in Brevo UI → calling POST /smtp/email with templateId and params → setting up delivery webhooks → error handling and retry logic Result: Working transactional email flow with template, API integration, and monitoring
用户提问: "我怎么通过Brevo API发送带动态订单数据的订单确认邮件？" 技能处理: 一步步讲解：在Brevo UI中创建模板 → 调用POST /smtp/email接口传入templateId和params参数 → 配置投递Webhook → 错误处理和重试逻辑 结果: 提供可运行的事务性邮件流，包含模板、API集成和监控配置

Troubleshooting

故障排查

Transactional emails going to spam

事务性邮件进入垃圾邮件

Symptom: Order confirmations or account emails landing in spam Cause: Usually domain authentication issues, shared IP reputation, or content triggers Solution: 1) Verify SPF/DKIM/DMARC are properly configured. 2) Check if you're on a shared IP with bad reputation — consider dedicated IP. 3) Review email content for spam trigger words. 4) Ensure you're not mixing marketing content into transactional emails. See 
/sales-deliverability
.
症状: 订单确认或账户邮件进入垃圾邮件文件夹 原因: 通常是域名认证问题、共享IP信誉问题或内容触发垃圾规则 解决方案: 1) 验证SPF/DKIM/DMARC配置正确；2) 检查是否使用了信誉差的共享IP——考虑使用专属IP；3) 检查邮件内容是否包含垃圾邮件触发词；4) 确保没有在事务性邮件中混入营销内容。参考
/sales-deliverability

High bounce rates on transactional email

事务性邮件退信率过高

Symptom: Bounce rate exceeding 2% on transactional sends Cause: Sending to invalid addresses — users entering fake emails at signup, typos, abandoned accounts Solution: 1) Implement real-time email validation at signup (ZeroBounce, Kickbox, or provider's built-in). 2) Use double opt-in for account creation. 3) Suppress hard bounces immediately. 4) Clean your contact list quarterly.
症状: 事务性邮件退信率超过2% 原因: 向无效地址发送邮件——用户注册时填写虚假邮箱、输入错误、账户废弃 解决方案: 1) 注册时引入实时邮箱验证（ZeroBounce、Kickbox或服务商内置能力）；2) 账户注册使用双重确认；3) 立即拉黑硬退信地址；4) 每季度清理联系人列表

Webhook events not arriving

Webhook事件未送达

Symptom: No webhook callbacks received after sending emails Cause: Webhook endpoint misconfigured, firewall blocking provider IPs, or SSL certificate issues Solution: 1) Verify webhook URL is publicly accessible (not localhost). 2) Check that your endpoint returns 200 within 5 seconds. 3) Whitelist provider IP ranges if behind a firewall. 4) Check provider's webhook logs for failed delivery attempts.
症状: 发送邮件后没有收到Webhook回调 原因: Webhook端点配置错误、防火墙拦截了服务商IP、SSL证书问题 解决方案: 1) 验证Webhook URL是公网可访问的（不是localhost）；2) 确认端点可以在5秒内返回200状态码；3) 如果有防火墙，将服务商IP段加入白名单；4) 检查服务商的Webhook日志查看失败投递记录