使用自定义SMTP发送邮件
如果您在使用 Supabase Auth 时采用以下配置：
- 邮箱和密码账户
- 使用通过邮件发送的一次性密码或链接的无密码账户（OTP、魔法链接、邀请）
- 来自用户页面或 Auth 管理 API 的基于邮箱的用户邀请
- 需要邮箱确认的社交登录
您需要设置自定义 SMTP 服务器来处理发送给用户的消息。
为了让您快速开始探索并为应用程序设置邮件消息模板，Supabase 为所有项目提供了一个简易 SMTP 服务器。该服务器存在若干重要限制，不适用于生产环境。
仅允许向预先授权的地址发送消息
除非您为项目配置了自定义 SMTP 服务器，否则 Supabase Auth 将拒绝向非项目团队成员的地址发送消息。您可以在组织设置的团队标签页中管理此设置。
例如，如果您的项目组织包含以下成员账户 person-a@example.com、person-b@example.com 和 person-c@example.com，那么 Supabase Auth 将仅向这些地址发送消息。其他所有地址都将发送失败，并显示错误信息 邮箱地址未授权。
存在可能随时变更的严格速率限制
为维护默认 SMTP 发送服务的健康度和声誉，您的项目可发送的消息数量受到限制，且可能不经通知就发生变化。当前该限制设置为每小时 2 条消息。
默认SMTP服务不提供消息送达或正常运行时间的SLA保证。
默认SMTP服务仅以"尽力而为"的方式提供，适用于以下非生产环境用例：
- 探索和开始使用Supabase Auth
- 与项目团队成员一起设置和测试电子邮件模板
- 构建玩具项目、演示或任何非关键任务型应用
我们强烈建议所有客户在所有其他用例中设置自定义SMTP服务器。
如何设置自定义SMTP服务器？
Supabase Auth支持任何兼容SMTP协议的邮件发送服务。首先您需要选择一个服务提供商，创建账户（如果尚未拥有）并获取该账户的SMTP服务器设置和凭证。这些信息包括：SMTP服务器主机地址、端口号、用户名和密码。您还需要设置默认的发件人地址，通常类似于no-reply@example.com。
以下是可与Supabase Auth配合使用的部分服务列表：
完成邮件发送服务的账户设置后，请前往认证设置页面启用并配置自定义SMTP。
保存这些设置后，您项目的Auth服务器将向所有地址发送邮件。为了保护新设置服务的信誉，系统默认设置了每小时30条消息的低速率限制。如需根据您的使用场景调整此限制，请访问速率限制配置页面。
应对滥用行为：如何维护SMTP服务器的发送信誉？
当您的应用程序公开并逐渐流行时，可能会遭遇几种滥用行为，这些行为会对您的发送域名信誉产生负面影响。
常见的滥用来源是机器人或攻击者注册用户到您的应用程序中。他们使用已知电子邮件地址列表，以预设密码将用户注册到您的项目中。这种行为在规模和强度上各不相同：有时机器人会缓慢地在数月内发送注册请求，有时则会一次性发送大量请求。
通常这种行为的目标是：
- 负面影响您的电子邮件发送信誉，之后可能会索要赎金承诺停止该行为
- 通过对您的服务发起短期甚至长期的拒绝服务攻击，阻止新账户创建、使用魔法链接或一次性密码登录，或严重影响应用程序中的重要安全流程（如重置密码或忘记密码）
- 迫使您降低项目的安全态势，例如禁用电子邮件确认。此时，他们可能会通过以特定或大量用户名义创建账户进行针对性攻击，然后利用社会工程技术诱骗受害者使用您的应用程序，使攻击者和受害者都能访问同一账户
缓解策略：
- 配置CAPTCHA保护您的项目，这是此场景下控制机器人最有效的方式。您可以使用提供隐形验证的CAPTCHA服务，大多数情况下真实用户无需解决验证难题
- 在应用程序中优先使用社交登录(OAuth)或SAML单点登录，而非基于电子邮件的认证流程
- 优先采用无密码认证（一次性密码），这会限制攻击者从此行为中获取的价值
- 不要在压力下禁用电子邮件确认功能
其他最佳实践
设置并维护 DKIM、DMARC 和 SPF 配置
与您的邮件发送服务商合作，为发送域名配置 DKIM、DMARC 和 SPF。这将显著提高邮件的送达率。
设置自定义域名
认证邮件通常包含指向您项目 Auth 服务器的链接。设置自定义域名 可以降低因其他 Supabase 项目的不良声誉导致您的邮件被标记为垃圾邮件的风险。
不要混用认证邮件与营销邮件
为认证和营销消息使用独立服务。如果其中一项服务的声誉受损，不会影响整个应用或运营。
具体包括：
- 为认证使用独立发送域名 ——
auth.example.com，为营销使用独立域名marketing.example.com - 使用不同的发件地址 ——
no-reply@auth.example.com与no-reply@marketing.example.com
配置备用 SMTP 服务
当主要使用的 SMTP 服务出现故障，或您的账户因垃圾邮件风险面临封禁威胁时，可以快速切换到备用服务。
保持品牌一致性和内容专注性
确保将认证消息与营销内容明确区分：
- 避免在认证消息中包含推广内容
- 不要在认证消息中介绍应用功能：自动化垃圾邮件过滤器可能会将其归类为营销内容，增加被标记为垃圾邮件的风险。特别是当项目涉及以下领域时更需注意：Web3、区块链、AI、NFT、赌博、色情内容
- 避免在认证消息中使用标语或其他简短营销素材
- 减少认证消息中的链接和行动号召按钮数量
- 减少认证消息模板的变更频率：相比多次小改动，更推荐一次性大改
- 避免在认证消息中进行A/B测试
- 使用与营销邮件不同的基础HTML模板
- 慎用邮件签名：如需使用，确保其样式和内容与营销消息有明显区别
- 使用简洁明了的邮件主题：减少或避免使用表情符号
- 减少认证消息中的图片数量
- 避免包含用户提供的数据：如姓名、用户名、邮箱地址或称呼语。如需包含，请确保已进行消毒处理
提前为大规模流量激增做好准备
如果您预计在特定时间会有大量用户涌入，请与您的邮件发送服务商协作，相应调整速率限制并同步预期。大多数邮件发送服务都不喜欢消息发送量的突然激增，这可能会影响您的发送信誉。
针对此类活动，建议实施额外的保护措施：
- 构建排队或候补名单系统，而非直接开放注册，这将帮助您控制从邮件发送服务发出的消息数量。
- 在活动期间禁用基于邮箱的注册，仅使用社交登录。或者，您可以通过在用户界面中隐藏或增加访问难度，降低活动期间基于邮箱的注册流程优先级。
使用发送邮件认证钩子实现更精细的控制
若需对发送过程进行更精细的控制，您可以使用发送邮件认证钩子替代SMTP服务器。这在以下高级场景中特别有用：
- 需要使用React或其他邮件模板引擎
- 使用的邮件发送服务不提供SMTP服务，或非SMTP API功能更强大
- 需要对邮件进行队列处理而非立即发送，以平滑发送高峰或实施额外过滤（避免重复消息）
- 需要使用多个邮件发送服务提高可靠性（当主服务不可用时自动切换至备用服务）
- 需要根据邮件地址或用户数据选择不同发送服务（例如：美国用户使用服务A，欧盟用户使用服务B，中国用户使用服务C）
- 需要为邮件添加额外头部信息用于追踪或其他目的
- 需要为邮件添加附件（通常不建议）
- 需要为邮件添加S/MIME签名
- 需要使用不对外开放的邮件服务器（如某些企业或政府邮件服务器）
延长用户会话持续时间
较短的用户会话持续时间可能会对邮件发送造成问题，因为它会强制活跃用户频繁登录，从而增加需要发送的消息数量。建议考虑延长用户会话的最大持续时间。如果您确实发现登录次数无故增加且没有明确原因，请检查您的前端应用程序是否存在错误。
如果您在前端使用SSR框架，并且发现用户登录次数无故增加，请检查您的设置。确保保持@supabase/ssr包为最新版本，并严格遵循我们发布的指南。确保您的SSR前端的中间件组件按预期工作，并与我们发布的指南相匹配。有时一个放错位置的return语句或条件判断可能会导致会话提前终止。