Supabase Signup Confirmation Email Not Received: Debugging Guide

Your Supabase signup flow looks correct, but confirmation emails aren't arriving. This is usually fixable in under an hour if you know where to look. The most common cause is rate limiting on Supabase's built-in SMTP provider, but it could be custom SMTP misconfiguration, URL redirects, or email filtering. Start by checking your auth logs before chasing email providers.

Why Supabase Signup Confirmation Emails Fail

Signup confirmation emails break for five main reasons. Understanding which one applies to you saves hours of debugging.

Suabase's built-in SMTP provider limits you to 2 emails per hour per project. If you're testing or running a public launch, you'll hit this ceiling immediately. The rate limit doesn't trigger a visible error in your app--emails silently fail to send. Custom SMTP gets around this, but only if your credentials and connection string are correct. A single typo in your SendGrid API key or Resend token silently breaks the whole flow.

Site URL and Redirect URL mismatches in your Supabase config are another common trap. The confirmation email generates a magic link using your configured Site URL. If the link points to the wrong domain or an unallowed redirect URL, the verification fails. This is especially common when developing locally (localhost:3000) then deploying to production.

Email providers maintain suppression lists for bounced or complained-about addresses. If a user's email previously bounced or generated a complaint on your SMTP provider, it will reject future emails from that address. You won't see an error in Supabase logs--the provider just silently drops the message.

User email server firewalls can also block your confirmation email. Enterprise companies often filter outgoing mail from certain IP ranges. If your SMTP provider's IP has a poor reputation (due to other customers' spam), it lands in spam or gets blocked entirely.

Quick Diagnosis: Identify Your Specific Issue

Your symptoms narrow down the root cause. Use this table to find your starting point.

Your first move is always the auth logs. Everything else follows from what the logs tell you.

Step 1: Check Your Auth Logs (Before Anything Else)

Nine out of ten email issues show up in your auth logs as a specific error. Checking the logs first prevents wild guesses.

Open your Supabase Dashboard. Navigate to Authentication > Logs. Filter for the timestamp when you sent your test email. Look for an "EmailSignUp" event.

If you see an error like "Email rate limit exceeded," you've hit the 2 emails/hour ceiling on Supabase's built-in SMTP. Jump straight to Step 2 (custom SMTP).

If you see "Email address is invalid," either your form is sending malformed email addresses, or the address is on your SMTP provider's suppression list. Test with a fresh email address you control completely (not a company domain).

If the logs show "Delivery failed" or "SMTP connection error," your custom SMTP configuration has a problem. Double-check your provider's credentials (API key, password, connection string) in your Supabase Auth settings.

If there's no "EmailSignUp" event at all, the problem isn't email--it's your client code. Your signup form isn't triggering the auth call. Check browser console for JavaScript errors.

Most developers skip the logs and spend hours debugging the wrong thing. Spending 2 minutes here saves 2 hours of guessing.

Step 2: Configure Custom SMTP (The 80/20 Fix)

Supabase's built-in SMTP is meant for testing only. Any production app needs custom SMTP.

The rate limit (2 emails/hour) is the killer. Even a small launch will exceed it. Plus, Supabase's built-in provider has poor IP reputation, so emails land in spam even when delivery succeeds.

You have four solid SMTP provider options. Resend is the simplest for startups: free tier covers 100 emails/day, then $0.20 per 1,000 emails. SendGrid starts at $29/month. Mailgun charges $0.50 per 1,000 emails on the pay-as-you-go plan. AWS SES costs $0.10 per 1,000 emails and integrates tightly with AWS apps.

For a 20-person company sending authentication emails, Resend is the obvious choice. Free tier until you scale, flat per-email pricing after that, and domain reputation is excellent (emails land in inboxes).

Here's how to set it up with Resend. Go to Resend.com and create an account. Get your API key from the dashboard. In Supabase, go to Authentication > Email Templates. Click "SMTP Settings." Fill in: SMTP Host: smtp.resend.com, Port: 465, Username: default, Password: (your Resend API key). Save.

Test immediately. Send yourself a test email from Supabase Auth settings. If it arrives in 5 seconds, your custom SMTP works. If it bounces or arrives in spam, check your Resend account logs for specific error details.

One common mistake: using "default" as the username instead of your actual Resend account email. Resend requires the username field for authentication, even though it's ignored. Double-check your SMTP credentials match your provider's documentation exactly.

Step 3: Verify Site URL and Redirect URLs

