Configure production email

Supabase's default email service is for initial exploration, not a public production application. It sends only to authorized project-team addresses, has a low project-wide quota, and provides no delivery SLA. Configure custom SMTP before testing production signup.

New Free plan projects using the default SMTP service cannot customize Auth email templates. Custom SMTP is therefore also a prerequisite for step 7 on those projects.

Prepare the sending service

Supabase works with SMTP providers such as Brevo, Postmark, Resend, SendGrid, or Amazon SES. In the chosen provider:

1. Add a dedicated transactional sending domain or subdomain, such as auth.example.com.
2. Create a sender such as no-reply@auth.example.com.
3. Publish and verify SPF and DKIM records.
4. Publish a DMARC policy and monitoring address appropriate for the domain's rollout stage.
5. Disable click tracking for Auth emails if it rewrites confirmation URLs.
6. Create SMTP credentials dedicated to the production Supabase project.

Keep authentication mail separate from marketing mail where practical. It protects deliverability and makes failures easier to isolate.

Configure Supabase SMTP

Open Supabase → Authentication → SMTP Settings, enable custom SMTP, and enter:

• sender name;
• sender email;
• SMTP host;
• port;
• username; and
• password.

Use the port and transport recommended by the provider. Do not put these SMTP credentials in NEXT_PUBLIC_ variables or commit them to the repository; Supabase stores them as hosted Auth configuration.

Send a test to an address outside the Supabase organization team. Delivery to only a project owner's address does not prove that custom SMTP is active.

Configure Auth rate limits

After custom SMTP is saved, open Authentication → Rate Limits. Supabase initially applies a low hourly email limit to a newly configured SMTP service. Increase it only to a volume the provider and sending domain can safely support.

Review these separate controls:

Control	What it limits
Emails sent	Combined signup, recovery, and email-change messages project-wide
OTP requests	Calls to the OTP endpoint project-wide
Per-user email cooldown	How soon the same user can request another message
Verification attempts	Attempts to verify a token, limited independently

Rate limits are abuse controls, not capacity targets. Add CAPTCHA or Turnstile before a public launch if automated signups could damage sender reputation or exhaust the quota.

Deliverability check

Inspect a delivered message's headers and confirm:

• the visible From address is correct;
• SPF passes;
• DKIM passes;
• DMARC passes or aligns as intended;
• links retain the original Supabase template URL; and
• the message is not unexpectedly rewritten by click tracking.

Completion check

• Custom SMTP is enabled in the production Supabase project.
• An external recipient receives the test message.
• SPF, DKIM, and DMARC results are understood.
• Auth rate limits match expected traffic and provider limits.
• Link tracking does not consume or rewrite one-time Auth links.

Next: Install email templates.