用途
该技能面向事务性邮件（Transactional Email）的工程实现，帮助在应用中设计并搭建可靠的邮件发送与接收基础设施。典型触发场景包括：为应用选择事务性邮件服务商、构建邮件发送基础设施（队列、重试、幂等）、开发跨客户端渲染的 HTML 邮件模板、为发送域配置 SPF/DKIM/DMARC、实现入站邮件处理（回复邮件、邮件转工单），以及排查送达率问题（退信、进入垃圾箱、认证失败）。
不适用场景：营销邮件活动与自动化、营销邮件的送达率（名单清洗、分群）、后端 API 与服务架构、通用后台任务基础设施、推送通知与移动消息、应用内实时通知。
主要能力
服务商与模板选型：事务性 ESP 可选 Resend（现代开发体验）、Postmark（送达率）、SendGrid（规模）、AWS SES（成本）；模板方案可选 React Email（React 组件）、MJML（响应式标记）、Maizzle（面向邮件的 Tailwind）；HTML 邮件测试工具包括 Litmus、Email on Acid、Parcel（需自行核对各服务商能力与定价）。
发送管道正确性：业务事件与 outbox 行在同一数据库事务中提交，对（用途、收件人、业务事件）加唯一约束；用租约或数据库锁认领行，重试时复用同一服务商幂等键与载荷；将服务商受理与消息 ID 与投递状态分开持久化；对 webhook 原始请求体验签，按唯一事件 ID 幂等入库，并按服务商事件时间/序列与既定优先级归并状态，避免迟到事件清除后续的投诉、退订或硬退信抑制。
模板开发：React Email 以 React 组件与 TypeScript 编写模板，服务端渲染为 HTML，内置预览服务器；MJML 以 XML 标记编译为基于表格的响应式 HTML，自动处理响应式列、内边距与 Outlook 条件注释；Maizzle 用 Tailwind 工具类编写并编译为内联样式与邮件安全 HTML，带热重载开发服务器。渲染约束：收件人包含经典 Outlook 时使用表格布局与内联关键样式，浏览器预览不能证明收件箱渲染效果。
送达率工程：为每个发送域发布并对齐 SPF、DKIM、DMARC，DMARC 从 p=none 开始收集聚合报告再逐步收紧；使用专用发送子域（如 mail.yourdomain.com）隔离事务性与营销邮件声誉；配置退信与投诉抑制；区分事务性与营销邮件的发送域、IP 乃至 ESP。资料还给出送达率设置清单（SPF 记录、≥2048 位 RSA DKIM、_dmarc 记录与 rua、DMARC 策略推进、RFC 8058 退订头、退信/投诉 webhook、Google Postmaster Tools、预热计划）。
入站邮件处理：基于 webhook 的架构，ESP 在指定地址接收邮件、解析后 POST 结构化数据到端点；解析数据含发件人、收件人（用唯一令牌路由）、主题、纯文本与 HTML 正文、附件等；常见用例包括回复邮件评论、邮件转工单、文档摄取、邮件审批；安全上需验签、净化 HTML 正文、扫描附件、限流并使用不可猜测的唯一令牌。
使用方式
工作流为：先确认邮件任务类型（服务商选择、发送基础设施、模板、送达率或入站处理），将生命周期营销、通用后端或移动通知类工作路由到相邻技能；再按决策树选择服务商与模板方案；然后应用发送管道正确性、认证、渲染与入站处理指引；最后通过导航参考核实服务商当前能力、限制与政策。资料提到，若运行时安装了 cloudflare-email-service 可加载它，否则先查阅官方 Email Service 文档再实现绑定或 API。
适用场景与限制
适用于需要可靠事务性邮件投递的应用工程团队，尤其是涉及密码重置、收据、通知、回复邮件与邮件转工单的系统。限制与注意事项：资料强调不得在请求处理器中内联发送邮件，必须入队为后台任务；服务商“已受理”不等于已投递；不得仅因投递 webhook 未到达就重发；不得从打开像素推断同意、参与或再参与（Apple Mail 隐私保护会预取像素），抑制与同意代码路径应以点击、回复或显式动作为准；DMARCbis（RFC 9989）废止 RFC 7489，移除 pct、rf、ri 标签，以 t=y 替代 pct 渐进，np= 设置不存在子域策略，可能向邮件列表发帖的域不应发布 p=reject；共享 IP 与专用 IP 的选择需依据稳定流量、预热计划与服务商支持，资料未给出通用月度阈值；预热节奏与暂停规则、名单清洗、日落政策、再许可与打开率测量归营销邮件自动化所有。