Integrations

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.

Custom SMTP lets you send from your verified domain and inspect accepted messages in Email Bump's transactional log. Authentication does not guarantee inbox placement. Both Supabase Auth's rate limits and Email Bump's sending limits still apply. See Supabase's custom SMTP guide.

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:  [email protected]   # 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

Use a test account and a real mailbox you control to request a confirmation or magic link from your application. Accepted messages appear in the transactional log; allow for processing time. Ordinary mail keeps Supabase's subject; JSON template sends use the saved Email Bump template's subject.

If nothing appears there, check SMTP logs. A message we refused — almost always a sender address on a domain you haven't verified — never becomes a transactional message, so the refusal and its reason are recorded there instead. Supabase's own auth logs will show the same reply from its side.

If it appears but the user says it never arrived, the delivery events on the message tell you whether it bounced, and why.

Delivery is not proof that a person opened the message or successfully signed in. Test the confirmation link too: link rewriting and security scanners can interfere with single-use auth URLs. See Supabase's production checklist.