Matt Turley, Continuum. Updated November 5, 2026.
For founders whose users sign up and never receive the confirmation, magic link, password reset or receipt.
Either the email was never sent, or it was sent and filtered. Check your email provider's log first. A built-in test sender with limits, a sending domain without SPF and DKIM, a from-address on an unverified domain and an email API key missing in production are the usual causes. A delivered link that says "expired" often points to a link scanner.
Email fails in two different places. Sending fails when your app cannot hand the message to a provider, usually because of a missing key, an unverified domain or a provider limit. Delivery fails when the provider hands it to the recipient's mail server and that server decides it is spam or rejects it. The provider's log tells you which, and it is the first thing to open.
AI-built apps commonly use the auth provider's built-in email sender because it works on day one. That sender is meant for trying things out, and has low rate limits and restrictions. It fails in the first week of real signups.
Authentication for your sending domain (SPF, DKIM and DMARC) is no longer optional for reaching the big mailbox providers. Without it, even correct emails land in spam or are rejected.
How to tell Auth emails work for you and your team but not for new users, or stop after a handful of signups. The provider's documentation describes its default sender as limited and not for production.
The fix Configure your own SMTP or email API provider in the auth settings, with a verified domain, before launch.
How to tell Emails arrive in spam or bounce. The provider dashboard shows the domain as unverified, or a DNS check shows no SPF or DKIM record for the sending domain.
The fix Add the DNS records your provider gives you (SPF and DKIM), publish a DMARC policy, and send from an address on that domain.
How to tell No entry appears in the provider's log at all. The API key exists locally but not in production, or the call throws and the error is caught and ignored, so signup appears to succeed.
The fix Define the key in the production scope, and make a failed send visible: log it, alert on it and show the user a way to resend.
How to tell The email arrives and the button leads to localhost or to a preview URL. The confirmation redirect or Site URL is still the development value.
The fix Set the Site URL and the allowed redirects to the production domain, and send yourself a real email to click through.
How to tell The user says the link has expired or was already used the moment they click it. Some corporate mail systems open every link in a message to scan it, which uses up a single-use token.
The fix Land the user on a page that requires a click or a code entry before the token is redeemed, or use a one-time code instead of a link.
How to tell Delivery is mixed: some mailboxes receive it, others do not. A shared sending address, a no-reply sender with no reply path, or a burst of mail after a launch can all reduce reputation.
The fix Use a dedicated sending subdomain, keep messages plain and transactional, and ramp volume up rather than starting with a spike.
Setting up a custom sender and adding DNS records is a settings task that most founders can do in an afternoon by following the provider's guide. Bring us in if the configuration looks right and mail still goes missing, or if the sending code is tangled into a custom auth flow.
The Leak Check is free and tests the auth flow and other launch basics from the outside in under a minute. For the sending code and configuration behind the email, a Ship Check reads the codebase.
free Leak Check: Paste your live URL. It runs seven surface checks (reachability, SSL, auth flow, payment path, exposed secrets in the client bundle, Supabase exposure, broken links and performance) and returns a green, yellow or red for each. It is a surface scan, not a full security audit. Or: Get a Ship Check, $299.