很多人第一次接邮件系统只把它当成“发验证码”的工具。注册发一封、忘记密码发一封好像就结束了。等产品上线后才发现邮件会影响登录、通知、账单、交付、营销、召回和用户信任。邮件系统不是一个边缘功能。它是产品和用户之间最稳定的异步沟通渠道之一。用户不在线时你仍然可以通过邮件完成提醒、确认、恢复、交付和转化。早期产品不需要做复杂邮件平台但要从第一版就把邮件类型、发送服务、模板、退订、日志和送达率想清楚。否则后面很容易出现邮件丢失、进垃圾箱、用户收不到验证码、营销邮件乱发等问题。先区分事务邮件和营销邮件接入邮件系统前先把邮件分成两类事务邮件和营销邮件。事务邮件是用户触发或系统必须发送的邮件比如验证码、魔法链接、密码重置、支付成功、发票、任务完成、异常提醒、安全通知。这类邮件和用户操作强相关要求及时、可靠、可追踪。营销邮件是你主动发给用户的内容比如产品更新、教程、活动、促销、召回、Newsletter。它更强调分组、退订、频率控制和内容质量。这两类邮件不要混在一起。事务邮件必须保证送达不能因为用户退订营销邮件就收不到密码重置。营销邮件必须有退订机制不能用“系统通知”的名义一直发广告。第一版可以用同一家服务商发送但在代码和配置里要明确区分类型。选择邮件服务商不要只看价格邮件服务商的选择会直接影响送达率和维护成本。常见选择包括 Resend、Postmark、SendGrid、Mailgun、Amazon SES、Brevo 等。不同服务商在价格、开发体验、送达率、模板管理、日志能力和合规支持上差异很大。早期产品可以优先选择开发体验好、日志清楚、事务邮件稳定的服务。价格不是唯一指标。邮件发不出去、进垃圾箱、日志查不到会比省一点费用更贵。如果你主要发事务邮件可以优先看发送 API 是否简单、事件 webhook 是否完整、日志能保留多久、失败原因是否清楚。如果你要做 Newsletter再看分组、退订、活动统计和批量发送能力。独立开发者不要一开始就追求最便宜。先选一个能稳定把邮件送到用户收件箱的方案。域名配置是送达率的底线邮件系统不是拿到 API Key 就结束。你必须配置发送域名并正确设置 SPF、DKIM、DMARC。SPF 告诉收件方哪些服务器可以代表你的域名发邮件。DKIM 给邮件加签名证明内容没有被篡改。DMARC 告诉收件方遇到伪造邮件时如何处理并能帮助你监控域名被滥用的情况。如果这些配置不完整邮件很容易进垃圾箱甚至被直接拒收。尤其是验证码、登录链接、支付通知这类关键邮件一旦送达不稳定会直接影响产品使用。第一版可以先用子域名发邮件比如mail.example.com或notify.example.com。不要随便用个人邮箱或未验证域名发产品邮件。邮件模板要按场景设计邮件模板不是简单把文字塞进 HTML。不同邮件有不同目标。验证码邮件要突出验证码、有效时间和安全提示。魔法链接邮件要突出按钮和过期说明。密码重置邮件要说明如果不是本人操作可以忽略。任务完成邮件要提供结果入口。支付成功邮件要包含金额、套餐、时间和支持入口。模板设计要简洁少用复杂图片和重样式。很多邮件客户端对 CSS 支持不一致过度设计可能导致展示异常。关键内容必须在纯文本或简单 HTML 中可读。每封邮件都应该包含发件人、主题、核心动作、必要说明和支持联系方式。营销邮件还必须包含退订入口。发送日志和状态必须保存邮件发出去了不等于用户收到了。你需要记录邮件发送状态。至少要保存邮件类型、收件人、触发用户、发送时间、服务商 message_id、发送状态、失败原因。如果服务商支持 webhook还可以记录 delivered、bounced、opened、clicked 等事件。事务邮件尤其需要日志。用户说“我没收到验证码”时你要能快速查到邮件是否发出、是否被退信、是否被服务商拒绝、是否被投递成功。没有日志你只能猜。第一版可以建一张简单的email_logs表。不要把所有邮件正文都长期保存避免隐私风险但关键元数据要能查。失败重试和频率限制要做好邮件系统一定会遇到失败服务商接口超时、邮箱不存在、域名配置错误、用户邮箱满、临时退信。你需要设计失败处理。对于验证码、魔法链接、密码重置这类实时邮件如果发送失败要给用户明确提示并允许稍后重试。对于任务完成、通知类邮件可以进入队列重试几次。对于永久退信的邮箱不要无限重发。同时要做频率限制。验证码邮件不能让用户无限触发否则会带来成本和滥用风险。常见限制是同一邮箱每分钟、每小时、每天限制发送次数。邮件发送既要可靠也要防止被滥用。什么时候需要邮件队列第一版产品可以直接调用邮件 API 发送。但只要邮件数量增加或者邮件发送不应该阻塞用户操作就应该考虑队列。比如用户提交任务后结果生成完成再发通知支付成功后发票邮件可能稍后发送批量营销邮件需要分批发送失败邮件需要延迟重试。这些都适合放进队列。队列的好处是让主流程更稳定。用户操作完成后不必等待邮件服务商响应。邮件发送失败也不会影响核心业务状态。早期可以用简单任务队列、数据库队列表、框架自带队列或云服务。不要一开始为了邮件引入过重架构但也不要让邮件发送卡住核心请求。一个最小邮件系统结构第一版可以这样设计邮件类型 - 登录验证码 - 密码重置 - 支付成功 - 任务完成 - 重要异常通知 - 产品更新或 Newsletter 基础模块 - 邮件服务商 API - 域名 SPF / DKIM / DMARC - 模板管理 - email_logs 表 - 失败重试 - 频率限制 - 营销邮件退订这个结构不复杂但能覆盖早期产品最关键的邮件场景。你可以先把事务邮件做好再逐步增加营销邮件和自动化邮件。总结邮件系统不是只发验证码。它支撑登录、找回密码、支付确认、任务交付、通知提醒和用户召回。早期接入时要区分事务和营销邮件配置好域名认证设计场景化模板记录发送日志并处理失败和频率限制。把邮件系统做好不会立刻让产品变得华丽但会让产品更可靠。用户在关键时刻能收到邮件本身就是一种信任。作业列出你的产品必须发送的事务邮件。列出哪些邮件属于营销邮件并设计退订方式。检查发送域名是否配置 SPF、DKIM、DMARC。设计一张email_logs表记录关键发送状态。为验证码或魔法链接设计频率限制规则。下一节课消息通知设计通知不是越多越好而是要在正确时间提醒用户完成下一步。原文链接邮件系统如何接入 | Harries Blog™
邮件系统如何接入
很多人第一次接邮件系统只把它当成“发验证码”的工具。注册发一封、忘记密码发一封好像就结束了。等产品上线后才发现邮件会影响登录、通知、账单、交付、营销、召回和用户信任。邮件系统不是一个边缘功能。它是产品和用户之间最稳定的异步沟通渠道之一。用户不在线时你仍然可以通过邮件完成提醒、确认、恢复、交付和转化。早期产品不需要做复杂邮件平台但要从第一版就把邮件类型、发送服务、模板、退订、日志和送达率想清楚。否则后面很容易出现邮件丢失、进垃圾箱、用户收不到验证码、营销邮件乱发等问题。先区分事务邮件和营销邮件接入邮件系统前先把邮件分成两类事务邮件和营销邮件。事务邮件是用户触发或系统必须发送的邮件比如验证码、魔法链接、密码重置、支付成功、发票、任务完成、异常提醒、安全通知。这类邮件和用户操作强相关要求及时、可靠、可追踪。营销邮件是你主动发给用户的内容比如产品更新、教程、活动、促销、召回、Newsletter。它更强调分组、退订、频率控制和内容质量。这两类邮件不要混在一起。事务邮件必须保证送达不能因为用户退订营销邮件就收不到密码重置。营销邮件必须有退订机制不能用“系统通知”的名义一直发广告。第一版可以用同一家服务商发送但在代码和配置里要明确区分类型。选择邮件服务商不要只看价格邮件服务商的选择会直接影响送达率和维护成本。常见选择包括 Resend、Postmark、SendGrid、Mailgun、Amazon SES、Brevo 等。不同服务商在价格、开发体验、送达率、模板管理、日志能力和合规支持上差异很大。早期产品可以优先选择开发体验好、日志清楚、事务邮件稳定的服务。价格不是唯一指标。邮件发不出去、进垃圾箱、日志查不到会比省一点费用更贵。如果你主要发事务邮件可以优先看发送 API 是否简单、事件 webhook 是否完整、日志能保留多久、失败原因是否清楚。如果你要做 Newsletter再看分组、退订、活动统计和批量发送能力。独立开发者不要一开始就追求最便宜。先选一个能稳定把邮件送到用户收件箱的方案。域名配置是送达率的底线邮件系统不是拿到 API Key 就结束。你必须配置发送域名并正确设置 SPF、DKIM、DMARC。SPF 告诉收件方哪些服务器可以代表你的域名发邮件。DKIM 给邮件加签名证明内容没有被篡改。DMARC 告诉收件方遇到伪造邮件时如何处理并能帮助你监控域名被滥用的情况。如果这些配置不完整邮件很容易进垃圾箱甚至被直接拒收。尤其是验证码、登录链接、支付通知这类关键邮件一旦送达不稳定会直接影响产品使用。第一版可以先用子域名发邮件比如mail.example.com或notify.example.com。不要随便用个人邮箱或未验证域名发产品邮件。邮件模板要按场景设计邮件模板不是简单把文字塞进 HTML。不同邮件有不同目标。验证码邮件要突出验证码、有效时间和安全提示。魔法链接邮件要突出按钮和过期说明。密码重置邮件要说明如果不是本人操作可以忽略。任务完成邮件要提供结果入口。支付成功邮件要包含金额、套餐、时间和支持入口。模板设计要简洁少用复杂图片和重样式。很多邮件客户端对 CSS 支持不一致过度设计可能导致展示异常。关键内容必须在纯文本或简单 HTML 中可读。每封邮件都应该包含发件人、主题、核心动作、必要说明和支持联系方式。营销邮件还必须包含退订入口。发送日志和状态必须保存邮件发出去了不等于用户收到了。你需要记录邮件发送状态。至少要保存邮件类型、收件人、触发用户、发送时间、服务商 message_id、发送状态、失败原因。如果服务商支持 webhook还可以记录 delivered、bounced、opened、clicked 等事件。事务邮件尤其需要日志。用户说“我没收到验证码”时你要能快速查到邮件是否发出、是否被退信、是否被服务商拒绝、是否被投递成功。没有日志你只能猜。第一版可以建一张简单的email_logs表。不要把所有邮件正文都长期保存避免隐私风险但关键元数据要能查。失败重试和频率限制要做好邮件系统一定会遇到失败服务商接口超时、邮箱不存在、域名配置错误、用户邮箱满、临时退信。你需要设计失败处理。对于验证码、魔法链接、密码重置这类实时邮件如果发送失败要给用户明确提示并允许稍后重试。对于任务完成、通知类邮件可以进入队列重试几次。对于永久退信的邮箱不要无限重发。同时要做频率限制。验证码邮件不能让用户无限触发否则会带来成本和滥用风险。常见限制是同一邮箱每分钟、每小时、每天限制发送次数。邮件发送既要可靠也要防止被滥用。什么时候需要邮件队列第一版产品可以直接调用邮件 API 发送。但只要邮件数量增加或者邮件发送不应该阻塞用户操作就应该考虑队列。比如用户提交任务后结果生成完成再发通知支付成功后发票邮件可能稍后发送批量营销邮件需要分批发送失败邮件需要延迟重试。这些都适合放进队列。队列的好处是让主流程更稳定。用户操作完成后不必等待邮件服务商响应。邮件发送失败也不会影响核心业务状态。早期可以用简单任务队列、数据库队列表、框架自带队列或云服务。不要一开始为了邮件引入过重架构但也不要让邮件发送卡住核心请求。一个最小邮件系统结构第一版可以这样设计邮件类型 - 登录验证码 - 密码重置 - 支付成功 - 任务完成 - 重要异常通知 - 产品更新或 Newsletter 基础模块 - 邮件服务商 API - 域名 SPF / DKIM / DMARC - 模板管理 - email_logs 表 - 失败重试 - 频率限制 - 营销邮件退订这个结构不复杂但能覆盖早期产品最关键的邮件场景。你可以先把事务邮件做好再逐步增加营销邮件和自动化邮件。总结邮件系统不是只发验证码。它支撑登录、找回密码、支付确认、任务交付、通知提醒和用户召回。早期接入时要区分事务和营销邮件配置好域名认证设计场景化模板记录发送日志并处理失败和频率限制。把邮件系统做好不会立刻让产品变得华丽但会让产品更可靠。用户在关键时刻能收到邮件本身就是一种信任。作业列出你的产品必须发送的事务邮件。列出哪些邮件属于营销邮件并设计退订方式。检查发送域名是否配置 SPF、DKIM、DMARC。设计一张email_logs表记录关键发送状态。为验证码或魔法链接设计频率限制规则。下一节课消息通知设计通知不是越多越好而是要在正确时间提醒用户完成下一步。原文链接邮件系统如何接入 | Harries Blog™
