General Email Configuration

Email Sending Mechanism

The core logic for sending emails resides in src/server/email/send-email.ts. This function acts as a router:

1. It checks the value of the NEXT_PUBLIC_EMAIL_PROVIDER environment variable.
2. Based on this value (smtp, resend, plunk, or nodemailer-app), it calls the corresponding provider-specific sending function (e.g., send-email-smtp.ts, send-email-resend.ts).
3. Each provider-specific function handles the details of interacting with that service's API or transport (often defined in the src/server/email/transports/ directory).

This approach allows easily switching between email providers by changing the environment variable.

Supported Providers

Detailed setup instructions for each provider are available:

• SMTP: For using a standard SMTP server (Gmail, SendGrid Relay, AWS SES SMTP, custom server, etc.).
• Resend: For using the Resend transactional email service.
• Plunk: For using the Plunk email service (managed or self-hosted).
• Nodemailer App (Local): For local development and testing, catching emails locally instead of sending them.

Common Use Cases

The sendEmail function is used throughout the application for critical communications, including:

• Sending email verification links (if NEXT_PUBLIC_AUTH_ENABLE_EMAIL_VERIFICATION=true).
• Sending password reset links.
• Sending email change confirmations (if enabled).

General Considerations

Deliverability

• Dedicated Providers: Using a dedicated email service provider (like Resend, Plunk, SendGrid, AWS SES API) often simplifies deliverability management as they handle much of the underlying infrastructure (IP reputation, feedback loops, etc.).
• SMTP: Email deliverability with generic SMTP can be more complex. You are responsible for ensuring your sending domain has proper SPF, DKIM, and DMARC records configured. Incorrect configuration can lead to emails being marked as spam or rejected entirely.

Rate Limits & Free Tiers

• Check Limits: Be mindful of sending limits imposed by your email provider, especially on free or low-cost tiers (e.g., Resend's free tier allows ~100 emails/day, Plunk's might be ~300/day).
• High User Growth: If you anticipate high user growth and have email verification enabled (NEXT_PUBLIC_AUTH_ENABLE_EMAIL_VERIFICATION=true), these daily limits can be reached quickly, preventing new users from verifying their accounts.

Mitigation Strategies

• Disable Email Verification: In src/env.ts (or via the config UI at /configure), set NEXT_PUBLIC_AUTH_ENABLE_EMAIL_VERIFICATION to false. This removes the need to send a verification email on signup but means user email addresses are not confirmed.
• Rely on Social Logins: Encourage or enforce login via social providers (like GitHub, Google, if configured) which typically don't require separate email verification through your app.
• Upgrade Provider Plan: Consider upgrading to a paid plan for higher or unlimited sending limits if required.