Supabase Auth returns email_address_invalid for an existing confirmed user

[niconikia88]

Hello everyone,

I'm troubleshooting a Supabase Auth issue in a project on the Free plan.

An existing, confirmed user can no longer sign in. Both password recovery (/auth/v1/recover) and magic-link authentication (/auth/v1/magiclink) return the error email_address_invalid.

The user still exists in auth.users, and the account is confirmed. The email domain has an MX record, and the MX hostname resolves to multiple IP addresses.

The project uses the hosted Supabase Auth service. I have not deleted or recreated the user because I need to preserve the existing account and its related data.

I have also checked the Auth logs and confirmed that the recovery and magic-link requests fail with HTTP 400 and the error code email_address_invalid.

Has anyone encountered this issue with an existing, confirmed user? What should I check next to identify the root cause and safely restore access?

Project reference: jhkwptjwhlsatixpazzo

Supabase support ticket: SU-507202

Thank you for your help.

[aymansalkhatib]

This error comes from Auth's email validation, before any email is sent. So the problem is the email address itself, not the user account. Check these:

1. Make sure the domain is not a test domain (example.com, .test, .local, .invalid).

2. Check the stored email for hidden spaces or strange characters:

select email, length(email), email ~ '\s' as has_space
from auth.users where id = '<user-id>';

3. Check the domain's mail records from a public DNS:
   dig MX <domain> @8.8.8.8

To restore access without losing the user's data, set a new password from your backend using the service role key:

await supabase.auth.admin.updateUserById(userId, { password: 'new-temp-password' })

Then let the user change it after signing in.

[SamRepository25]

One additional check: if the email address belongs to a legitimate production domain, I would investigate the exact address being passed to Supabase Auth before changing the user account.

1. Compare the email supplied to /auth/v1/recover and /auth/v1/magiclink with the stored auth.users.email. Check for leading/trailing whitespace, hidden characters, or unexpected encoding.
2. Verify that the domain is not classified as a reserved or test domain. Having valid MX records does not necessarily mean Auth will accept an address.
3. If the address and domain are valid, collect the timestamps, request IDs (if available), endpoint paths, and HTTP 400 error responses for Supabase Support to investigate the hosted Auth validation path.

I would avoid deleting or recreating the user, since that could complicate existing data relationships. I would also avoid changing the password as the first diagnostic step: it may provide a workaround, but it would not explain why both email-based endpoints reject the address.

Have you confirmed whether the affected email domain is a normal production domain rather than a reserved or test domain?

[niconikia88]

Thank you for the suggestion.

The affected address belongs to our normal company domain, cgmstampa.it, not a test or reserved domain.

I checked the existing record in auth.users:

• The stored email is nico.caruccio@cgmstampa.it.
• Its length is 26 characters and 26 bytes.
• No whitespace is present.
• The domain is cgmstampa.it, 12 characters, lowercase.
• The domain has MX records, and the MX hostname resolves to multiple IP addresses.

Both /auth/v1/recover and /auth/v1/magiclink return HTTP 400 with email_address_invalid.

I have not deleted or recreated the user, or changed the password. I would like to understand why the hosted Auth service rejects this address before making account changes.

I will collect the exact request timestamps and request IDs from the Auth logs if available.

Could this be caused by hosted Auth email validation or a project-specific configuration issue?

[niconikia88]

Additional diagnostic information from the Supabase Auth logs:

• Timestamp: 2026-10-13 19:20:40
• Method: POST
• Endpoint: /magiclink
• HTTP status: 400
• Log ID: c24f05c1-d15a-4c2b-8d06-dc6da4eccd9b
• Referer: http://localhost:3000
• Error: Email address "nico.caruccio@cgmstampa.it" is invalid

The request is reaching the hosted Supabase Auth service, but the email address is rejected. The stored email has no whitespace, and the domain is lowercase and has MX records.

Could someone help determine why the hosted Auth service rejects this existing, confirmed user's email address?

[Mohamedaloubaido]

Based on the additional details, I would treat this as a hosted email-validation-path issue rather than a problem with the auth.users row itself.

In the current Supabase Auth code, email_address_invalid can be returned during the email-send path when the validation client reports an invalid address, invalid format, or DNS validation failure. The hosted Auth configuration also has support for an email validation service and blocked MX records.

That fits your symptoms quite well:

• the existing user is confirmed;
• the stored address has no whitespace or encoding issue;
• the domain has valid MX records;
• both /recover and /magiclink fail before email delivery;
• the Auth log explicitly says the address itself was rejected.

So I would not delete or recreate the user. That would risk breaking references without addressing the validator that is rejecting the address.

A useful isolation test would be:

