For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /docs/web/email.md (or send Accept: text/markdown).
Email and mailing
Transactional templates, preview tooling, and provider adapters.
Read your first local message, then enable delivery
Transactional email means a message triggered by an app action, such as a sign-in code or task result. With the Web server running, keep EMAIL_PROVIDER=local in apps/web/.env.local. Complete database setup, request a sign-in code at /auth, then open /mail-preview and inspect the latest message. A local message appearing here is not an email delivered to your external inbox.
To send real messages, choose one email provider, create its account, verify a domain you control and follow its dedicated guide. Put the named API key and sender address in apps/web/.env.local, save and restart the Web server. Request one new sign-in code, then check both the provider's delivery log and the destination inbox, including spam. Domain verification and sender approval can take time.
If the message fails, inspect the delivery error and sender verification before requesting repeatedly. The /mail-preview route is development-only and returns 404 in production. Keep marketing outreach separate from this transactional sender so a newsletter campaign cannot disrupt account verification mail.
Keep transactional delivery separate
The email module handles transactional product messages, including authentication and task completion. Outreach belongs to the consuming product’s own workflow and must remain separate from this transactional path.
Configure the delivery adapter
Use the local adapter for deterministic tests. Configure the selected production adapter and its server-side credentials before enabling external delivery. Never place mail-provider secrets in client configuration or logs.
Record delivery independently
A generated result and its completion email have separate outcomes. Inspect delivery records before claiming a message was sent successfully. Test a failed delivery without treating it as a failed generation or submitting duplicate model work.
Setup and configuration
EMAIL_PROVIDER=local keeps delivery deterministic during development. For production delivery pick one of the configured adapters — Resend (RESEND_API_KEY), AWS SES (AWS_REGION plus access keys), Postmark, SendGrid, Mailgun, generic SMTP, or Brevo — and verify EMAIL_FROM matches a sender identity the provider accepts.
All templates live in src/transactional-mail-templates.ts. The dev-only /mail-preview route renders every template so changes are reviewed visually instead of by sending mail.
EMAIL_PROVIDER=resend
EMAIL_FROM=Your Product <[email protected]>Implementation workflow
Authentication codes, magic links, invitations, billing notices, and task-completion mail all pass through the same transactional sender with the resolved locale's copy. Outreach campaigns are a separate product concern and never share this path.
Preview a template in mail-preview before editing copy or layout; keep brand values (name, colors, logo tiles) coming from configuration so derived products restyle without forking templates.
Verification and troubleshooting
Assert on the local adapter's recorded messages in tests — recipient, subject, and rendered body. A failed send must surface as a delivery outcome, not a crashed workflow. Use the opted-in smoke path with REAL_SMOKE_EMAIL_ALLOWED_DOMAIN for real delivery.