Supabase Auth sends email for you from the moment you create a project. Signup confirmations, magic links, password resets, all of it works on day one with nothing configured.
Then you get closer to shipping and start noticing what those emails actually look like. They come from a sending domain that is not yours, they use Supabase’s default HTML, and your logo is nowhere in them. Changing that is where people discover there are two completely different mechanisms for taking auth email over, and that they are much further apart than they first appear.
What Supabase Auth Actually Sends
Before changing anything, it is worth knowing how many templates you are dealing with:
- Signup confirmation
- Magic link
- Password recovery
- Invite
- Email change, which is two emails when secure email change is on, one to the current address and one to the new one
- Reauthentication
Plus a set of security notices Supabase sends after the fact. Each of the above is a separate template in Authentication → Email Templates, with its own HTML and its own Go template variables like {{ .ConfirmationURL }}.
That count matters, because every approach below multiplies by it. A logo change is not one edit, it is seven.
Option 1: Custom SMTP
This is the standard answer and it is a perfectly good one. You bring your own email provider, put its SMTP credentials into Supabase, and Supabase keeps sending its own templates through your account.
Setup lives under Project Settings → Authentication → SMTP Settings. You will need a provider (Resend, Postmark, SendGrid, Amazon SES and Mailgun all work), a verified sending domain with SPF and DKIM records, and the host, port, username and password from that provider.
What it gives you: your own sending domain, your own sender reputation, and delivery you can see and debug in your provider’s dashboard.
What it does not change:
- Template editing. You are still editing raw HTML in the Supabase dashboard, one type at a time.
- Branding drift. Change your logo and you are updating seven templates by hand.
- Link versus code. Supabase’s templates render the confirmation URL. If you want your users to type a six digit code instead, that is an HTML edit per type.
If you are comfortable in raw HTML, stop here. Custom SMTP is genuinely the right call for a lot of apps, and Resend or Postmark will serve you better as a general email platform than anything else will.
Option 2: The Send Email Hook
Supabase also supports a Send Email Hook, which is a different mechanism from custom SMTP and worth understanding even if you do not use it.
With custom SMTP, Supabase still composes the email and just uses your credentials to send it. With a Send Email Hook, Supabase composes nothing. It calls an HTTPS endpoint you nominate, hands over the user, the email type and the verification token, and whatever your endpoint builds is what the user receives.
That means the hook owner controls the template, the branding, the sending domain, and whether the email presents a clickable link or a typed one-time code. It also means the hook owner is responsible for actually sending it, so if your endpoint is down, your users cannot sign in.
You can implement this yourself with an Edge Function. You are then writing and maintaining seven email templates, handling the token to URL reconstruction correctly for each action type, and owning the uptime of a service that sits directly in your login path. It is very doable and it is real work.
Option 3: Hand the Whole Thing Over
Entrig implements that hook for you. It registers itself as your project’s Send Email Hook through Supabase’s Management API, so from that point on every auth email your project would have sent goes out through Entrig and your own verified domain instead.
That covers signup confirmation, magic links, password recovery, invites, both sides of an email change, reauthentication codes, and Supabase’s post-hoc security notices.
What changes in practice:
- Branding is applied at send time, not baked into a saved template. Change your logo or accent colour once and every future email picks it up, including ones you have never touched.
- Link or code, per email type. Choose whether each type sends a clickable link, a one-time code, or both, without editing HTML. Reauthentication is always a code, because Supabase gives it no verification URL to work with.
- Expiry copy comes from your project’s real setting. Every email that hands out something time-limited states how long it lasts, read from your project’s own Email OTP Expiration value rather than a hardcoded guess.
What does not change:
- You still need a verified sending domain with the DNS records to match. There is no way around proving you own the domain you send from.
- Entrig needs the Supabase Auth permission to register the hook. If you connected before this existed, you will be asked to reconnect once.
Setup is documented in the Auth Email guide, and it is a sender picker and a toggle.
Which One Should You Pick
| Situation | Pick |
|---|---|
| Building locally, nothing user-facing yet | The built-in sender is fine |
| Shipping, happy editing HTML, want a dedicated email platform | Custom SMTP with Resend or Postmark |
| Shipping, want branded auth emails and no template maintenance | Send Email Hook, self-built or via Entrig |
| Already sending push from your Supabase database | Entrig, since auth email and push share one dashboard and one sending domain |
Being honest about the middle row: if what you need is a great general-purpose email platform, Resend and Postmark are better at that than we are, and they should be. What we are better at is the specific job of being welded to Supabase Auth, where the templates, the branding, the expiry copy and the link-versus-code decision are handled as configuration rather than as code you maintain.
A Note on Deliverability
Whichever option you pick, an auth email that gets filtered to spam is the worst outcome in this whole area, because the user cannot log in and has nothing to retry.
Verify SPF, DKIM and DMARC on your sending domain, warm up a new domain gradually rather than sending your first thousand emails on day one, and send from a subdomain you control rather than your apex domain.
That advice holds regardless of which of the three options you choose.