Install email templates

Hosted and local templates are configured separately. Edit hosted templates under Supabase → Authentication → Email Templates. Files under supabase/templates/ affect only the local CLI stack.

Use the reusable Supabase email-template examples as a safe starting point, then apply the product's branding and support details.

Match signup verification

The confirm-signup template must match SIGN_UP_EMAIL_VERIFICATION:

• otp: show {{ .Token }} and instruct the user to enter the configured-length code in the application.
• link: construct a token-hash link using {{ .RedirectTo }} and send it through /auth/confirm.
• otp-and-link: include both alternatives and explain that using either one consumes the verification.
• disabled: Supabase does not send a signup-confirmation message.

Passwordless login is different and always exclusive. Its hosted Magic Link or OTP template must contain only {{ .Token }} in otp mode or only the login link in link mode. Never include both for passwordless login.

Install the authentication templates

Review every flow enabled by the application:

Template	Required content
Confirm signup	OTP or token-hash link matching the chosen verification mode
Magic link	A sign-in link using the Supabase confirmation URL or the application's documented callback construction
Reset password	A recovery link that returns to /auth/callback?flow=recovery; Core verifies the recovery session before /account/reset-password/new
Invite user	Invitation purpose, expiry wording, and acceptance link
Change email address	Old/new-address context appropriate to secure email change
Reauthentication	The {{ .Token }} and the action it authorizes

Use {{ .RedirectTo }} when the application supplies a per-request redirect. {{ .SiteURL }} is the project's fixed fallback and can silently return a user to the wrong route when substituted for RedirectTo.

Enable security notifications

Where supported by the product, enable and brand the notifications for:

• password changed;
• email address changed;
• phone number changed;
• sign-in method linked or removed; and
• verification method added or removed.

Security messages should state what changed, when practical, and what the user should do if they did not perform the action. Do not place secrets, raw tokens, or sensitive user metadata in a notification.

Template safety

• Keep the subject specific and recognizable.
• Include a plain explanation of why the message was sent.
• Use the configured product and support names consistently.
• Do not claim a hard-coded expiry that differs from Email OTP Expiration.
• Avoid externally hosted tracking pixels in security-sensitive messages.
• Disable provider click tracking that rewrites one-time links.
• Use user_metadata only for harmless presentation; never treat it as authorization data.
• Test both mobile and desktop rendering with real mail clients.

Completion check

• The signup template matches SIGN_UP_EMAIL_VERIFICATION.
• The passwordless template contains only its configured OTP or link method.
• Every enabled Auth flow has a template with correct destinations.
• Expiry copy agrees with the hosted Email OTP Expiration setting.
• Security notifications are enabled and branded where appropriate.
• A real external mailbox renders each important template correctly.

Next: Verify production.