How to Use a Six-Digit Email Code for Supabase Signup and Sign-In

Set up Resend and use AI prompts to add email codes to your existing Next.js app.

Written by: Vladislav Zhirnov
Published: September 10, 2026
Updated: September 12, 2026
Reading time: 26 min read
Topics: #Supabase
#MVP Development

For a small app, I want a few ways to sign up, each easy to use. Google sign-in and an email option give people distinct choices. For email, pick one flow. I prefer a six-digit code here; I wouldn't put passwords, email links, and codes beside each other as three email choices.

Enter your email, get six digits, and type or paste them into the app. If your phone's notification preview shows the code, you may not even need to open the email.

I use six-digit email codes for signup and sign-in in Doogle, my dog-training app (opens in a new tab).

I like keeping people in the app they started in. On mobile, a sign-in link can open in the email app's browser, leaving them to find their way back. A code lets them return to the original screen and finish there.

Passwords give people another thing to remember. They can forget them or reuse one, and password resets add another flow for you to build, maintain, and test. That's why I prefer a code for the email option in this kind of app. Google sign-in can sit alongside it.

We'll use Resend (opens in a new tab), a service that sends emails for your app, to deliver the code. Supabase will create and check it. You don't need to know it already. We'll start with its account setup, let your AI handle the connected services, then build the screens and retry options.

Before you start

Your app should already recognize accounts and keep people signed in after a page reload. The prerequisite above covers that foundation.

Build the code flow in your app's local or test version. Keep existing login methods working during that change. For the finished screen, choose a few easy, distinct methods, such as Google sign-in and email codes. Use one email flow so people don't have to choose between several ways to do the same job.

First, create a Resend account (opens in a new tab) or sign in to one you already have. Complete any email verification it asks for and open the dashboard. Resend is the delivery service, not a new inbox you need to check. The code emails will arrive in your users' existing inboxes.

Your AI can do more than build the screens. With connected tools or browser access, it can also set up the sender and Supabase's email settings. You handle signing in and approving access. It should then do the setup that access allows.

Have these ready:

Your existing Next.js app and its Supabase project.
Your Resend dashboard, signed in to the account you want this app to use.
A domain you own, plus access to the settings that control its email and website records.
An email address you can use for testing, including one that doesn't already have an account in your app.
Your AI coding tool, opened in the existing app.

This prompt checks which app, accounts, and tools your AI can use. It identifies missing access before setup begins and leaves email settings unchanged:

Copyable prompt

Help me add email-code signup and sign-in to this existing app. First inspect our current Next.js and Supabase account setup and the tools you can use. Identify the exact Supabase project, my Resend account, and the provider that manages my domain's email and website records.

Reuse our existing login foundation. If part of it is missing, explain that before adding this feature. Identify whether we have a test project; if only the live project is available, tell me before changing shared email settings.

Use existing authorized connections or browser access. If a connection is missing, help me connect the provider's official tool. Resend has an official hosted MCP connection; do not make me build a custom server. Check the actual available operations instead of assuming a connector can change every setting.

I will sign in and approve any new account access. Keep private keys out of chat and tracked files; use the tool's protected credential storage. Tell me what you can now configure and any exact step that still needs me. Do not change email settings in this inspection step.

After you run it: Your AI should identify the right app and accounts, show which tools are connected, and name any missing access. You can now give it the setup jobs below.

Step 01Verify your sending domain in Resend

If your website is yourapp.com, use code.yourapp.com as the sending domain. The full sender address can be login@code.yourapp.com. Enter just code.yourapp.com in Resend's domain field; use the full address for the sender email.

That separate part of your domain, code.yourapp.com, is called a subdomain. I recommend it to keep these signup emails separate from other email you send. Your website can stay exactly where it is. Resend also recommends a subdomain (opens in a new tab) to separate different kinds of email.

Resend needs to confirm that you control the domain your emails will come from. The records that let Resend send mail for your domain live in your domain settings. They're called DNS records. You usually manage them where you bought the domain, unless you've moved that job to another provider.

Your AI can follow Resend's domain setup (opens in a new tab) to add the sending domain, read its required records, and check verification. Adding the records themselves also needs access to your domain provider. Resend supports connected AI tools, and its Cloudflare connection (opens in a new tab) can add records after you authorize it.

