Supabase Auth sends the emails for sign-up, password reset, magic links, invites and email changes. In a hosted project, Supabase's built-in mailer only delivers to members of your Supabase organization and allows 2 emails per hour for the whole project. Real users never receive their reset or confirmation email, and retries fail on the hourly limit.

aSaaSin fixes this with the Send Email hook: Supabase Auth calls a Supabase Edge Function (send-email) that renders the email with React Email and sends it through Resend. Newsletter and waitlist emails sent from Next.js are unaffected and keep using services/email.

• Auth triggers the hook instead of its own mailer.
• Send Email hook posts a signed payload (Standard Webhooks) to the function.
• Edge Function verifies the signature, plans one or two emails, renders HTML and plain text, and sends them with Resend.
• /auth/confirm is the page every link points to. It verifies the one-time token only when the user presses Continue, then creates the session and redirects.

Everything the function imports lives under supabase/functions/, because the Supabase CLI only bundles that folder. The reusable parts (layout, Resend transport, sender parsing) are in _shared/email/, the Supabase-specific parts (payload, plan, redirects, webhook, copy) in _shared/auth-email/.

Secure Email Change sends two emails: one to the current address and one to the new address. Supabase crosses its fields on purpose (the current address gets token and token_hash_new, the new address gets token_new and token_hash). The function handles this and only answers 200 once Resend accepted both. With Secure Email Change off, only the new address gets an email.

• Brand - name, logo and colors live in supabase/functions/_shared/email/brandConfig.ts. The Edge Function cannot import config/ or constants/colors.ts, so these values are copies. A test (brand.test.ts) fails when they drift from SITE.name, HexColors or the logo file in public/. Change the brand in the app first, then update brandConfig.ts.
• Copy - one file per locale, typed as AuthEmailCopy: copy.en.ts (default) and copy.de.ts as a second example. The brand name is interpolated.
• Layout - inline-styled, table-based React elements rendered by @react-email/render (HTML and plain text).

Add one file copy.<locale>.ts of type AuthEmailCopy next to copy.en.ts, then import it in supabase/functions/send-email/index.ts in place of copyEn. The function sends one locale per deployment; it does not pick a language per user.

Follow the steps in this order. Rehearse on a separate Supabase project first if you can.

The app contains the /auth/confirm page that every email link points to. Deploy it to production before you enable the hook (see Deployment).

1. In the Supabase dashboard open Authentication → Hooks → Send Email and choose HTTPS. Keep it switched off while you set it up.
2. Set the URL to https://<project-ref>.supabase.co/functions/v1/send-email.
3. Generate the secret and copy the value (v1,whsec_…).
4. Set the secrets with the Supabase CLI (quote the values):

Then run the quick deploy check below and switch the hook on.

AUTH_EMAIL_ALLOWED_ORIGINS is required and comma separated. The first entry is the default origin for links and the logo, so put the canonical host first.

While the hook is on but a secret is missing, the function answers 500 Email hook is not configured, logs the missing variable names, and Auth reports an error to the user (resets and sign-ups fail visibly).

Open Authentication → Rate Limits and set the emails-per-hour value. With the hook the 2/hour cap no longer applies. Start low and raise it only after checking your Resend plan quota.

• In Authentication → URL Configuration keep your production origins' /auth/callback** and http://localhost:3000/auth/callback** in the redirect allow list. Links sent before the switch keep working through the code exchange in /auth/callback.
• In Resend, make sure click and open tracking is off for the sending domain. A rewritten link breaks the one-time token.

• Resend is faked in every test; nothing is sent.
• The preview builds the logo URL from NEXT_PUBLIC_APP_URL, so the logo only loads while the app runs.
• Local Supabase keeps using Mailpit (http://127.0.0.1:54324) by default, because the [auth.hook.send_email] block in supabase/config.toml stays commented out. Enabling it would send real mail through Resend instead.
• Optional local hook test: run the function with the CLI (needs Docker), uncomment the hook block in supabase/config.toml, and send to Resend's test recipient delivered@resend.dev.

1. Deploy the app first, then the function, then create the hook.
2. Sign up with an address outside your Supabase team. The mail arrives from your sender, the button leads to a Continue page, then to the dashboard with a success toast.
3. Reset a password for an external account. The mail arrives, Continue opens /reset-password, you set a password and land on the dashboard.
4. Reuse an old reset link. You should see "The link is invalid or has expired" on the forgot-password page, not a silent redirect.
5. Change an email address (if you use it) and confirm. With Secure Email Change on, both emails arrive.
6. Check Resend → Emails (delivered, no click tracking) and Supabase → Edge Functions → send-email → Logs (no signature_invalid or send_failed).

Use delivered@resend.dev for tests that must not reach a person.

• Signature first. The function verifies webhook-id, webhook-timestamp and webhook-signature over the raw body (Standard Webhooks, 5 minute tolerance) before it parses or renders anything. Bodies over 64 KB are refused.
• Redirects are restricted. The link origin is the one in redirect_to only if it is listed in AUTH_EMAIL_ALLOWED_ORIGINS, otherwise the first entry. Only /auth/callback survives as the post-login path. The callback and /auth/confirm accept relative paths only.
• Verify on click. Links open /auth/confirm, which verifies the token only after Continue, so mail scanners and link previews cannot use it up. It also works from a different browser than the request.
• Retries are safe. Resend idempotency keys derive from webhook-id, so a retried hook never sends a second copy.
• No secrets in logs. Logs contain action types, status codes, Resend error names and the names of missing variables only: no tokens, links, addresses, payloads or secrets.

Supabase can also send notifications such as "password changed" or "email changed". With the hook enabled they would arrive at this function, but there are no templates for them, so it answers 422 and logs action_unsupported. Keep these notifications disabled in the Authentication settings until you add templates (a new kind in plan.ts and a string per locale).

• Rollout order: app, function, secrets, hook.
• Rollback: disable the hook, then the app if needed. Disabling the hook restores the sender Supabase would use without it: its built-in mailer (team members only, 2 emails per hour) unless you configured custom SMTP.
• Keep /auth/confirm deployed until the links already sent have expired.

• Only the six action types in the table above are handled. Security notifications are not supported (answered with 422).
• reauthentication sends a code only, with no link.
• One locale per deployment. There is no per-user language.
• Delivery is Resend only. Another provider means replacing _shared/email/transport.ts.
• The repository tests fake Resend. There is no automated end-to-end test against a live Supabase project.
• Local hook testing with supabase functions serve has not been exercised.
• The manual setup (hook, secrets, rate limit) is per Supabase project and is not scripted.