A custom SMTP launch checklist for Supabase and Resend

A custom sender should leave you with a configuration you understand and accounts you still control. The useful preparation happens before copying any setting: decide which project sends, which domain identifies the message and which action you will test.

This checklist covers a hosted Supabase project that you control and an existing web authentication path. It does not assume every app built in Lovable or another builder exposes the same settings. A builder’s general email connector may serve product notifications while authentication uses a different route. Confirm who actually operates your Auth backend first.

Start with a small scope sheet

Write down the Supabase project, public app URL, chosen path and expected destination. Choose one of signup confirmation, password reset, magic link or invitation. Record the email provider account and sender domain. Decide who has authority to change DNS and who will operate the test mailboxes.

“Make all email work” is not a small scope. An invitation and a reset may share a sender but have different templates, destinations and app behavior. Test coverage should match the promised outcome rather than expanding silently after the first message arrives.

Keep ownership and credentials separate

Create or use the provider account in the app owner’s organization. The owner should enter sensitive values directly in the relevant tools. A readiness form does not need an API key, service-role credential, password or live reset link. Sending those by email makes a simple setup harder to control.

Resend’s official SMTP guide lists a verified domain and an API key among the prerequisites. Its Supabase integration can handle the connection without a helper manually passing credentials around. Use the native integration where it fits; paying someone should buy coordination and verification, not an invented proprietary step.

Inventory DNS before changing it

Find the current DNS host and note existing mail-related records. The domain may already receive business email or send through another service. A provider’s requested addition is not permission to replace unrelated MX or authentication records. Preserve the baseline and write a rollback note for each intended change.

Use the provider’s exact instructions for the chosen sending domain or subdomain. If a record conflicts with an existing service, stop and resolve that conflict with the owner. Do not paste a second policy record or impose a restrictive organization-wide policy just because a checklist contains a familiar acronym.

A dedicated sender subdomain can make the scope easier to describe. For example, mail identifying an app’s authentication service should be distinguishable from marketing mail. The specific DNS names remain the owner’s decision, and verification status must be checked at the provider rather than guessed from elapsed time.

Separate the sender domain from the Auth URL

The address in the message’s From field and the host in an authentication link are different things. A verified sending domain does not automatically change your Supabase Auth endpoint. An optional custom Auth/API domain may involve separate platform configuration and cost.

Be explicit about which one you are changing. The basic AuthMailReady scope concerns a customer-owned sender and one existing path. An optional platform domain is not quietly purchased or bundled into that fee. Ask whether the added change is necessary for the agreed task before taking it on.

Check the intended destination

Review the production Site URL and the precise allowed destination for the selected path. Avoid making a broad wildcard a shortcut for understanding the app. Configuration can point an implemented path to the right place, but it cannot create a missing reset form or callback handler.

Choose factual sender branding and an unambiguous message purpose. This is not the place to turn an authentication message into a sales campaign. If a template change is needed, preserve the fields and link behavior the app expects. A redesigned email that breaks the action is a regression, not polish.

Review tracking and limits deliberately

Resend’s auth-email guidance discusses link tracking and automated link scanners. Do not assume marketing-oriented tracking settings are appropriate for a single-use auth action. A provider can also accept mail while the application’s own rate limit restricts the next attempt.

Write down the relevant account limits, not just the provider’s monthly quota. Resend’s published Free transactional tier currently includes 3,000 emails per month with a 100-per-day cap. A paid plan changes provider allowances; it does not automatically rewrite Supabase configuration. Recheck current limits before promising launch capacity.

Test, record and hand back

Once required verification has completed, run the small owner-approved test set. Record the Auth event, provider event, mailbox observation and completed action. DNS propagation and account review are waiting states; repeatedly sending messages will not resolve them.

The handoff should identify what changed, what passed, what remains unknown, the provider costs and the rollback steps. Keep active tokens out of the report. If the test reaches the mailbox but fails inside the app, say so and agree the next scope. Use our acceptance guide to make that distinction concrete.

If you are comfortable with these steps, use the native tools. If coordinating them is the obstacle, the buyer’s guide explains what the fixed-scope service does and does not add.