As our user base has grown, we are taking steps to make sure we are able to continue to provide a safe, secure, robust free plan experience. To ensure that email-based auth continues to work for all users on Supabase, we're making changes if you're using the default email provider. This allows us to continue to offer our default provider in a more sustainable and resilient manner.
For maximum flexibility and control over your auth emails, we suggest one of the following:
If you still want to use the default email provider, these are the changes being planned:
-
Email template customization will be allowed and customized email templates will not be reverted to default.
-
26th September: If you do not have a custom SMTP server set up, emails can only be sent to email addresses in your project's organization. So for example, if your organization has the following members: person-a@example.com, person-b@example.com and person-c@example.com , this means that email messages from Auth will only be sent to these addresses.
These measures are taken to prevent abuse to our shared SMTP service. In the future, we may consider increasing the email rate limits once we see a drop in abuse.
Supabase uses a third-party email sending provider that has mandated we reduce email abuse significantly or they will be forced to block all email sending. A tragedy of the commons.
Yes, but we would run into the same issues. All email sending services are required to monitor abuse and force their customers to follow the same rules.
Not really. You can't just send email on the web today without investing a lot of money and time (unblocking port 25, keeping IP addresses out of spam lists, etc.). This is not our core competency and do not have plans to start doing this today.
Fortunately this is very easy. You can use any email sending service for this, really popular ones include:
All you need to do is create an account, verify your sending domain and finally input the SMTP username and password in the Auth settings page.
Currently this behavior is not supported and we'll be rolling out a fix for it during the first week of October.
Confirming email addresses is where most of the email message activity for a project originates. Turning it off can be a viable option for some projects that are still in the early testing, development or experimental phase.
Be aware that even if you turn off email confirmations the forgot password or reset password flows in your app continue to function. They also send messages, and starting 26th September those messages will be delivered only to the members of the Supabase organization that owns the project. All other end-users will get a message similar to "Email address not authorized." Effectively, the forgot password / reset password flow will be broken for your project.
What if I want just username + password authentication and using <username>@<fakedomain> instead?#
Please don't do this. Part of the reason why we were forced to lock down these changes is bounced emails, probably from use cases like this.
Official username + password support is going to be made available in the coming year, and until then:
- Use a real domain, that you control
- Send emails to that domain, so set up a receiving server
But the best thing to do is:
- Set up a Send Email Auth Hook that does nothing. You don't even need to use a server or an Edge Function. Just define a Postgres function that just does nothing.
All projects using generate link via the admin API without custom SMTP have been patched to allow the behavior. We still strongly urge those customers to set up custom SMTP regardless.
Just because you're mostly using the admin API to generate links to send in custom email messages, doesn't mean that the Auth server is not configured to use Supabase's shared SMTP service. Your Auth API can be called from your frontend at any time, especially in edge cases such as to handle forgot password or other similar flows, which you may not be handling via the admin API.
Therefore we urge all customers that do use the admin API to set up a custom SMTP sending service regardless.
If you are not interested in setting this up, you can instruct the Auth server to ignore all emails (pretend it's sending them) by configuring a Send Email Auth Hook as a Postgres function that does nothing.
You can disable the warning banner by setting up a custom SMTP provider , or, if your project doesn't use email at all, by disabling the email provider.
Email template customization will be allowed and customized email templates will not be reverted to default.
Team has decided that restricting email template customization is not viable and a big breaking change. We may need to do go back to this in the future if abuse continues and our other measures like allowing projects to only send messages to authorized email addresses do not improve the situation. We continue to urge all customers regardless of plan that use the default SMTP service for live applications to move to a custom SMTP provider as soon as able.
-
20th September: Email template customization will no longer be possible without setting up a custom SMTP provider. Email templates already customized can still be customized until 24th September.
-
24th September: Projects without a custom SMTP provider will have their custom email templates returned back to the default ones from Supabase. This means that any auth emails sent out from your project will use the default email template.
