The symptom
A new user signs up, opens the confirmation email, clicks the link, and lands on a page that will not load, or on an old preview version of your app. They do not email you about it. They close the tab and forget your product exists. From your side, signups look oddly quiet and the few users who do arrive seem unusually determined. That pattern usually is not a marketing problem. It is an auth setting that still points at where the app was built instead of where it lives.
Why it happens
Supabase and Firebase both build auth links from a configured address, not from wherever your app happens to be deployed today. In Supabase, the Site URL and the redirect allowlist decide where confirmation, magic link, and password reset emails send people. AI builders set those values while the app runs on a preview domain, and nothing updates them when you connect your real domain. Firebase has the same failure through its authorized domains and action link settings. The app works in the builder, it works for the account you test with because you are often already logged in, and it quietly breaks for every brand new person.
There is a second layer that gets missed. Even when the link points at the right domain, the email itself often comes from a default shared sender with no SPF, DKIM, or DMARC records behind it. That mail lands in spam for a share of your signups, so those users never even see the broken link. Two different failures, one result: people who wanted in never got in.
Test it the way a stranger would
Use a fresh email address you have never signed up with, ideally on a different mail provider than your own. Sign up, wait for the confirmation email, and look at three things before you click: which address sent it, whether it landed in spam, and where the link actually points when you hover or long press it. Then click it and finish the whole journey, including logging out and using the password reset flow, which uses the same settings and breaks the same way. Test on your phone too, because most of your users will open that email there.
The fix
In Supabase, set the Site URL to your live domain and make sure the redirect allowlist contains your live domain and the exact paths your auth flow returns to, then remove preview and localhost entries you no longer need. In Firebase, check the authorized domains list and the email action settings. Set up a proper sending domain for auth mail, with SPF, DKIM, and DMARC records, so confirmation mail comes from your domain and lands in inboxes. Then repeat the stranger test from start to finish. Settings changes in a dashboard are the safe kind of fix, and this one is worth doing by hand rather than by prompt, because you can see every value as you change it.
Verify it: a brand new email address can sign up, confirm, log in, log out, and reset its password, with every link pointing at your live domain and no step touching a preview address or localhost.
FAQ
Why did signup work when I tested it myself?
You were probably already logged in, or your test account was created before the domain changed, or the builder preview still resolves for you. The failure only shows for a genuinely new account following the email link cold.
Is the preview domain in the link a security problem too?
It can be. Preview deployments often carry older code and looser settings, and sending real users there mixes test and production in ways that get hard to reason about. Production auth links should point at production, full stop.
My confirmation emails go to spam. Is that the same bug?
It is a different bug with the same outcome. Links pointing at the wrong place are a redirect setting. Spam placement is a sender reputation problem, fixed by sending from your own domain with SPF, DKIM, and DMARC set up.
Ground Crew note
This is check 03 on the free production audit. We walk the full signup, confirmation, login, and reset journey with a fresh account on every audit, because it is the failure founders are least likely to see themselves. Run the full checklist or request the free audit.