Email and outgoing services

Outgoing email and related services for verification, notifications, and self-hosted dFlow.

Written By Zoro

Last updated 3 days ago

Application teams expect invites, password resets, and similar flows to arrive by email.

On self-hosted dFlow, you provide the transactional provider and keys; the product does not send mail without them.

Resend (primary path in Compose examples)

Set on payload-app:

VariableNotes
RESEND_API_KEYCreate in Resend for your domain
RESEND_SENDER_EMAILMust be verified (or from a verified domain)
RESEND_SENDER_NAMEDisplay name shown in clients

Operator checklist

  1. Verify your sending domain (SPF, DKIM, DMARC per Resend guidance).
  2. Use separate API keys per environment (prod vs staging).
  3. Rotate keys in your vault; update Compose and recreate the container.

If mail fails, check container logs for HTTP errors from the provider and confirm the from-domain is still verified.

Logging and telemetry (Better Stack)

Optional public client variables:

  • NEXT_PUBLIC_BETTER_STACK_SOURCE_TOKEN
  • NEXT_PUBLIC_BETTER_STACK_INGESTING_URL

These power browser log forwarding when enabled. Omit them if you do not use Better Stack; the app should tolerate absent optional telemetry when your build allows it.

Discord and support links

NEXT_PUBLIC_DISCORD_INVITE_URL is cosmetic for in-app links. Point it at your internal Slack or support system if you fork the UI, or leave a neutral community link.

Cloudflare Turnstile (optional bot protection)

When enabled in your deployment:

  • NEXT_PUBLIC_TURNSTILE_SITE_KEY
  • TURNSTILE_SECRET_KEY

Match keys to the same Cloudflare account and hostname policy you use for the dashboard domain.

What application teams still do

Teams configure Service env vars and app-level mail (for their own apps) in the dashboard. They do not configure RESEND_* for the control plane; that remains operator-owned.

Related