The app says the email was sent. The customer sees nothing.
A new customer signs up for your application and waits for their confirmation email. Nothing arrives. Another customer requests a password reset and experiences the same problem. Your application may display a success message, yet neither user can complete the process. Before changing the login system, you need to find out whether the email was generated, accepted, delivered, or blocked.
Consider a hypothetical customer portal built with an AI development tool and Supabase authentication. The founder successfully tested registration with their own email address, but new customers report missing confirmation emails. One possible reason is a restricted development email configuration. Another is incorrect email-provider setup, rate limiting, suppression after previous delivery failures, or messages landing in spam. A separate issue could make a delivered reset link invalid. These are different failures and require different investigations.
Email delivery is a chain, not a single function
An authentication email passes through several stages. The application triggers a signup or reset request. The authentication service processes it and hands it to an email provider, typically through SMTP or an email-sending hook. The provider then attempts delivery to the recipient's mail server, which decides whether to accept, filter, or reject the message. The customer must finally receive and use a valid link before its token expires. A successful authentication request does not guarantee inbox placement.
For Supabase specifically, the custom SMTP documentation describes restrictions on its built-in email service and recommends custom email delivery for production use. Its email troubleshooting guide recommends starting with Auth logs and then checking provider delivery records. Additional checks include bounce and suppression lists, sender-domain settings such as SPF, DKIM, and DMARC, redirect allowlists, and token expiry. Removing email verification is not an appropriate production fix for delivery failures.
When should a founder bring in an engineer?
If customers cannot complete registration or recover their accounts, the problem directly affects onboarding and retention. Someone needs to trace the complete authentication and delivery workflow rather than repeatedly rewriting the signup screen.
DitchNow, based in Haarlem, Netherlands, helps founders diagnose and improve authentication, email delivery, and other production-critical integrations.
Book a founder call with DitchNow.
Five prompts to investigate missing authentication emails
Before you begin: Use these prompts one at a time in the same project conversation. Give the assistant access only to approved project materials, use synthetic test data, and review its findings before approving changes.
1. Map
Inspect my application's signup, email confirmation, and password reset architecture. Map every stage from frontend trigger to authentication service, SMTP provider or send-email hook, delivery handling, and verification-link destination. Identify relevant configuration, rate limits, templates, redirect allowlists, and token-expiry settings. Reference project files and available documentation. Clearly mark provider settings you cannot inspect. Do not modify anything.
2. Audit
Perform a read-only audit using authorized, sanitized Auth logs and available email-provider delivery events. Distinguish trigger failures, provider rejection, rate limits, suppressed addresses, bounced emails, spam filtering, and invalid or expired links. Check SMTP configuration, SPF, DKIM, DMARC, redirects, and email template errors. Report confirmed findings, possible causes, supporting evidence, and unknowns. Never display credentials or private email contents.
3. Plan
Propose a targeted implementation plan for the confirmed problems. Include appropriate SMTP or send-email hook configuration, sender-domain authentication, rate-limit handling, safe error messages, template validation, redirect allowlists, token-expiry behavior, and observability. Preserve email verification and existing account security. Define acceptance criteria for signup, confirmation, password reset, and failure scenarios.
4. Challenge
Critically review the plan for overlooked delivery and authentication issues. Design isolated tests using approved test inboxes and synthetic user accounts. Include provider rejection, delayed delivery, expired tokens, invalid redirects, repeated reset requests, and suppression behavior where safely reproducible. Explain which checks require the email provider and what cannot be guaranteed about inbox placement.
5. Implement
I approve these changes: [APPROVED SCOPE]. Apply them only to an isolated test environment with authorized test inboxes or an email sandbox. Verify the signup and reset flows, inspect sanitized delivery events, and confirm that confirmation links behave correctly. Report configuration changes, test outcomes, remaining unknowns, and production-release requirements. Do not email real customers, expose SMTP secrets, or deploy automatically.