SMTP settings for Supabase Auth

The settings, in full

Supabase asks for six values. Five of them are the same for everyone; only the sender address is yours.

Use port 587. Port 465 works too, but Supabase expects STARTTLS on 587 and that is the combination least likely to surprise you.

Where the fields live

In the Supabase dashboard, open your project and go to Authentication → Emails → SMTP Settings, then turn on Enable Custom SMTP. On older projects the same panel sits under Project Settings → Authentication; Supabase has moved it more than once, so search the settings for “SMTP” if neither path matches what you see.

Fill in the six values, save, and Supabase will start routing every auth email — confirmation, magic link, password reset, email change — through your credential instead of its own sender.

Why the built-in mailer is not enough

Supabase ships a shared email service so that a brand-new project can send something on day one. It is deliberately throttled to a couple of messages an hour, it only delivers to members of your Supabase organisation, and Supabase itself says it is not for production use.

That is why the first real signup on a new project appears to do nothing: the user is created, the confirmation email is rate-limited away, and nothing in the UI tells you. Custom SMTP is not an optimisation here — it is the step that makes signup work at all.

Raise the auth rate limit as well

Enabling SMTP does not by itself lift Supabase's own cap on auth emails. Go to Authentication → Rate Limits and raise Rate limit for sending emails to something your traffic justifies.

Leaving it low is the most common reason people configure SMTP correctly and still see missing confirmation emails at the second or third signup of the hour. Our own monthly quota is separate and shown in your dashboard — the two limits are enforced in different places and you need both to be generous enough.

The sender address rule

The sender email you give Supabase becomes the From: header on every auth email, and we will only send for a domain you have verified in Domains. If the two disagree, the message is rejected at SMTP time with a clear error rather than delivered unsigned.

So: add your domain, paste the DKIM and SPF records we generate into your DNS, wait for verification, then set the Supabase sender to an address on that same domain. A noreply@ or auth@ mailbox does not have to exist — it only has to be on the verified domain.

Local development and self-hosted

Running Supabase locally through the CLI, the same settings go in supabase/config.toml rather than the dashboard:

[auth.email.smtp]
enabled = true
host = "smtp.email4vibecoder.com"
port = 587
user = "env(SMTP_USER)"
pass = "env(SMTP_PASS)"
admin_email = "[email protected]"
sender_name = "Your App"

Most people leave local development on Inbucket (the mail catcher the CLI starts for you) and only point at a real server from a deployed environment. Both are fine — just create a separate credential for each, so revoking one never touches the other.

Check that it worked

Trigger a password reset for your own address from your app, then open Activity. Within a second or two you should see the message, its recipient, and what the receiving server replied — the actual SMTP conversation, not a “sent” flag.

If nothing appears in Activity at all, the message never reached us: the failure is on the Supabase side, and its own auth logs (Logs → Auth) will name it.

When it does not work