注册确认邮件模板不能改，或者发信请求报错、收件箱始终没信？
先用项目当前允许的默认模板测试注册触发、实际收件和账号验证闭环；如果还要验收品牌文案或样式，再确认项目规则，评估自有 SMTP 或适用的付费方案。测试收件地址是否可用，取决于项目的邮件发送配置。
新建 Supabase 免费项目的独立开发者，可据此验证自家产品的注册流程。
QA 工程师可用它区分邮件触发、真实收件和账号验证各自能证明什么；负责认证邮件的技术负责人，则可判断何时需要调整发送配置。
最后更新于 2026 年 10 月 25 日；规则核对自 Supabase 免费层邮件模板变更公告、Auth 邮件模板文档及自定义 SMTP 文档。
第一步：先判定项目属于哪种环境
不要只看“免费项目”就假定模板行为相同。先到项目控制台确认项目创建时间、当前套餐，以及 Auth 邮件是否走 Supabase 默认邮件服务；记录项目是托管项目、自托管实例，还是本地开发环境。
截至 2026 年 10 月 25 日，Supabase 公告说明：自 2026 年 6 月 3 日起，新建免费项目在使用默认邮件服务时，不能修改认证邮件模板。公告同时说明，此限制不适用于该日期前创建的免费项目、付费方案、自行配置 SMTP 的项目和自托管项目；实际适用范围仍应以项目当前控制台和最新官方说明为准。
新建免费项目还能修改注册确认邮件模板吗？
如果它使用默认邮件服务，就按公告说明把模板限制视为适用，不要把本地成功修改模板当成托管项目也能修改的证据。自托管和本地开发有各自的模板配置方式；本地项目可通过 supabase/config.toml 和 HTML 模板文件调整，但这只验证本地模板设置，不证明托管项目的邮件发送结果。本地模板配置文档明确区分了本地 CLI 工作流与托管项目。
第二步：把验收目标拆成两件事
先写清本轮测试要通过什么，避免把“邮件能发”误当成“品牌邮件验收通过”。
- 只验注册功能闭环：默认模板足以用于检查注册请求、确认入口或验证码，以及验证完成后的账号状态。此时重点是功能链路，不是邮件是否采用品牌配色或自定义措辞。
- 还要验收品牌邮件：把主题行、正文、样式、发件人展示和模板变量列为单独验收项。默认邮件实际送达，并不等于这些品牌要求已经满足。
Supabase Auth 邮件模板中的 {{ .ConfirmationURL }} 是确认链接，{{ .Token }} 是一次性验证码，{{ .TokenHash }} 是验证码的哈希值；{{ .SiteURL }} 和 {{ .RedirectTo }} 则与应用站点地址、调用时传入的重定向地址有关。检查链接时，应按当前流程核对对应变量和允许的重定向配置，不要仅凭邮件中出现一个链接，就认定它会跳到预期页面。
第三步：选地址前先查发送权限
为什么默认 SMTP 不能给任意测试地址发邮件？
Supabase 官方文档说明，默认 SMTP 主要用于非生产测试；未配置自有 SMTP 时，Auth 只会向项目所属团队的预授权地址发送邮件。向其他收件地址发送，可能返回 Email address not authorized。因此，临时邮箱、个人邮箱或同事邮箱都不能先验地视为获准地址；先核对组织团队成员和当前项目设置，再判断地址是否适合本轮测试。
还要把发送频率算进测试安排。官方发送限制文档当前列出的默认邮件发送额度为 每小时 2 封，且默认邮件服务没有送达或运行时间的 SLA 保证。注册测试若反复点“重发”，可能先碰到频率限制；不要把被限流误诊为模板问题。该数值可能调整，执行前应重新查看当前 Auth 发送限制。
场景例子：独立开发者在新托管项目里用个人地址注册，接口返回了结果，但收件箱没有邮件。先看返回错误和目标地址是否在获准范围，再核对发送额度；只有请求确实被接受后，才继续检查收件箱和邮件内容。这个顺序能避免把权限拒绝错归因于模板限制。
第四步：在隔离环境触发一封注册邮件
开始操作前，为自家产品使用专门的测试项目或明确隔离的测试环境。记录项目标识、目标环境、测试账号邮箱、注册时间和前端返回结果；不要用真实用户资料填充演示账号，也不要在日志或截图里暴露不必要的个人信息。
随后按这条流程执行：
- 确认前端连接的是预期的 Supabase 项目，而不是生产项目。
- 检查注册表单提交的邮箱地址与计划使用的收件地址完全一致。
- 核实该地址符合当前发送配置的允许范围；不符合时先换为获准地址，或在有需要时评估自有 SMTP。
- 在应用中提交一次注册，记录请求结果和错误信息，不连续重发。
- 等待并检查测试收件箱；若没有邮件，先确认请求是否被拒绝、是否受到频率限制，再查实际收件。
这一步得到的是一次具体请求的证据，不是对所有收件地址、邮件客户端或环境的普遍保证。需要等待邮件的场景，可参考邮件到达时间的排查节点，但排查时仍应以 Supabase 项目实际配置为准。
第五步：收到邮件后，逐项验收链接和账号状态
测试收件地址收到邮件后还要检查什么？
先对照本次注册记录，确认邮件收件人正确，主题和内容属于注册确认邮件，并检查确认链接或验证码是否对应当前测试。若流程使用链接，打开后核对落地页面和返回路径；若使用验证码，按应用的预期方式提交，并记录验证结果。不要把“邮件已收到”直接记成“账号验证成功”。
默认邮件模板怎样用于测试注册验证闭环？
从注册页提交开始，依次记录以下三个结果，三者分开判定：
- 发送请求：应用或接口返回了什么，有没有授权、配置或限流错误。
- 实际收件：邮件是否进入获准的测试收件箱，收件人和内容是否对应本次注册。
- 账号验证：打开确认入口或提交验证码后，应用是否进入预期页面，账号是否呈现预期的已验证状态。
当这三项都符合自家产品的验收标准，才可判定注册验证闭环通过。邮件客户端的链接预取等行为可能影响确认链接；Supabase 文档也提示某些邮件安全功能会预先访问链接，因此单次点击后的结果不应脱离应用状态单独判断。若项目使用验证码流程，应检查验证码验证结果，而非只看邮件中是否出现数字。
第六步：按验收条件决定是否配置自有 SMTP
Supabase Auth 邮件模板受限后，怎么选择下一步？
按目标作决定，不必为了测试注册功能先改邮件基础设施：
- ✅ 若目标只是确认自家注册、收件和验证流程，且获准测试地址可用：继续用当前默认模板完成闭环，并记录模板样式不属于本轮验收。
- ✅ 若必须验收自定义文案、品牌样式或模板变量：先确认项目是否属于公告所述限制范围，再评估配置自有 SMTP 或适用的付费方案。配置后仍须重新验证发送、实际收件和账号状态；不能承诺切换后一定送达。
- ✅ 若使用本地环境调模板：把结果标记为“本地模板验证”，不要当作托管项目的送达测试。
- ❌ 若收件地址未获默认服务授权：不要继续盲目重发；先换用允许的测试地址，或评估符合项目需求的发送配置。
自有 SMTP 可让项目向更广泛的收件地址发送，并让新建免费项目继续自定义模板；但这会增加发送服务配置与凭据管理工作。Supabase 文档说明，配置后新设置的服务仍有发送频率限制，具体限制可变；自定义 SMTP 不等于投递保证，也不自动证明品牌邮件已达到设计预期。
如果仅需临时接收一封注册确认邮件，测试收件地址可以作为方案之一；前提仍是当前 Supabase 发送配置允许向该地址投递。对于短期测试，OrbSend 提供无需账户的临时收件箱；地址有明确的收信期限，建议先查看临时邮箱的寿命规划，并在测试记录中注明收件地址与环境。它不适合需要长期找回、持续收信或必须回信的重要账户；这些场景应使用受控的长期邮箱。
给下一次验证留足时间
创建一个默认 3 小时、可按需延长的临时邮箱。