If Supabase signup, password-reset or magic-link emails stop reaching real users, first identify whether the message was rejected by Supabase, refused by your email provider, delivered to spam, or delivered with a broken confirmation link. Those are four different failures. Changing SMTP settings blindly can leave the real problem untouched.
For a live SaaS or client portal, this is not just an email issue. A new customer cannot activate an account, an existing customer cannot recover access, and support may have no reliable way to distinguish a failed signup from an unconfirmed one. Fix the entire journey before declaring the incident resolved.
Quick diagnosis: follow the failed message
| What you see | Likely layer to investigate first | What to verify |
|---|---|---|
| “Email address not authorized” | Supabase’s built-in sender | Is custom SMTP actually enabled? |
| HTTP 429 or “email rate limit exceeded” | Supabase Auth rate limits | Which project-wide or per-user limit was reached? |
| “Error sending confirmation email” | SMTP handoff or Auth-side failure | What do Auth logs say at that exact time? |
| Provider says delivered; user has nothing | Inbox delivery | Provider events, spam, suppression and domain authentication |
| Email arrives but link opens localhost | Auth redirect configuration | Site URL, allowed redirect URLs and email template |
| Email works for the founder but not customers | Built-in sender restriction or deliverability | Test with an address outside the project team |
This is a diagnostic map, not proof of any individual cause. Record the exact error code, time, affected environment and provider event before editing production settings. Never paste SMTP passwords, private keys or customer email addresses into a public support thread.
Why a demo works but real signups fail
As documented by Supabase’s current SMTP guide, the default email service is intended for testing, not production. It sends only to addresses belonging to the Supabase organization’s team and currently allows two Auth emails per hour across the project. These restrictions can change, so verify them against the live documentation.
This creates a particularly misleading launch test. The founder signs up using a team email and receives a confirmation. A real customer signs up using a different address and receives nothing. The interface may still show a friendly “check your inbox” message.
Supabase’s Auth testing guide documents the relevant errors: `email_address_not_authorized` for the team-only restriction and `over_email_send_rate_limit` for the project email cap.
Do not disable email confirmation merely to make signups appear successful. That allows accounts to be created without proving ownership of the email address and does not repair password-reset delivery. It changes your trust model instead of solving the incident.
Fix the sending path without weakening authentication
1. Check Supabase Auth logs before buying anything
Find a failed request in your project’s Auth logs. Confirm whether the response was a rate limit, an unauthorized destination, a provider authentication failure, or a different Auth/database error. Compare the timestamp with the corresponding request in the browser or server logs.
If Supabase handed the message to your email provider, inspect that provider’s delivery events next. Supabase’s troubleshooting guidance explains that after handoff, delivery depends on the provider and recipient mail systems.
A 200 response from an application endpoint is not evidence that the customer received and successfully used the email.
2. Configure a production sending provider
Choose an email service that supports Supabase’s SMTP integration or an appropriate Send Email Auth Hook. Supabase documents both approaches; Resend also documents its Supabase integration.
Use a sending identity controlled by the business, not a developer’s personal account. Verify the sending domain with the provider and add the SPF, DKIM and DMARC records it specifies. Consider a separate authentication subdomain so marketing-email reputation does not directly affect account-recovery messages.
Save the SMTP host, port, sender address and credentials in the intended project’s secure settings. Do not embed SMTP credentials in browser code or commit them to GitHub.
After enabling custom SMTP, review the project’s Authentication → Rate Limits configuration. Supabase’s documented initial custom-SMTP email limit is 30 per hour, which may need adjustment for a legitimate launch. Raising it does not remove other limits or your provider’s own sending restrictions.
3. Check the per-user cooldown and accidental repeat requests
A project-wide email cap and a per-user resend cooldown are separate. Supabase’s rate-limit documentation describes the limits for signup, OTP, password recovery and other Auth operations.
If the app sends multiple requests when a page loads, or lets users click “Resend” repeatedly without feedback, fix the application behavior as well as the provider configuration. Display a clear, non-revealing response and an appropriate wait state rather than encouraging frantic retries.
For a public signup endpoint, consider Supabase-supported CAPTCHA protection to reduce automated abuse. Configure it with the correct client token flow; do not treat a CAPTCHA checkbox as a substitute for server-side rate limits.
4. Repair links that arrive but do not work
If the email is delivered but sends the user to localhost, a preview hostname or the wrong route, the SMTP provider has done its job. Inspect the Site URL, Redirect URLs, the application’s requested return URL and the confirmation/reset handler.
Supabase’s redirect guide states that Site URL is the default destination when no redirect is supplied, and recommends exact production paths rather than broad wildcards. Custom email templates may also need the correct redirect variable.
A link that reaches your homepage but fails to establish a session is not a successful confirmation. Verify the callback exchange, cookies or session persistence, and access to a protected page.
If your specific issue is a Lovable preview login that fails only on the live domain, my production redirect troubleshooting guide covers that separate problem. This article is about email sending and the full email-based account journey.
A realistic incident: users exist but cannot activate accounts
Imagine a paid-membership app that has launched with 40 signup attempts. The dashboard shows some user records, yet support receives messages saying confirmation emails never arrived. The founder assumes the database is corrupt and asks for a rebuild.
A responsible investigation first checks whether those requests were rejected by the built-in sender, whether SMTP credentials and domain records are valid, whether the provider accepted the messages, and whether confirmation links return to the correct deployed app. The database may need no rebuild at all.
But the developer must also check what happened to users who attempted signup during the incident. Some may be unconfirmed, some may have completed registration through another method, and some may have retried. A recovery plan should not silently create duplicate accounts, mark everyone verified, or expose whether a particular email is registered.
This is the distinction between getting an email to send once and restoring a reliable production onboarding system.
What should you pay a developer to repair?
A basic SMTP configuration is often a small task. It should not be sold as a complete authentication rebuild. Conversely, a live application with broken signup, password reset, redirects, account state and missing monitoring may need a broader paid recovery engagement.
Ask for a quote based on deliverables rather than a vague “fix Supabase” promise:
| Scope | What a responsible engagement should deliver |
|---|---|
| Focused configuration fix | Verified sending domain, working SMTP handoff and an external-inbox test |
| Production Auth repair | Signup, confirmation, reset, resend, redirect and session tests, with errors handled safely |
| Broader product recovery | Affected-user reconciliation, abuse controls, monitoring, deployment rollback and owner handoff |
A production Auth recovery involving several broken journeys can justify a $1,000+ engineering engagement. That is a possible project scope, not a universal market price or a quote for changing one setting. If the only issue is a missing SMTP credential, the work should be scoped accordingly.
For AI-assisted applications, also inspect whether the code is pointing to the correct Supabase project and whether development and production configurations have been mixed. My AI-built app production checklist covers the wider release boundary.
Seven acceptance tests before calling the fix complete
- A new user outside the Supabase organization receives a confirmation email and can activate an account.
- An existing user can request a password reset, receive it and successfully sign in with the new password.
- Magic-link or email-OTP login works if the product offers it, without reusing expired links.
- The message links return to the correct HTTPS production domain, and the resulting session survives a page refresh.
- A bounced or rejected email can be identified in logs without exposing passwords, tokens or private customer information.
- Repeated requests produce sensible cooldown/error behavior; a resend button does not accidentally fire multiple Auth calls.
- The business owns the sending domain, provider account, Supabase project and deployment access, and has a documented recovery procedure.
Also test a normal existing-user login and a user with no permission to view another account’s records. An Auth email repair must not weaken authorization or row-level security.
When to hire instead of adding another prompt
If your app is still a private prototype, Supabase’s official setup instructions may be enough. If paying customers are locked out, signup has stopped working, or you cannot trace messages across Supabase, your provider and the deployed application, treat it as a production incident.
I work on AI-assisted MVPs and websites where authentication, deployment, permissions and account ownership must survive real users. Through my MVP development service, I can help scope a targeted Auth recovery rather than replacing a working product unnecessarily. Tell me what fails and which systems you use, without sharing credentials, and we can identify the smallest responsible repair.
