Supabase Auth — Email Delivery (Resend)

Supabase Auth — Email Delivery (Resend)

Overview

Supabase sends auth emails (magic links, invites, confirmations, resets) via Resend through an SMTP relay. This runbook documents the configuration only; it does not change production.

Verified Resend domain

The Resend domain used for all auth email from addresses is the one verified in the Resend dashboard. All DNS records (SPF, DKIM) must be active before emailing any tenant users.

Credentials

Value	Where it lives
SMTP password (Resend API key)	Supabase project secret SMTP_PASS
SMTP host	smtp.resend.com
SMTP port	587 (STARTTLS)
SMTP user	resend
Sender identity	from: "Supabase Auth <noreply@<verified-domain>>"

The API key is only stored in Supabase as the SMTP_PASS environment secret. It is never committed to git, never logged, never quoted in error messages, and never returned by any API.

Configuration surface

Email behaviour is driven by Supabase auth settings (templates, link expiry, redirect URLs). Changing those settings is not covered by this runbook. This document only covers the SMTP transport path.

Testing

1. Trigger a real auth flow from a test user account in the Supabase Authentication dashboard (e.g. “Send magic link”).
2. Confirm receipt at the destination inbox.
3. Inspect headers for proper SPF/DKIM alignment with the verified Resend domain.

Rollback

If email delivery fails after a configuration change:

1. Revert the config change (Supabase dashboard or supabase CLI).
2. Restart the Supabase auth service (project-level restart from the dashboard).
3. Re-run the test flow to confirm delivery.

Production safety

• This runbook does not change production. It is reference-only.
• Never commit, log, or echo the SMTP_PASS value or any Resend API key.
• If a key is suspected leaked: rotate it in Resend immediately, then update Supabase SMTP_PASS with the new value.