Envello as Supabase Auth's custom SMTP provider

Supabase's default email sender exists to get you through local development, not production. It's capped at a handful of emails per hour on the free tier, sends from a shared Supabase address that spam filters don't trust, and gives you no logs when a confirmation email doesn't land. The fix is Supabase's built-in custom SMTP setting: point it at Envello and every Auth email, confirmation, magic link, password reset, email change, goes out through your own domain instead.

Why this is a separate integration from the API

Sending your own transactional email from a Supabase Edge Function (covered in a separate guide) is for emails your application logic triggers: order confirmations, receipts, custom notifications. Auth emails are different, they're triggered internally by Supabase's GoTrue auth server whenever someone signs up, requests a magic link, or resets a password, and your application code never sees the send happen. The only way to control where those go is Supabase's SMTP settings, not the Envello API directly.

Get SMTP credentials from Envello

Envello exposes SMTP credentials alongside the API for exactly this kind of integration, where the calling system speaks SMTP and can't be swapped for an HTTP client.

• In the Envello dashboard, go to Domains and confirm the sending domain you'll use for Auth email is verified (SPF, DKIM, DMARC all green)
• Under SMTP Credentials, generate a new credential set scoped to that domain
• Note the host (smtp.envello.dev), port (587 for STARTTLS), username, and password, you'll paste these into Supabase next

Configure Supabase

In the Supabase dashboard, this lives under Project Settings.

• Go to Project Settings → Authentication → SMTP Settings
• Toggle Enable Custom SMTP on
• Host: smtp.envello.dev
• Port: 587
• Username and Password: the SMTP credential pair from Envello
• Sender email: an address on your verified domain, e.g. [email protected]
• Sender name: your product name, e.g. Acme Inc
• Save, then use the Send test email button Supabase provides before touching anything else

Why the sending domain has to be verified first

If the domain in Sender email isn't SPF/DKIM verified on the Envello side, the emails will authenticate as neither Supabase nor you, and land in spam or get rejected outright. This is the step people skip, and it's why the test email in Supabase's SMTP panel matters, it's a fast signal but not a substitute for checking DKIM alignment on a real received message's headers.

Customize the email templates

Supabase's default Auth email templates are plain and unbranded. Once custom SMTP is live, it's worth replacing them so the emails look like they came from your product, not from Supabase's demo theme.

• Templates live under Authentication → Email Templates: Confirm signup, Invite user, Magic Link, Change Email Address, Reset Password
• Supabase's templates support a small set of variables ({{ .ConfirmationURL }}, {{ .Token }}, {{ .SiteURL }}), keep these intact, they're how the link actually works
• Keep the HTML simple, transactional emails that try to replicate a full webpage layout render inconsistently across email clients
• Update the Site URL and Redirect URLs under Authentication → URL Configuration to match your production domain, otherwise confirmation links point back to localhost

Rate limits move from Supabase's to yours

Once custom SMTP is enabled, Supabase's own default-sender rate limit no longer applies, your Auth emails are now bound by Envello's sending limits instead. Supabase still applies its own request-level rate limiting to the Auth endpoints themselves (to prevent signup abuse), that's separate and stays in place regardless of which SMTP provider you use.

Debugging a missing Auth email

When a user reports they never got a confirmation or reset email, check in this order.

• Envello's dashboard logs for that recipient, if the send isn't there at all, Supabase never called out, check the SMTP credentials are saved correctly and the toggle is actually on
• If it shows as sent but not delivered, check the message status, a bounce usually means the recipient address doesn't exist, a block usually means a domain reputation or content issue
• Confirm the sender domain's SPF and DKIM are still passing, a DNS change on the domain (a new record, a registrar migration) can silently break authentication without any error in Supabase
• Check Supabase's Auth logs (Logs → Auth) for the underlying GoTrue error, a misconfigured SMTP credential often fails at the Supabase layer before it ever reaches Envello

One credential per environment

Generate separate SMTP credentials for staging and production Supabase projects, on separate subdomains if practical (auth.yourdomain.com vs. staging-auth.yourdomain.com). This keeps a staging environment's test signups from touching your production domain's sending reputation, and makes it trivial to revoke one environment's access without affecting the other.