Emails with Resend
Configure verification and app emails for the stack you picked.
The app needs to send verification emails before users can finish signing up. It may also send password resets, magic links and workspace invitations.
The demos use Resend with a verified sending domain. For your product, configure your own domain and sender, then add the credentials in the right place for your kit.
Supabase kits
Configure Resend SMTP in the Supabase project's Auth settings. Set the sender, SMTP host, port and credentials, then check the site URL and allowed redirect URLs.
The web app's optional email API configuration is separate from Supabase Auth delivery. Adding a Resend key only to the web app won't configure Supabase's verification emails.
Convex kits
Configure the selected Convex deployment's email provider variables. The auth flow uses AUTH_RESEND_KEY and AUTH_EMAIL_FROM. App emails can use the separate Resend variables defined in that kit's env example.
A frontend env file alone doesn't configure a cloud Convex backend. Verify which deployment you are changing before testing a sign up.
Neon kits
Better Auth sends through the application's email setup. Use the example env file to configure the sender and Resend credentials.
The TanStack Neon kit uses an outbox for delivery. Its local worker runs separately; the Vercel deployment dispatches bounded batches and retries pending work on its configured cron.
D1 kits
Configure email secrets on the relevant Workers, including the background email Worker where used. The kits use Cloudflare jobs/outbox handling for email delivery.
Follow the kit's local email instructions when testing. You don't need to send local test emails to real users.
Check the complete flow
Create a test account, open the delivered verification email, and sign in again after verification. Then test a password reset and an invitation if you use those flows.
If the link opens the wrong website, check the configured application origin and the auth provider's callback allowlist first.