1. Verify whether normal password authentication still works for this user. If it does, that strongly isolates the problem to the outbound-email validation path.
2. If possible, test a disposable account using another address on the same cgmstampa.it domain. If it produces the same email_address_invalid, the issue is domain/MX-level rather than user-level.
3. Send Supabase Support the exact log ID you already captured (c24f05c1-d15a-4c2b-8d06-dc6da4eccd9b), project ref, timestamp, affected domain, and the fact that both /recover and /magiclink reproduce it.

If immediate account recovery is required and you control the project, an admin password update can restore password-based access while preserving the same user ID and relationships, but I would treat that only as a workaround — it will not resolve the underlying email validation problem.

Given the evidence so far, I think Supabase Support needs to check why the hosted validator is classifying cgmstampa.it (or its MX) as invalid.

[niconikia88]

Thank you all for your suggestions. I've completed the checks described in the comments.

Here are the results:

• The user exists in auth.users and is confirmed.
• The stored email is nico.caruccio@cgmstampa.it.
• The email has no whitespace, its character length matches its byte length, and the domain is lowercase.
• cgmstampa.it is our legitimate company domain, not a test or reserved domain.
• The domain has MX records, and the MX hostname resolves to multiple IP addresses.
• Both password recovery and magic-link authentication have returned email_address_invalid.

I also captured this Auth log entry:

• Timestamp: 2026-10-13 19:20:40
• Endpoint: POST /magiclink
• HTTP status: 400
• Log ID: c24f05c1-d15a-4c2b-8d06-dc6da4eccd9b

I have not deleted or recreated the user, and I have not changed the password.

Could Supabase Support or someone familiar with the hosted Auth validation service check whether this domain or its MX records are being rejected by the email validation path?

I would like to restore access while preserving the existing user ID and all related data.

Thank you.

[yos88da]

One thing nobody has mentioned yet, for when emails do go out: your log shows the request came from http://localhost:3000. Supabase uses the Site URL (Authentication → URL Configuration) as the default address in confirmation and password-reset emails, and the docs say to change it from http://localhost:3000 to your production URL: https://supabase.com/docs/guides/auth/redirect-urls. If it still says localhost, the reset link will open localhost even after support fixes the validation.

Also worth quoting in the ticket: the error list describes email_address_invalid only as "Example and test domains are currently not supported" (https://supabase.com/docs/guides/auth/debugging/error-codes), which doesn't fit a real company domain, so they need to say which rule rejected it.

[aymansalkhatib]

I went through the Auth (GoTrue) source to see which checks can produce this exact response, and it narrows things down quite a bit.

The 400 email_address_invalid with Email address "…" is invalid is returned by sendEmail in internal/api/mail.go for exactly three errors from the email validator (validateclient.go). The validator wraps the mail client, so it runs right before any email is sent. That's why /recover and /magiclink fail in the same way.

Validator error	When it fires	Fits your case?
invalid_email_format	mail.ParseAddress fails, or the parsed address differs from the input	No: plain address, no whitespace
invalid_email_dns	reserved names (.test, .local, example.com, …), a single-label domain, or both the MX and the A/AAAA lookup return a definite "not found"	No: cgmstampa.it has an MX (mx.cgmstampa.it). Timeouts and SERVFAIL are deliberately treated as valid
invalid_email_address	a short hard-coded list (test@gmail.com, …), Gmail local parts shorter than 6 characters, or the external validation service (email_validation_service_url) answering {"valid": false}	Only the last condition fits

The code also rules out two other suspects:

• A blocked MX (email_validation_blocked_mx) returns invalid_email_mx, which isn't mapped to this 400. It would show up as a different error.
• The auth.users row. The validator only looks at the address string.

So the most likely explanation is that the hosted email-validation service is rejecting this specific address. That's a per-address verdict you can't see or change from the dashboard, so it needs Supabase support. In the ticket, it helps to include your log ID and the result of testing a second address on cgmstampa.it: that shows whether the service flags the mailbox or the whole domain.

Restoring access now, without changing the account

auth.admin.generateLink() creates the same magic-link or recovery link but doesn't send an email. Since the validator only runs when an email is sent, it isn't involved; adminGenerateLink only does a basic format check (checkmail.ValidateFormat). From your server, with the service-role key:

const { data, error } = await supabaseAdmin.auth.admin.generateLink({
  type: 'magiclink', // or 'recovery'
  email: 'nico.caruccio@cgmstampa.it',
  options: { redirectTo: 'https://your-app.example.com/after-login' },
})
// data.properties.action_link: deliver it to the user through your own channel

(generateLink docs). The user ID, identities and related rows stay as they are, and the password isn't touched. redirectTo must be in your Redirect URLs allow list. As @yos88da pointed out, also make sure the Site URL is no longer http://localhost:3000.

One caveat: I can only read the open-source code, not the hosted configuration, so support has to confirm the service's verdict. Going by the code, though, nothing in your user record or DNS setup can produce this error.