Lovable confirmation email not receiving? What to check before a user emails you

FirstUser — the AI test user for Lovable, Bolt and Cursor apps — opens the published URL, signs up with a generated identity, and tries email confirmation when a disposable inbox can see the message. It then logs in and opens checkout. This page is the checklist. FirstUser is how you re-check the live path after you change settings.

You usually test with your own email, the editor preview, or an account you created with Add user. Lovable’s authentication docs say accounts created with Add user → Create new user are confirmed automatically. That is not the path a stranger takes. With auto-confirm off, signup sends a confirmation email and the person must verify the address before they can sign in. By default those emails come from a generic sender.

Use a fresh email address on the published site (your custom domain or the published lovable.app URL), not only the editor preview. Lovable’s email-auth troubleshooting starts in the spam folder: emails from new domains often land there.

If many people signed up in a short window and confirmations stopped, check the project’s rate limit for sending emails. Lovable puts that limit under Advanced in the email settings. To raise it, set up email sending first, either managed email or a verified custom domain.

If sign-in works in the preview and fails on the published app or a custom domain, Lovable’s auth docs say the Site URL and redirect URLs are usually the reason. On the built-in backend, publishing sets the Site URL to the published lovable.app address, and connecting a custom domain adds it to the redirect URLs. A Site URL you set yourself stays as you left it. An app on your own Supabase project does not get those updates; add the live addresses in that project’s auth settings. You can ask Lovable in the project chat, or set them under More → Users → Settings → Advanced → Redirect URLs.

If someone is stuck unconfirmed, signing in again does not resend the confirmation email. Lovable says signing up again with the same address can send a new one. You can also confirm the account yourself with Add user → Create new user. Those accounts are confirmed automatically.

For live traffic, Lovable’s docs say you can send signup confirmations, password resets, invites, and magic links from your own domain under More → Emails. Auto-confirm is convenient while you are building, because nobody has to open an inbox. For a live app, Lovable says leaving confirmation on means each account belongs to an address the person owns. With auto-confirm on, signup never sends that email, so you are not testing the mail path.

After a change, open the published URL in a private window and sign up with a brand-new address. Open the message and use the confirmation link. Then log out and log in. Repeat after the next publish. An uptime check only sees that the homepage returns a response. It does not submit the form or wait for mail.

FirstUser does not install an SDK and does not connect to Lovable. You paste the public URL. The run screenshots the landing page, submits a generated identity, and confirms email when a disposable inbox can see the message, or when you fill Test-account email domain on the free test with a domain you can read. It logs in, tries one named first action if you set one, then looks for pricing or checkout. Each step is pass, fail, or skipped, with a screenshot. A failure includes a short diagnosis and a fix prompt you can paste back into the builder.

Captchas, unusual widgets, and login that only works through another identity provider often fail. Local and private URLs are blocked in production. FirstUser does not publish a failure rate for Lovable apps. The free signup test is one report and does not ask for a card. Paid plans are Starter at $19 a month (1 app, daily), Pro at $49 (5 apps, daily checks now, hourly coming soon, and a deploy hook), and Team at $99 (20 apps, the same daily checks, deploy hooks, and 5 seats). A Pro or Team deploy hook reruns the test after you republish.