Supabase Email Templates: A Safe Design Checklist

Supabase auth emails should look like your product without changing how people sign in. The safest design workflow starts in Migma: prepare a restrained, branded email, review its HTML and inbox layout, then let the developer install and test it in Supabase.

The hard part is preserving the authentication contract. A polished button is useless if a template variable becomes ordinary text, a tracking wrapper changes the URL, or the reader lands in the wrong environment. This guide gives designers and developers a shared handoff checklist for those risks.

This workflow is published by Migma. It prioritizes reviewed creative, readable layouts, and a clear boundary between email design and authentication. It does not claim a native Migma–Supabase connector or replace Supabase's security configuration. Product details were checked against official documentation on October 14, 2026.

Decide which email you are designing

Start with one action: confirm signup, accept an invitation, sign in, change an email address, reset a password, or reauthenticate. Supabase documents these as separate authentication templates. Security notifications form another group and must be enabled at project level.

Write a one-sentence job for the selected template. For a signup confirmation, the job could be: “Help someone confirm the address they just entered and return to the application.” That sentence makes review easier. A promotional banner, product carousel, or unrelated newsletter signup does not help complete that action.

Agree on the application name, support destination, sender identity, and the exact button label before designing. The copy should describe the action accurately. A confirmation email should not imply that the account is already verified; a password reset should not say the password has already changed.

Build a small branded draft in Migma

Review the website-derived logo, colors, fonts, and approved facts in Migma brand settings. Then ask for a single-column authentication email with a recognizable logo, a short explanation, one main action, and a support line.

A practical brief is:

Create a signup confirmation email for our application. Keep the approved product name and button label. Use one column, readable text, and a restrained header. Leave authentication variables unchanged. Do not add offers, tracking links, deadlines, or claims that were not supplied.

Review the draft visually. Keep the useful text as live text rather than putting it inside a large image. Check the action with images blocked, and make sure the reader can identify the product without relying on a background illustration.

Migma prepares email-safe HTML and supports inbox checks. That helps with creative review, but it does not prove that the authentication flow works. Treat layout approval and sign-in acceptance as two separate checks.

Preserve the variables during handoff

Use the official Supabase variable names exactly. The following table is a working reference, not a replacement for reviewing the selected template's documentation.

Supabase's template engine uses Go templates. The syntax belongs to that engine; it is not interchangeable with another email platform's personalization language. Do not replace it with a convenient-looking merge tag during a design edit.

Keep a clean original and compare the exported HTML against it. Ask the developer to inspect variable spelling, spaces, braces, URL placement, and conditional sections. If a design tool has changed a variable, repair and retest it before installing the template.

Use synthetic examples during review. Avoid pasting real sign-in tokens or customer account details into a creative brief. A sample render can show how long addresses or missing names affect layout without exposing a live authentication link.

Choose the correct installation route

Migma's export workflow includes an HTML download. Use that reviewed file as the design handoff, with the developer responsible for adapting and installing the authentication template.

For a hosted Supabase project, the official documentation points to its dashboard template page. For local development and self-hosted configurations, it points to configuration files and local HTML templates. Those are different installation paths; a change in one environment is not evidence that another environment has changed.

If your project uses a custom sending hook, the developer must also review the hook's input, provider template, and runtime behavior. Do not assume that copying HTML into the dashboard updates a separate provider-managed template. Record which system actually produces the message.

Before rollout, save the last working template and the new version together. Include the message type and environment in the filenames so a teammate can restore the intended version without guessing.

Test the final message and the action

Run Migma Email Preflight for layout, writing, links, and common sending risks. Review desktop, mobile, light mode, and dark mode. A dynamic authentication URL may need separate runtime testing because its final value exists only when the system sends the message.

Then test from the final Supabase environment using controlled accounts. Check a fresh signup, the intended redirect, a missing optional name, and the actual inbox on a narrow screen. For a reset template, verify the reset journey rather than merely opening the message.

Supabase documents two important link hazards. Security scanners can prefetch and consume a one-time confirmation URL. External email tracking can also rewrite authentication links. Its documentation describes OTP or an intermediate confirmation page as approaches to the first problem and recommends disabling email tracking for the second. Have the developer choose the implementation appropriate to the application; changing button styling alone will not fix either issue.

Record the evidence: template version, environment, inbox checked, action tested, result, and reviewer. A provider accepting a message is not proof that the reader completed signup or that it reached the inbox.

Keep the next change easy to review

Future brand edits should be small. Change the logo, spacing, or approved wording without casually changing authentication behavior. After export, repeat the variable comparison and final-environment test.

Start with one template in Migma, approve its creative, and hand off the HTML with the checklist above. Once that message works, reuse its visual treatment for the other authentication emails while reviewing each action separately.

Frequently Asked Questions