This prompt gives your AI the sending-domain setup: add the domain, add its required records, and check verification. Give it your chosen domain and sender address so it can work on the right setup:

Copyable prompt

Set up the sending domain for this app in the Resend account we identified. Use the domain and sender address I gave you. Inspect existing domains and records first so you reuse the right setup instead of creating duplicates.

Use Resend's official connected tools or the signed-in dashboard to add the sending domain if needed. Choose a region near our recipients and retrieve the exact records Resend generates. Add those records through our authorized DNS provider connection. If Resend offers a built-in connection for the provider, help me authorize it. Do not replace existing mailbox records or proxy a mail-related CNAME.

Check the existing DMARC policy and explain any needed addition before changing it. Leave receiving, open tracking and click tracking disabled for this login-email sender. Trigger verification once, then read the domain's actual status while it checks the records. Do not keep restarting verification as a way to poll. Report pending records as pending, not verified.

Complete everything your current access supports. If I need to add a record myself, give me its exact type, name, value, and priority plus the correct provider page. After I finish, resume verification. Show the final domain name and status without displaying secrets.

After you run it: Open the domain in Resend. Its name should match your chosen sending domain and its status should say Verified. If it still says pending, let your AI check which record has not appeared yet.

If you need to finish in the dashboard

Use the records generated for your domain. Some providers add yourapp.com to names automatically, so check that it does not appear twice. Resend's domain setup instructions (opens in a new tab) cover its supported domain providers.

A setting called DMARC controls how mail using your domain is treated. Check its existing policy against Resend's DMARC guidance (opens in a new tab) before changing it. You don't need incoming mail in Resend for this setup. Following Resend's login-email advice (opens in a new tab), keep open and click tracking off for these account emails.

Open Domains in Resend and choose Add Domain if your sending domain is not already there.
Enter the sending domain, such as code.yourapp.com, and choose a region near your recipients.
Add the records Resend supplies to your domain provider, preserving the records for existing email services.
Return to Resend, start verification, and continue when the domain says Verified.

Step 02Connect Resend to Supabase

Supabase will create and check the codes. Resend will deliver the emails. The connection between them uses an email-delivery setting called SMTP. Its mail server address is the Host value you'll check after setup.

Create a private key for the connection between Resend and Supabase. Resend calls these API Keys. Follow Resend's key setup (opens in a new tab) to give the delivery key Sending access, restricted to your verified domain. Your AI can create it through an authorized connection and save it into Supabase if its tools support handling credentials privately.

This key works like a private password for the email connection. Keep it out of chat and your app's browser code. If your AI's tools cannot transfer it privately, enter it directly in Supabase yourself.

This prompt connects your verified Resend sender to Supabase so Supabase can send your code emails. It saves the delivery settings and checks them while keeping the private key hidden:

Copyable prompt

Connect our verified Resend sender to the exact Supabase project identified earlier. Read its current email-delivery settings first. If it uses a custom Send Email hook or another delivery setup, explain that before replacing anything.

Create a dedicated Resend delivery key with Sending access restricted to our verified domain, using your authorized management connection. Store and transfer it privately. If your tools cannot do that without exposing the key in chat or screenshots, open the correct credential field for me to enter it instead.

Configure Supabase custom SMTP with host smtp.resend.com, port 465, username resend, our chosen sender address, and our app's sender name. Use the delivery key as the SMTP password. Use the existing authorized browser or a narrow update through the current Supabase Management API; do not assume Supabase's MCP exposes an email-settings tool. Do not push a fresh local settings file over unrelated hosted settings.

Save the connection and read back the non-secret settings. Show the project, sender, host, port and enabled state, with the password hidden. Do not send test emails yet or add separate Resend email-sending code to the app for this SMTP connection.

After you run it: Your AI should show the saved sender and connection details for the correct Supabase project. A hidden password field after saving is normal; actual email delivery gets checked in Step 4.

Check the sender and connection

To manage signup and sign-in in your Supabase project, open Authentication, then Email under Notifications, and choose SMTP Settings. Check that custom SMTP is enabled and the saved sender uses your verified domain.

