Guides

Supabase

Send Supabase Auth emails — confirmations, magic links, password resets — through Email Bump.

Why change it

Supabase Auth sends the emails your sign-up flow depends on — confirmations, magic links, invitations, password resets, email-change confirmations. Out of the box they go through Supabase's own shared service, which is meant for development: it is rate limited, the messages come from an address that isn't yours, and you cannot see what happened to them.

Pointing Supabase at Email Bump changes three things. The mail comes from your verified domain, so it authenticates as you and lands better. The rate ceiling becomes your plan's rather than a development quota. And every message appears in your transactional log with its opens, clicks and bounces, so a user saying “I never got the email” is a question you can answer.

Before you start

You need two things, both a few minutes of work:

Prerequisites

A verified sending domainone-time setupoptional

Add it under Sending domains. Supabase's sender address has to be on a domain you have verified.

An API keyone-time setupoptional

Create one under API keys. It is shown once, so paste it straight into Supabase.

Configure SMTP

In your Supabase project, open Authentication → Emails → SMTP Settings and turn on Enable Custom SMTP. Then:

cURL

Sender email:  noreply@yourdomain.com   # on your verified domain
Sender name:   Your App
Host:          smtp.emailbump.com
Port:          587
Username:      emailbump
Password:      ebk_your_key

The sender address is the part people get wrong

It must be on a domain you have verified in Email Bump. Left at Supabase's default, or set to a domain you haven't verified, every send is refused — the reply says so, and it shows up in Supabase's auth logs rather than anywhere obvious.

If your host blocks port 587, use 2587. Both negotiate STARTTLS; 465 is available for implicit TLS.

Rate limits

Supabase applies its own rate limit to auth emails, separate from anything here — it exists to stop a loop in your app from emailing a user hundreds of times. Once custom SMTP is on you can raise it under Authentication → Rate Limits. If confirmations stop arriving during a burst of signups and Email Bump shows nothing, that limit is the first place to look, because the mail never reached us.

Templates

Supabase's built-in templates keep working unchanged — we accept ordinary email, so whatever Supabase composes is what goes out. Edit them where you always did, under Authentication → Emails → Templates.

If you would rather design them in Email Bump, replace a Supabase template with JSON naming one of yours and we render it instead:

cURL

{
  "template_id": "d3d04286-d773-4d06-acfd-7ee983108f0b",
  "variables": {
    "confirmation_url": "{{ .ConfirmationURL }}",
    "email": "{{ .Email }}"
  }
}

Supabase's template variables — {{ .ConfirmationURL }}, {{ .Token }}, {{ .Email }} — go on working inside the JSON, because Supabase substitutes them before the message is sent. See SMTP for the full shape.

Check it worked

Sign up a test user, or use Send magic link from the Supabase dashboard. The message should appear in your transactional log within a second or two, with the subject Supabase composed.

If it doesn't appear at all, Supabase rejected it before sending — check its auth logs for the SMTP reply, which will name the reason. The usual one is a sender address on an unverified domain. If it appears but the user says it never arrived, the delivery events on the message will tell you whether it bounced, and why.