The confirmation email contains a magic link. That link won't work unless your Site URL and Redirect URLs are configured correctly in Supabase.

Go to Authentication > URL Configuration in your Supabase Dashboard. You'll see two fields: Site URL and Redirect URLs.

Site URL is the domain where your app runs. If your app is hosted on a custom domain, set Site URL to your production domain with HTTPS (no trailing slash). Confirmation emails will generate links pointing to your configured domain with an auth confirmation token.

Redirect URLs are the routes your app handles after email confirmation. These must be absolute URLs on your domain. Common patterns include your auth callback route or dashboard page. If you forget to add a redirect URL that your app uses, confirmation will fail silently--the user clicks the link and nothing happens.

Local development is a common trap. If you develop on localhost but deploy to production, you must change Site URL when you go live. Leaving it set to your local development environment in production means all email links point to your local machine, which is unreachable for real users.

Create separate Supabase projects for development and production. Your development project should use your local development address for Site URL. Your production project should use your production domain. This prevents accidental development URLs in production emails.

Step 4: DNS Records and Email Deliverability (Production Hardening)

If you've configured custom SMTP and verified your Site URL, but emails still land in spam or bounce, the issue is email deliverability. Your SMTP provider's IP has poor reputation.

You can improve this by setting up SPF, DKIM, and DMARC records. These DNS records tell receiving mail servers that your SMTP provider is authorized to send email on your behalf.

Go to your domain registrar or DNS provider. Add these records:

SPF record: v=spf1 include:sendgrid.net ~all (if using SendGrid) or v=spf1 include:resend.com ~all (if using Resend). This tells mail servers which IP addresses can send email from your domain.

DKIM record: Your SMTP provider generates this. In Resend, it's under Domains > Add Domain > Add DKIM Records. Copy the record into your DNS.

DMARC record: v=DMARC1; p=quarantine; rua=mailto:your-email@example.com instructs servers on what to do if emails fail authentication checks.

DNS propagation takes 5 minutes to a few hours. After propagation, your SMTP provider's emails will have better deliverability. Users' spam filters will recognize the email as legitimate.

Test your setup using your SMTP provider's built-in email preview tool. SendGrid and Resend both show how your email renders in Gmail, Outlook, and Apple Mail. This catches template issues before real users see them.

One last check: if you're using a custom sender address from your domain, make sure your SMTP provider allows custom from addresses. Resend does; SendGrid requires domain verification first.

Frequently Asked Questions

Why aren't I getting my verification email?

Your email hasn't been sent yet. Check Supabase auth logs for errors (rate limit, invalid address, SMTP misconfiguration). If logs are empty, your signup code isn't calling the auth API. If logs show "Delivery failed," your SMTP provider's credentials are wrong. If you see no errors, the email was sent--check spam folder and suppression lists.

Why is my email verification failing?

The user clicked the link, but verification didn't complete. This usually means the redirect URL isn't whitelisted in Supabase auth config. The user clicks the email link, gets taken to your app, but your app doesn't recognize the callback URL. Add the URL to Redirect URLs in Authentication > URL Configuration.

Does Supabase provide email service?

Supabase provides built-in SMTP for testing (limited to 2 emails/hour). For production, you must configure a third-party SMTP provider like Resend, SendGrid, Mailgun, or AWS SES. Supabase doesn't send emails itself; it relays your emails through your chosen provider.

Why can't I log into Supabase?

If you mean the Supabase Dashboard itself: check your password and 2FA settings. If you mean users can't log into your app after email confirmation: they likely didn't complete email verification. Check your app's auth redirect logic after email confirmation succeeds.

Is Supabase trusted for authentication?

Yes. Supabase's authentication system (built on GoTrue) is production-grade and used by thousands of apps. Email configuration complexity is a separate issue from auth trustworthiness. The email problem is almost always your SMTP configuration, not Supabase's auth logic.

The Bottom Line

Eighty percent of signup email issues resolve by configuring custom SMTP. Supabase's built-in provider is rate-limited and low-reputation; use Resend, SendGrid, Mailgun, or AWS SES for real traffic. If you've checked auth logs, set up custom SMTP, and verified Site URL and Redirect URLs, the remaining issues are almost always email filtering or DNS reputation.

If email configuration is slowing your shipping, managed hosting eliminates this entire debugging cycle. Ship handles authentication email out-of-the-box, so you ship faster and stop fighting email infrastructure. Get started with Ship for predictable, flat-fee hosting.