Supabase Auth rejects a valid email address during password recovery

[LK-1708]

Hello Supabase community,

I'm building a Next.js application hosted on Vercel, using Supabase Auth for user authentication.

When calling supabase.auth.resetPasswordForEmail() for an existing user, I receive this error:

Email address "[redacted]" is invalid

The mailbox is active and used daily. The address format is valid, and the account exists in Authentication → Users.

What I have checked:

• The application uses the correct Supabase project URL.
• The resetPasswordForEmail() call specifies https://exclusive-parking.vercel.app/reset-password as the redirect URL.
• The redirect URL is configured in Supabase.
• The /reset-password page exists and the Vercel deployment succeeds.
• The email domain has a published MX record.
• I have tried entering the address manually and normalizing it in the application code.
• Custom SMTP is currently disabled; the project uses Supabase's default email service.

An earlier recovery email was delivered, but its link redirected to localhost:3000. After correcting the redirect configuration, recovery attempts began returning the invalid-email error.

Has anyone experienced this behaviour with Supabase Auth? How can I determine whether the rejection comes from GoTrue's email validation, project configuration, or another cause?

I have not included any secret keys, passwords, or access tokens.

Thank you.

[k1ng-arthur]

The supabase email service has rate limits, try using a custom SMTP. Also i would check that the email domain does not look like spam/temporary as that has caused problems before.

[puneet26082006]

Hi! I think there are two separate things worth checking here: email validation and the recovery redirect.

The redirect URL only controls where the user is sent after opening a recovery link. Changing it shouldn't by itself cause an email address to become invalid.

One important detail is the actual Supabase error code.

• email_address_invalid points toward email validation.
• email_address_not_authorized means the recipient isn't permitted by Supabase's default email service.
• 429 indicates a rate limit.

Since you're using the default email provider, remember that Supabase currently restricts delivery to email addresses belonging to your project's organization. For production users, you'll need custom SMTP.

I'd suggest checking the following:

1. Open DevTools → Network and inspect the response from /auth/v1/recover.
2. Check the exact error.code and HTTP status, not just the displayed message.
3. Compare the email with the address stored under Authentication → Users.
4. Check Authentication logs at the exact time of the failed request.
5. Confirm whether the affected address belongs to your Supabase organization's team.

Supabase documents the errors here:
https://supabase.com/docs/guides/auth/debugging/error-codes

And the default SMTP restrictions here:
https://supabase.com/docs/guides/auth/auth-smtp

If you can share the sanitized error code and status, it should be possible to narrow this down considerably without exposing the user's email or any credentials.

[kirlyr]

Since recovery emails were delivered before, I'd separate the email-validation issue from the redirect URL issue first.

The redirect URL controls where the user goes after recovery, but it shouldn't normally determine whether the email address itself is valid.

A couple of things I'd check:

• Log the Supabase Auth error code and HTTP status, not just the message.
• Check whether the same error occurs for another existing test account.
• Verify the exact request payload being sent to /auth/v1/recover, with sensitive data removed from any shared logs.
• Compare the current behavior with and without the redirectTo option in a controlled test.

This could help distinguish a validation issue from a redirect configuration problem.

I'd avoid posting the actual email address publicly. If both tests fail with the same error, the Auth error code and request timestamp would be useful for Supabase support.

[yos88da]

Two separate things are going on here, and the first email you got points at one of them. A recovery link that opened localhost:3000 usually means the Site URL in your project is still the default. Supabase's redirect URL docs say that setting is the default redirect when no redirectTo is passed, and to change it from http://localhost:3000 to your production URL. It is under Authentication, URL Configuration. Also check that your production address is listed in Redirect URLs, since redirectTo has to match an allowed entry.

The invalid email error is a different path. As mentioned above, look at the exact error code in the response from /auth/v1/recover and in the Auth logs. If it is email not authorized instead, that is the default email service only sending to addresses on your organization's Team tab, and the SMTP docs say to set up custom SMTP for real users.

I wrote up the common causes and how to find yours: https://vibe-fixer.com/guides/password-reset-link-opens-wrong-site?src=gh-sbreset. I run VibeFix.

[bintangyudhis]

The message text alone is ambiguous — the deciding detail is the exact code in the response from POST /auth/v1/recover (DevTools → Network, or your Auth logs). The two candidates mean very different things, per Supabase's error code reference:

• email_address_invalid — GoTrue rejected the address at validation. Supabase's docs describe this code as covering example/test domains, which aren't supported. Since your mailbox is real, the likely culprit is the exact string your app sends: you mentioned you tried normalizing the address in code — test one recovery with a raw request that bypasses your app entirely:

  curl -X POST 'https://<project-ref>.supabase.co/auth/v1/recover' \
    -H 'apikey: <anon-key>' \
    -H 'Content-Type: application/json' \
    -d '{"email": "the-exact-address"}'

  If the raw call succeeds, your normalize/validation step is mangling the address (whitespace, encoding, or an over-strict helper). If it fails with the same code, also try a second, mainstream address — that splits "this specific address" from "every address".

• email_address_not_authorized — this is the default email service restriction: with custom SMTP disabled, Supabase only delivers to members of your project's organization. Real end users will always fail this way until you set up a custom SMTP provider. If this is your code, that's your whole answer, and it also explains the timing: your earlier successful delivery was probably to an address inside your organization.

The localhost link in the first email is a separate issue and already covered above: your Site URL under Authentication → URL Configuration was still the default http://localhost:3000.

[kirlyr]

I found a very similar report in #51652, and the GoTrue source gives us a useful workaround here.

In internal/api/mail.go, the exact "Email address ... is invalid" response can come from the email validator during the sending process. The validator can even reject a real address with valid MX records if the external validation service returns {"valid": false}.

If your response code is email_address_invalid, one option for restoring access without recreating the user is to generate a recovery link through the Admin API:

const { data, error } = await supabaseAdmin.auth.admin.generateLink({
  type: 'recovery',
  email: userEmail,
  options: {
    redirectTo: 'https://exclusive-parking.vercel.app/reset-password'
  }
});

if (error) throw error;

// Deliver data.properties.action_link securely
// through your own email provider.

Unlike resetPasswordForEmail(), generateLink() creates the link without sending the email through Supabase's built-in mailer. So it may work around a rejection occurring in that sending path.

Important: this must run on a trusted backend with a server-only admin key. Never expose or log the generated link or token, and only deliver it to the verified account owner.

This doesn't fix the underlying validator. If /auth/v1/recover still returns email_address_invalid with the correct address, I'd send Supabase support the request timestamp and Auth log ID so they can inspect which validation rule rejected it.

If the actual code is email_address_not_authorized instead, that's the default SMTP restriction, and configuring custom SMTP is the appropriate fix.

[solvionholdings]

The message Email address "..." is invalid is the email_address_invalid code. It is different from the default-SMTP restriction, and the fix is different, so check error.code first:

• email_address_invalid: Auth's email validator rejected the recipient. Per the error-codes docs, example and test domains aren't supported (https://supabase.com/docs/guides/auth/debugging/error-codes). In practice it fires for blocked test hosts such as example.com, test.com or localhost, and for domains whose MX lookup comes back empty when Auth goes to send.
• email_address_not_authorized: you're on the built-in SMTP service, which only sends to members of your Supabase organization. Fix it with custom SMTP (https://supabase.com/docs/guides/auth/auth-smtp).

const { error } = await supabase.auth.resetPasswordForEmail(email.trim(), {
  redirectTo: 'https://your-app.vercel.app/reset-password',
});
if (error) console.error(error.code, error.status, error.message);

The validator only runs when Auth is actually about to send. For an address with no account, Auth sends nothing and returns success, so it never trips. That's why a real user can fail while a fake address "works". Test against the deployed domain's actual MX with dig +short MX yourdomain.com from outside your network.

The earlier localhost link is a separate issue. It comes from the Site URL under Authentication → URL Configuration still being http://localhost:3000. Set it to your production URL and keep your Vercel preview URLs in the Redirect URLs allow-list (https://supabase.com/docs/guides/auth/redirect-urls).

One security note: on your reset form, show the same "if an account exists, we've sent a link" message whatever the error. Showing different text for this error reveals which addresses have accounts. resetPasswordForEmail is designed not to reveal that (https://supabase.com/docs/guides/auth/passwords).

I wrote up the details here: https://www.guardlayer.io/blog/supabase-email-address-invalid-password-reset