The delivery key is different from the access your AI uses to manage your accounts. A key limited to sending email cannot configure domains. If you need to create that key yourself, use API Keys in Resend, choose Sending access, and restrict it to your sending domain.

You can use this connection with hosted Supabase. As Supabase's custom SMTP guide (opens in a new tab) explains, its built-in email sender is intended for limited testing. Custom delivery lets you send to your app's users. Check your current Supabase sending limits (opens in a new tab) and Resend account limits (opens in a new tab) before testing.

These field examples come from Resend's Supabase setup instructions (opens in a new tab). Use your app's values, then compare the saved connection with the table below.

Supabase fields for the sender email address and app name. — Sender fields shown in Resend's setup guide. Use your own verified sender address and app name.

Supabase email connection fields for the mail server address, port, username and a private password. — Connection fields shown in Resend's guide. Compare the saved values with the table below; keep the password hidden.

Setting	Value
Sender email	An address under the domain you verified, such as login@code.yourapp.com
Sender name	Your app's name
Host	smtp.resend.com
Port	465
Username	resend
Password	The Resend API key you just created

Step 03Put a six-digit code in the email

Supabase can send a sign-in link or a code. Its passwordless email setup (opens in a new tab) uses the same email request for both; the email template determines what the person receives. Email codes may appear as OTP, short for one-time password, in the settings.

In Supabase's email templates (opens in a new tab), check both Confirm sign up and Magic link or OTP. A new or unconfirmed account can receive the signup email, while a returning confirmed account receives the magic-link email. You can see that split in Supabase's email-flow implementation (opens in a new tab). Updating only the returning-user template can leave signup sending the old message.

This prompt updates the emails new and returning users receive so both can contain the code. It checks the code length and timing, then shows an example of the saved email before a real send:

Copyable prompt

Set up the emails for passwordless email-code signup and sign-in in our existing Supabase project. Inspect which templates new, unconfirmed, and returning accounts use. Check both Confirm sign up and Magic link or OTP against current Supabase behavior.

Use an authorized browser or the Supabase Management API to add {{ .Token }} to each relevant template, with a clear instruction to enter the code in our app. Inspect the existing content first and preserve any confirmation or sign-in links required by other login methods. Keep email confirmation enabled. Do not change the database or add password-based account rules.

Check the current code length, expiry, and wait between sends. Use six digits for this feature. Preserve the existing expiry unless we deliberately choose another value, because other email links can share it. Tell me the actual expiry and resend wait so the app can match them.

Save and read back the template content. Show a local preview of the exact saved email with an obvious sample code, without sending a live email. Label that preview as an example. If you cannot edit the hosted settings, give me the complete ready-to-paste template and open the exact template page; then verify what I saved. Do not call a local file change a saved hosted change.

After you run it: Your AI should show which templates it updated, confirm that the saved content contains the placeholder, and open the example email. The template contains {{ .Token }}; the received email should contain the person's six digits.

What the code email should look like

The saved template needs a clear instruction to enter the code in your app, followed by this exact placeholder:

{{ .Token }}

Supabase replaces this template placeholder (opens in a new tab) with the person's code when sending the email. Keep the spaces, braces, dot, and capital T as shown. The actual code should appear in the received email, not the placeholder.

Before removing an existing link, check whether another login option still uses that template. Password signup may share the confirmation email. Add the code without breaking that existing path, and leave email confirmation enabled.

The example below shows the placeholder becoming a code. Your email can use your own styling. Check the instruction and six digits, rather than trying to match the colors. The number shown here is an example, not a working sign-in code.

An example email template contains {{ .Token }}; the example email shows the six-digit code 038271. — Example: Supabase replaces {{ .Token }} with six digits when it sends the email. Your layout can differ.

Check the code settings

Save the relevant email templates. To choose email as a sign-in method, open Authentication → Sign In / Providers → Auth Providers → Email. Check Email OTP length and Email OTP expiration. Length is in digits; expiration is in seconds. Use six digits for this guide, and note how long the code is valid. Supabase's passwordless email settings (opens in a new tab) document a default expiry of one hour, but your project's setting is the one your app must follow.

Also note the wait between code requests. Supabase's sending limits (opens in a new tab) document a default of 60 seconds for another request by the same user. Your project may use a different value. You'll give that value to your AI in Step 5.

