Changes to Email Template Customisation on Free Tier

[doublethink]

For the past six months we've been tracking a steady increase in coordinated abuse of Supabase's free-tier email infrastructure. Bad actors were standing up free Supabase projects, rewriting the auth email templates with phishing content, and then triggering signup or password-reset flows against arbitrary email addresses to deliver those phishing emails from our SMTP infrastructure to people who had no relationship with Supabase.

We rolled out increasingly aggressive rate limits on outbound auth emails. We deployed keyword blocklists to catch the most common phishing payloads. We built automated detection that flagged suspicious template content and disabled offending projects. Each one was met with a workaround within days if not hours.

To our knowledge Supabase was the only auth provider that offers both a hosted email service and fully customizable email templates on free tier. Obviously this combination is what made us a uniquely attractive target.

All of this is to say we tried hard to ship changes that wouldn't affect legitimate users. But the abusive accounts — while likely just a handful of individuals — given the scale of their abuse, were responsible for the bulk of spam leaving our infrastructure, and we've reached the point where the volume risks having our email server blacklisted entirely.

What's changing

Starting today Wednesday, 3 June 2026, new free-tier projects using Supabase's default email provider will no longer be able to modify their auth email templates. The default templates — confirmation, password reset, magic link, etc. — will be used as-is.

Who's affected

Existing free-tier projects keep their current email templates exactly as they are. Nothing changes for projects created before 3 June 2026.
Paid plans (Pro and above) are not affected. Template customization continues to work as it does today.
Free-tier projects that configure their own SMTP provider can continue to customize templates freely. The restriction only applies when sending through Supabase's default SMTP.

If you're starting a new free-tier project and need branded auth emails, you can configure your own SMTP provider (Resend, Postmark, SendGrid, Amazon SES, etc.) in your project's auth settings — once enabled, you can customize your templates as before.

[GaryAustin1]

Is it intentional to not put {{.Token}} in the new fixed templates?
This rules out simple testing using verifyOtp versus redirects.

[doublethink]

Hi Gary
Yes I understand there was a lot of back and forth with Design about including this.
Namely they wanted the templates to be a base of developers to add styling to instead of so clearly test related by having both methods.
I will raise this feedback with them

[GaryAustin1]

Here is a user who uses supabase to teach students mobile apps and OTP is needed. Now all students have to setup SMTP provider.
https://github.com/orgs/supabase/discussions/47114