Documentación

Configure Resend

GuideEmail deliverySender identity setup

Fast Unicorn uses Resend for transactional email flows such as password recovery and purchase-related communication.

This guide explains which part of the project controls sender identity, what environment configuration is required, and how to verify that email flows work correctly before production.

Before configuring Resend

Finish the environment setup from Environment and make sure your branding values are updated if you want emails to reflect your real product identity.

What this guide covers

API configuration

How Resend is enabled through environment values and project config.

Sender identity

How the sender email is defined and why the verified domain matters in production.

Transactional flows

Which app features depend on email delivery and how to verify them before launch.

Main files and folders

  • src/config/site.ts: Sender identity and brand-facing email defaults.
  • src/env.js: Environment validation for required email configuration.
  • src/server/api/routers/emails.ts: "use server" module with server actions for sending emails (not a tRPC router).
  • src/server/api/routers/customAuth.ts: Auth-related email triggers such as password recovery.
  • src/components/emails/: Email templates — welcome.tsx, code.tsx, TokenEmailValidation.tsx, EmailPassChangeTemplate.tsx, PurchaseConfirmationTemplate.tsx.
Environment requirements

Required environment variable

  • RESEND_API_KEY: Server-side API key used to send transactional emails through Resend.

Sender identity

The sender address is configured in src/config/site.ts as resendEmail.

Before using it in production:

  • verify your domain in Resend
  • create a sender address on that verified domain
  • replace the default development sender

Brand consistency

Your sender identity should match the product name, support address, and overall branding used in src/config/site.ts and your localized copy.

What depends on Resend

Resend is used by flows that send emails to users, including password recovery and other transactional notifications.

If the sender is not configured correctly, these flows may fail even if the rest of the app is working.

Use this order when enabling email delivery.

1

Verify your sending domain

Set up your domain inside Resend so production emails can be sent from an address you actually control.

2

Add the API key to the environment

Place RESEND_API_KEY in your environment file so the server can authenticate with Resend.

3

Update the sender address

Replace the default sender in site config with a real address on your verified domain.

4

Test a real transactional flow

Trigger password recovery or another email-based flow and confirm delivery, branding, and sender identity.

  1. Verify your domain in Resend
  2. Add RESEND_API_KEY to .env
  3. Update siteConfig.resendEmail
  4. Trigger a test recovery email from the forgot-password flow
  5. Confirm the email is delivered with the correct branding and sender identity
Production check

Before going live

  • Verify the domain status inside Resend.
  • Make sure the sender address uses that verified domain.
  • Confirm the sender name matches your product branding.
  • Test recovery or billing email flows in staging.
  • Check spam placement and final rendering in a real inbox.

Do not treat local success as production success

A flow can appear correct in development and still fail in production if the domain is not verified or the sender identity is inconsistent with your Resend configuration.