You now have a sender, a connection, and emails that can show a code. It's time to build the part people use.

Step 04Have your AI add the code sign-in screens

Keep the experience small: an email field, then a code field, then the app. One code field is enough. Let people paste all six digits at once.

Sending the email should open code entry. To sign someone in, the app needs Supabase to accept the code (opens in a new tab) and establish the signed-in state. Supabase calls the information that keeps someone signed in a session.

For the code field, keyboard hints (opens in a new tab) and autocomplete settings (opens in a new tab) can help phones offer a useful input method. They don't guarantee every email app will fill the code for you. Pasting should still work.

This prompt builds the email screen and sends the code through your existing account setup. It opens code entry after a successful send; accepting the code and signing in are the next job:

Copyable prompt

Add email-code signup and sign-in to this existing Next.js and Supabase app. Inspect the installed package versions, check their current documentation, and reuse our existing account setup. Preserve existing login methods during implementation. For the finished signup screen, keep a few easy, distinct methods, with one email flow. Use codes for this email option; do not add duplicate password or magic-link email choices. Identify existing-user access and shared dependencies before recommending removal of an existing method.

For this first change, build the email-entry screen and the transition to code entry. Use Supabase's current passwordless email-code send method, signInWithOtp. This option should work for new and returning accounts, so do not disable account creation for it. Check that the project's signup setting permits new accounts.

Use the app's existing design. Give the email field a visible label and normal email validation. Show which address will receive the code. While a send is in progress, show a waiting state and prevent duplicate requests. On failure or a timeout, make the controls available again and show a useful retry message. Do not claim the email was delivered when only the send request was accepted.

A successful send should open the code-entry screen. It must not sign anyone in; the send result normally has no user or session. Keep raw provider errors and account-existence details out of the message shown to users. Do not add the Resend key to the app.

Run the relevant checks and open this screen in the local or test app using your browser tools. Check email validation, the waiting state, and the transition to code entry with controlled test results. Show me what works and which delivery check still needs a real inbox. Keep the change limited to this job.

After you run it: Use a test address to request a code. You should see the address on the code-entry screen and receive an email with six digits. At this point, you should still be signed out.

This prompt connects the code field to Supabase so a valid code can sign the person in. It also handles paste, incorrect codes, and retries while keeping the app's existing sign-in behavior:

Copyable prompt

Connect the code-entry screen to Supabase verification, using the installed versions and our existing browser/server account setup.

Accept one six-digit code as text. Preserve leading zeros, allow whole-code paste, trim surrounding whitespace, and show a numeric keyboard on phones. Use the one-time-code autocomplete hint where supported. Keep a visible label, keyboard access, and readable feedback.

Use verifyOtp with the current email, the entered code as token, and type: 'email'. A new-user code and a returning-user code should use this email verification path. Do not try to decide whether an account is new by inspecting passwords or adding database triggers.

Only mark the person signed in after Supabase accepts verification and returns a usable session. Reuse our existing signed-in state and cookie handling, including the server's validated identity checks. Return the person to the appropriate page already defined by the app. Do not turn a successful send, a missing error, or an unverified user object into a login.

If the code is wrong, expired, or the request fails, keep the person on code entry with a clear next action. Let them correct and retry it. Clear the waiting state after failures and timeouts, and prevent duplicate verification attempts. Preserve our existing sign-out behavior.

Add focused tests for these states, run them, and show me the result. Do not rebuild unrelated account features.

After you run it: Try the received code. When it's accepted, your app should recognize the account and open the intended page. Next, make it easy to recover from a typo or a missing email.

Step 05Add resend and change-email options

Put Send another code and Change email beside the code field. The first asks for another email. The second lets the person correct the address without losing their place.

Show a countdown only while another send is unavailable. Use the actual wait you recorded from your project. The countdown helps the person understand the button; Supabase still decides whether a request is allowed.

There's a naming trap worth giving your AI explicitly. For this passwordless flow, Send another code repeats the same code-send operation. Supabase's separate resend operation (opens in a new tab) is for signup confirmation and other email flows. Don't choose it just because the button says “resend.”

When several emails have arrived, use the newest successfully requested code. Clicking a button that fails is not the same thing as receiving a replacement.

