Guide

Supabase "Error sending confirmation email" (500): causes and how to fix it

A new person signs up and your app shows "Error sending confirmation email". Public reports show it as a 500 with the code unexpected_failure: {"code":"unexpected_failure","message":"Error sending confirmation email"} (Supabase discussion #29703; also #36181). Password reset can fail the same way with "Error sending recovery email".

What the error means

With Confirm email on, Supabase Auth has to hand a message to an email server before the sign-up can finish. This error means that hand-over failed. The 500 status alone does not say why: Supabase's error reference says a 500 indicates the Auth service is degraded and "most often it points to issues in your database setup", and unexpected_failure means "Auth service is degraded or a bug is present, without a specific reason."

The reason is written in your project's Auth logs. In both public threads above, the first answer from a Supabase repository collaborator was the same: check the Auth logs for the message from the SMTP provider.

The causes, and how to fix each one

Start with step zero, then go to the cause the log points at.

0. Read the real error first

Every cause below leaves a different line in the logs, so this step decides which fix applies.

How to fix it

In the Supabase dashboard, open the Auth logs and find the entry at the time of the failed sign-up.
If the line mentions your SMTP provider (authentication failed, sender not allowed, certificate, connection), go to cause 2 or 3.
If it mentions a database object, trigger or relation, the problem is in the database: see "Database error saving new user".
If you send email through a provider, check that provider's own logs next. Supabase names them as the next place to look.

Source: Supabase troubleshooting: Not receiving Auth emails from the Supabase project

1. You are on the default email service and the address is not on your team

Unless you configure your own SMTP server, Supabase Auth "will refuse to deliver messages to addresses that are not part of the project's team". The error code reference lists email_address_not_authorized: "Emails can only be sent to members in your Supabase organization." The default service also allows 2 messages per hour and is "not meant for production use". Every address you test with is on the team. Every stranger is not.

How to fix it

Choose an email provider. Supabase names Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail and Brevo as examples.
From the provider, copy the SMTP host, port, username and password, and decide the sender address and sender name.
In the Supabase dashboard, open the Authentication settings, enable custom SMTP and enter those values.
Sign up again with an address that is not on your team.

Source: Supabase: Send emails with custom SMTP

2. Custom SMTP is on, but a setting is wrong

Supabase says "handover issues can occur due to misconfiguration of the custom SMTP provider". Check every value you entered: host, port, username, password and sender address.

How to fix it

Compare each field in Supabase with the values on your provider's SMTP page, character for character.
Use the SMTP username and password the provider issued, not your login to the provider's website.
Make sure the sender address is one your provider allows you to send from.
Save, then sign up again with a new address and read the Auth logs.

Source: Supabase: Send emails with custom SMTP

3. The sender domain is not verified with your provider

Email providers ask you to verify the domain you send from. In discussion #29703, the fix was adding the provider's DNS records (and adjusting how they were typed at the DNS host): "adding the DNS for resend did the trick."

How to fix it

In your email provider, add your sending domain and copy the DNS records it gives you.
Add those records at your domain's DNS host and wait for the provider to show the domain as verified.
Set up SPF, DKIM and DMARC for that domain, which Supabase recommends for deliverability.
Use a sender address on that verified domain in the Supabase SMTP settings.

Source: Supabase: Send emails with custom SMTP

4. A Send Email hook does not answer

If your project sends auth emails through a Send Email hook, Supabase lists hook_timeout: "Unable to reach hook within maximum time allocated." Only projects that use a hook can have this cause.

How to fix it

Check that the hook's endpoint or function is deployed and reachable.
Look at the hook's own logs for errors or slow responses at the time of the failure.
If you do not need the hook, switch back to SMTP sending.

Source: Supabase: Auth error codes

5. A sending limit was reached

When a limit is the cause, the message is usually different: "email rate limit exceeded", with status 429. With custom SMTP, Supabase starts you at 30 messages per hour.

How to fix it

Follow the email rate limit guide.
Raise the email limit on the Rate Limits page of the Authentication section once your own SMTP is set up.

Source: Supabase: Rate limits, Supabase: Send emails with custom SMTP

6. Supabase Auth itself is degraded

The one that is not yours to change. The Auth logs show no provider or database error, and Supabase describes unexpected_failure as "Auth service is degraded or a bug is present, without a specific reason."

How to fix it

Check Supabase's system status page (the "Check system status" link at the bottom of the Supabase docs) for an incident.
Retry after the incident is resolved, then sign up with a new address.

Source: Supabase: Auth error codes

Why you cannot see it yourself

You're signed in, your customers aren't. Your own address is on the team, so the default sender accepts it. You sign up once, so you never hit an hourly limit. A custom provider can accept the address you tested and still refuse the next one. Only a brand-new address from outside the team meets these causes.

Frequently asked questions

It worked yesterday. Why did it suddenly stop?

This exact question was asked in discussion #36181. The answer was to check the Auth log for an error from the SMTP provider. Read that line before changing anything.

Did the sign-up still create the user?

Check the Users list in your Supabase dashboard. If the user exists but is unconfirmed, they will later meet "Email not confirmed". Once email works, send a new confirmation with resend().

Can I just turn off email confirmation to make the error go away?

Yes, sign-ups will no longer send that email, but anyone can then register with an address they do not own, and password reset emails still need a working sender. Supabase says the reset flow, like sign-up confirmation, needs SMTP.

Related guides

Sources (official documentation)

Fixed it? Prove a real stranger gets in

After the fix, prove it with an address that is not on your team: it must get the email, confirm and sign in. Your own account cannot show that, because it is not new. Your AI reads your code. VibeFix signs up like a stranger.

Free check. An AI agent signs up to your live app as a brand-new person, with a real inbox of its own, on a phone and on a computer. You get the problem count, what each problem is, and one screenshot. It never changes your app and never emails your users. Test my app, free

$9 for one app. Shows which cause is breaking your app and where, the exact fix prompt for your app for every problem, plus 3 re-checks so you can see whether the fix holds for a stranger. It does not promise a fix; it shows what the agent saw.

VibeFix is independent. Supabase, Resend, AWS SES, Postmark, Twilio SendGrid, ZeptoMail, Brevo and Lovable are trademarks of their owners.

More guides