概述
本技能涵盖为 Web 应用构建可靠的电子邮件系统，包括事务性邮件发送、模板设计、送达率优化与收件箱放置。它涉及与邮件服务提供商（Resend、AWS SES、SendGrid、Postmark）的集成，使用 React Email 和 MJML 构建响应式 HTML 邮件模板，配置用于送达的 DNS 记录（SPF、DKIM、DMARC），管理邮件类型（事务性、通知、营销），队列管理，以及退信/投诉处理。
当需要发送欢迎邮件、密码重置、订单确认、通知摘要、营销活动或任何系统生成的邮件时，可使用本技能。在调试送达问题或在邮件服务商之间迁移时同样适用。
核心原则
- 事务性与营销邮件不同：事务性邮件（密码重置、收据）必须即时可靠送达；营销邮件（通讯、促销）可批量发送且应包含退订链接。切勿在同一发送域名上混用两者。
- HTML 邮件不等于 Web 开发：邮件客户端按 2004 年的方式渲染 HTML，不支持 flexbox、grid 或现代 CSS。应使用表格布局、内联样式，并跨客户端测试。React Email 和 MJML 可抽象这些痛点。
- 送达率靠积累：SPF、DKIM、DMARC 是基本要求而非保证。需维持低退信率（< 2%）、低投诉率（< 0.1%），并逐步预热新发送域名。
- 一切走队列：切勿在请求处理器中同步发送邮件。将发送任务入队，避免阻塞用户请求，并支持失败重试。
- 发送前测试：开发环境使用 Mailtrap 或 Ethereal，在多个客户端预览（Litmus、Email on Acid），并验证每个链接可用。
关键模式
模式 1：使用 Resend 的 React Email 模板
适用场景：构建类型安全、基于组件、具备现代开发体验且可靠投递的邮件模板。
实现包括两部分：一是 React Email 模板文件（emails/welcome.tsx），从 @react-email/components 导入 Html、Head、Body、Container、Section、Text、Button、Img、Hr、Link、Preview 等组件，定义 WelcomeEmailProps 接口（userName、loginUrl、guideUrl），用 Container、Section、Button 等构建欢迎邮件结构，并通过 styles 内联样式对象控制外观；最后设置 WelcomeEmail.PreviewProps 供预览并默认导出。二是发送服务文件（lib/email.ts），从 resend 导入 Resend，初始化客户端，定义 EmailTemplate 联合类型（welcome、password-reset、invoice）与模板映射、主题映射，编写 sendEmail 函数调用 resend.emails.send，出错时抛出 EmailSendError。
理由：React Email 提供基于组件的邮件模板、TypeScript 类型安全、开发热重载，并自动转换为邮件安全 HTML；Resend 提供高送达率、简洁 API 及开箱即用的 React Email 集成；类型安全的模板定义可防止发送缺少属性的邮件。
模式 2：带重试逻辑的邮件队列
适用场景：任何生产环境的邮件发送。切勿在请求处理器中同步发送邮件。
实现使用 bullmq 的 Queue 和 Worker 以及 ioredis，定义 emailQueue 并设置 defaultJobOptions（attempts: 3、指数退避、保留已完成/失败任务）；queueEmail 函数用于入队；emailWorker 后台处理任务，设置并发与限流（如每分钟最多 100 封以符合服务商速率限制）；监听 failed 事件，重试耗尽后告警。应用代码中先同步创建数据库用户，再异步入队欢迎邮件。
理由：队列将投递与用户请求解耦，服务商缓慢或宕机时注册仍能成功；指数退避处理瞬时失败；限流防止超出服务商配额；任务保留便于调试投递问题。
模式 3：用于送达率的 DNS 配置
适用场景：设置新发送域名或诊断送达问题。
DNS 记录示例：SPF 记录（TXT）授权发送服务器，如 "v=spf1 include:_spf.resend.com include:amazonses.com ~all"；DKIM 记录（通常为 CNAME）进行加密签名；DMARC 记录（TXT）设置对齐策略，建议从 p=none 监控起步，逐步过渡到 quarantine 再到 reject；退信域（Return-Path）配置 MX 与 SPF。文档还给出用 dns/promises 的 resolveTxt、resolveCname、resolveMx 编程验证 SPF、DMARC、DKIM 的 TypeScript 代码。
理由：邮件认证（SPF、DKIM、DMARC）向接收服务器证明邮件合法；缺少认证会进入垃圾箱。SPF 声明哪些服务器可为域名发送；DKIM 加密签名邮件；DMARC 告知接收方如何处理未认证邮件。
模式 4：退信与投诉处理
适用场景：长期维护发件人声誉与送达率。
通过 Webhook 处理邮件事件：硬退信永久加入抑制列表并更新用户记录；软退信 30 天内达到 3 次后抑制；投诉立即抑制并移除全部营销订阅；发送前用 canSendTo 检查抑制列表。
理由：服务商会监控退信与投诉率，超过阈值（退信 > 5%、投诉 > 0.1%）会暂停发送。抑制列表可防止向已知无效地址发送，保护发件人声誉。
邮件服务商对比
- Resend：面向开发者的事务性邮件；每天免费 100 封，50k 每月 20 美元；原生支持 React Email；优势为最佳开发体验，React Email 团队出品。
- AWS SES：高用量、成本优化；每 1000 封 0.10 美元；通过渲染支持；规模化时最便宜。
- SendGrid：营销加事务性；每天免费 100 封；通过渲染支持；优势为营销自动化。
- Postmark：事务性可靠性；10k 每月 15 美元；通过渲染支持；事务性送达最佳。
反模式
- 在请求处理器中发送邮件：阻塞用户响应且无重试；应改为后台工作队列。
- 事务性与营销邮件使用同一域名：营销声誉会影响密码重置；应使用独立子域名（如 mail.app.com 与 news.app.com）。
- 没有抑制列表：反复退信会破坏发件人声誉；每次发送前应检查抑制列表。
- 邮件 HTML 使用 div 布局：在 Outlook、Gmail 中渲染错乱；应使用表格布局或 React Email/MJML。
- 通知邮件中没有退订链接：违反 CAN-SPAM，引发垃圾邮件投诉；应提供一键退订。