This prompt adds working ways to ask for another code or correct the email address. It keeps the wait and messages tied to the current address and tests what happens when a send fails:

Copyable prompt

Add Send another code and Change email to the email-code screen.

Use the project's resend wait you checked earlier; read the current setting if it is missing. Use that setting for the countdown, and still handle Supabase rejecting a request because of its limits. Do not invent a default. Keep the waiting state tied to the current address and prevent duplicate sends.

Send another code must repeat signInWithOtp for the current email. Do not use the separate signup-confirmation resend method. Only show a new successful-send message when that request succeeds. A failed or timed-out resend must clear the busy state and show the next action; it must not falsely say another email was sent.

Change email must return to email entry, clear the old code and messages, and make the next request use the corrected address. If an earlier send or verification finishes later, it must not replace the current address, code, or signed-in state. Handle both results returned to the form and updates from the existing Supabase sign-in handling. Ignoring an old form result alone is not enough if the login code can still sign the person in. Avoid overlapping verification attempts and clear any obsolete signed-in state before continuing with the corrected address.

Keep codes as text. Use clear messages for an incorrect or expired code, a wait before another request, and a connection problem. Map Supabase's structured errors to those actions instead of showing raw provider messages or revealing whether an account exists.

Add tests with a controlled clock and delayed results for resend timing, duplicate clicks, failed resend, timeout, and email changes while a request is pending. Run them and report what passed.

After you run it: Try both controls yourself. A corrected address should be the one shown on the next screen and used for the next email. If another-code request fails, the screen should tell you what to do instead of pretending a new code is on its way.

Check the retry controls

Your AI should open the finished screen and exercise both controls. The example below shows the parts to look for: the destination email, one code field, a clear sign-in action, and ways to request another code or correct the address. Keep your app's own design.

Example code-entry screen with the destination email, a six-digit field, Sign in, Send another code, and Change email. — Example screen after Steps 4 and 5. When another send is unavailable, show the wait beside its disabled control.

Step 06Test new and returning users

Try the flow as someone who isn't already signed in. Use a private browser window and a test address you can read. Keep an eye on the sending limits while testing.

These checks cover the experience you just built:

Try this	What you should see
Use an address that has no account in the app.	A code arrives. Supabase accepts it, finishes signup, and signs the person in on the intended page.
Sign out, then use the same address again.	Another code lets the existing account back in without a password.
Enter the wrong six digits.	You stay on code entry, see useful feedback, and can try again.
Let a code pass the expiry time you recorded.	It is rejected, and you can ask for another code when sending is allowed.
Ask for another code once the countdown ends.	One request is made, and the newest successfully requested code works. A failed send doesn't show a success message.
Correct a mistyped email address.	The old code is cleared. The next email goes to the corrected address, and an older result doesn't switch the screen back.
Reload after signing in, then sign out.	The app keeps the correct account on reload and returns to its signed-out state after sign-out.

Repeat signup and sign-in on your phone. Open the email, copy the whole code, return to the app, and paste it. Check that the code field keeps any leading zero and that the buttons and messages are easy to use.

You can ask your AI to simulate an expired code or a slow connection to check how the screens respond. Then check actual delivery with a real email.

This prompt has your AI test the complete flow and fix problems within this feature. It checks the screens and retry behavior, then tells you which real inbox or phone checks still need you:

Copyable prompt

Review the email-code flow we just added against the new-user and returning-user tests in this guide.

Run the local tests for wrong and expired codes, whole-code paste, leading zeros, duplicate sends, resend timing, thrown or delayed requests, and an email change before an old result arrives. Check our existing signed-in state too, so a stale verification cannot later sign in the wrong attempt.

Use your browser tools to check the local or test screen at desktop and phone widths. Exercise the controls, including keyboard entry and paste. Show the relevant screens using sample values; keep real sign-in codes and private account details out of screenshots. Separate simulated results from actual email delivery and a completed sign-in.

Fix failures within this feature and run the affected tests again. Report what you actually ran, what passed, and which checks still need me to use a real inbox or phone. Keep the existing login options and shared account foundation working.

After you run it: Read the test report and complete any real inbox or phone checks still marked as untested. Once those checks work and the retry controls behave as expected, the feature is ready for your normal review and publishing process.

Troubleshooting

