Confirmation emails (type: signup) never dispatched to SMTP — other auth email types work fine on same project/SMTP config

[zoelivvy]

New user signups complete successfully and correctly withhold a session (confirming "Confirm email" is enabled and taking effect), but the confirmation email itself is never sent. This is isolated specifically to the signup confirmation flow — password reset emails work reliably on the same project with the same custom SMTP configuration.

Environment:

• Supabase Cloud, production project
• Custom SMTP provider: Resend
• Confirm email: enabled (verified in Authentication → Sign In/Providers)

Steps to reproduce:

1. Sign up a new user via supabase.auth.signUp({ email, password })
2. Check Supabase Authentication Logs — /signup request shows "request completed", no errors
3. Check Resend dashboard (Emails tab) — zero send attempts logged for this signup, ever
4. Meanwhile, trigger a password reset for an existing user on the same project — email sends and is delivered successfully within seconds, logged normally in Resend

What we've ruled out:

• Not a template issue — replaced the "Confirm signup" template with Supabase's own bare-minimum default (Confirm) and it still did not send
• Not an SMTP connectivity issue — same Resend SMTP credentials successfully send password reset emails on the same project
• Not a dashboard misconfiguration — "Confirm email" toggle confirmed ON, and its effect is visibly working (no session returned on signup)
• Not a rate limit — Resend's dashboard shows zero attempts, not failed/bounced/suppressed attempts, meaning the request appears to never leave Supabase's backend for this specific email type

Conclusion:
The /signup endpoint logs success and correctly withholds a session, but never appears to call the configured SMTP provider to dispatch the confirmation email specifically. This matches other reports of the same failure pattern (e.g. gotrue#492, gotrue#1283) where certain auth email types silently fail to dispatch while others on the same project work normally.

Question: Is this a known issue with signup-type email dispatch specifically? Is there a way to see GoTrue's internal dispatch logs to confirm where in the pipeline the email is being dropped?

[ryux1]

There are three different paths that can all look like a successful /signup, so the audit event is the quickest way to separate them.

1. In Authentication → Audit Logs, check the event for the test address. If it is user_repeated_signup, GoTrue intentionally returns 200 with a sanitized user and sends no message, to avoid leaking whether an account already exists. That path is visible in the current signup handler here. Delete the test user first or use a genuinely unused address.

2. If the event is user_confirmation_requested, check Authentication → Hooks for an enabled Send Email Hook. When that hook is enabled, it replaces the SMTP path entirely (source), so Resend's SMTP dashboard will correctly show no attempt. The hook must dispatch email_data.email_action_type === "signup" itself.

3. If there is no hook, open Logs → Auth (not only the /signup request row), reproduce once with a new address, and filter around that timestamp for apitask, mailer.signup, smtp, or error. Hosted Auth can run delivery as a request-scoped background task; a delivery failure is logged with action=apitask and task_type=mailer.signup (source). That explains how the endpoint can have a completed request row while Resend has no accepted message.

As a controlled follow-up, call supabase.auth.resend({ type: 'signup', email }) for the same unconfirmed user and inspect the returned error; this is the supported resend flow. Be aware that it also returns an empty success for a missing or already-confirmed user (source).

If the audit event is user_confirmation_requested, no Send Email Hook is enabled, and the Auth logs contain neither a mailer.signup failure nor an SMTP handoff while Resend still records zero attempts, that narrows it to the hosted Auth worker/configuration. At that point a support ticket with the project ref, UTC timestamp, request ID, and the relevant Auth log JSON should be actionable. Do not post the SMTP password or API key publicly.

Relevant docs: Auth audit-log actions, Auth logs in Logs Explorer, and signup confirmation resend.