Start with what you can see. It usually tells you which part to inspect next.

The email doesn't arrive

Check the address shown in the app, then check spam. If the address is wrong, use Change email.

If the address is right, open Resend's email activity and look for the attempted message. If it appears, inspect its status and any delivery explanation. A recorded send doesn't guarantee it reached the inbox.

If there's no message in Resend, follow Supabase's email troubleshooting (opens in a new tab) to check the saved delivery settings and sender's verified domain. Check the current sending limits too, including Resend's account limits (opens in a new tab). Ask your AI to inspect the error from that failed attempt without copying secret values into its report.

The code is rejected

Use the newest successfully requested code for the address still shown in the app. Check that all six digits were copied, including a leading zero.

If the code has expired, ask for another one when sending is available. If fresh codes keep failing, have your AI check that the app sends the current email and code to Supabase's email-code verification (opens in a new tab). It should also check that the configured code length matches the screen.

The resend button stays unavailable

If the countdown is still running, wait for it to end. If it reaches zero but the button never returns, ask your AI to check the waiting state after errors and timeouts.

If the button works but Supabase refuses another send, the app may have reached a different Supabase sending limit (opens in a new tab). Check the returned error and project settings. Changing the visible countdown won't change the server's limit.

The code is accepted, but sign-in doesn't finish

Ask your AI to follow the steps from accepted verification to your app's existing signed-in state. Check whether a usable session was returned, whether the existing browser and server setup agree on the account, and whether the app returns to the intended page.

If it works until you reload, have your AI inspect the existing signed-in state and cookie handling against Supabase's server-side account setup (opens in a new tab). If it happens after Change email, check that an earlier verification isn't updating the new attempt. This is a job for the account setup already in the app.

Still having trouble?

Pull me into your project with @Vlad, your virtual co-founder. Or, if you'd rather work with the real me, set up a call.

Get @Vlad Setup a Call

Summary

The experience is simple: enter an email, receive a code, paste it into the app, and sign in. Supabase checks the code. Resend delivers the email. Your app handles the screens and gives people a way to retry or correct an address.

Finish by trying it with a new account, a returning account, and your phone. When those paths work, move on to the next part of your product.

About the author

Vladislav Zhirnov

Co-Founder and CPO at Pinpoint

I'm Vladislav Zhirnov, Co-Founder and CPO at Pinpoint (opens in a new tab). There, I lead product strategy, contribute to early growth, and build AI systems that enable us to iterate quickly. Through this site, I help founders and product teams turn promising apps into successful products real people use.

Before this chapter, I spent more than five years at Side (opens in a new tab), growing from Product Manager Trainee to Director of Product Management. There, I led DUBS - a social gaming platform for teens - from concept to over 150,000 installs.

Away from the screens, I live on a homestead with Carl the mini-Highland cow and a rather large supporting cast.

To learn more about Pinpoint and the other projects I'm involved in, visit my portfolio.

Learn more about me

Common questions

Can I keep my existing login options?

Yes. A few simple methods can work well together, such as Google sign-in and one email option. For email, I prefer a code here. Avoid making people choose between several email flows that do the same job. Keep existing methods working while you add and test codes. Check existing-user access and shared email templates before removing anything.

How long should a code stay valid?

Start with the value in your Supabase project and make the email and app agree with it. Supabase's email-code settings (opens in a new tab) document a one-hour default. If you shorten it, give people enough time to receive the email and return to the app. Test that choice on a phone, rather than assuming the shortest possible window is best.

Does Resend replace Supabase?

No. Resend delivers the account emails. Supabase creates and checks the codes and handles the signed-in account. Connecting Resend changes the delivery service; it doesn't replace your app's account setup.

Sources

18 references

Show 10 more references

Choose your next move

Keep moving from idea to real use.

App Readiness CheckCheck the rest of your app before real people do.Use the App Readiness Check to find the next signup, data, payment, or publishing gap that could stop a real user.Check Your App Virtual Co-FounderBring @Vlad into the project.Bring @Vlad into the project to untangle a hard problem and turn the next move into a plan.Get @Vlad Hands-on helpWork directly with Vlad.Get direct help finding the actual problem and moving your app, AI system, or workflow toward real use.Setup a Call

Scan my page