arrow_back Back to Blog
lovable emaillovablesupabaseproduction

Lovable Email: Why Your Auth Emails Fail

·

The most common Lovable email complaint we get isn’t about design or templates. It’s “users sign up and the verification email never shows up.” And the annoying part is that the cause depends on which backend your app runs on, because “email” in Lovable means two different systems depending on whether you’re on Lovable Cloud or on your own Supabase project.

So first, figure out which one you have. If your project settings show Cloud and you never created a Supabase account, you’re on Lovable Cloud. If you connected a Supabase project yourself (or migrated to one), your auth emails go through Supabase.

Your own Supabase: the 2 emails per hour wall

This one catches almost everybody who moves off Lovable Cloud, and it’s brutal because nothing tells you about it until launch day.

Supabase ships with a built-in email sender so you can test auth without setting anything up. It has two restrictions that matter. It only sends to email addresses that belong to your Supabase organization’s team. Anyone else gets Email address not authorized. And it’s rate limited to 2 messages per hour for the whole project. Not per user. Per project.

You test signup with your own address, it works, you ship. Then real people sign up and get nothing.

We had a client launch a waitlist-to-beta flow on a Tuesday morning. Around 40 signups in the first hour, from a newsletter mention. Two of them got a confirmation email. The rest sat on “check your inbox” and a few emailed support asking if the product was a scam. The auth logs in the Supabase dashboard had the answer the whole time: over_email_send_rate_limit, over and over. The fix took 15 minutes. The damage to that first impression didn’t get fixed.

The fix is custom SMTP. In the Supabase dashboard go to Authentication, then the SMTP settings, and plug in a real provider. Supabase’s own docs list Resend, AWS SES, Postmark, SendGrid, ZeptoMail and Brevo. We use Resend for most Lovable apps because the setup is short:

  • Host smtp.resend.com, port 465
  • Username resend, password is your Resend API key
  • Sender something like no-reply@mail.yourstartup.com

Then check the auth rate limits page, because the default limit there is still conservative after you switch. Raise it to something that matches a real launch.

Postmark has better deliverability reputation if you care a lot. SES is the cheapest at scale and the most painful to get out of sandbox mode. I’d skip SendGrid for a new project. The dashboard is a maze for something that sends password resets.

Lovable Cloud: it works, until you want your own domain

On Lovable Cloud, auth emails go out from the default Lovable Cloud Auth sender out of the box. Signup confirmation, password reset, magic link, invite, email change and reauthentication all have built-in templates. For a prototype that’s fine.

The moment you want emails from your own domain, there are a few things to know:

It’s paid plans only. Email domains aren’t available on the free tier.

Setup isn’t the usual “add three DNS records” flow. Lovable creates a sender subdomain like notify.yourdomain.com and asks you to add NS records that delegate that subdomain to Lovable’s nameservers, plus a TXT for verification. Lovable then handles SPF, DKIM and DMARC itself. That’s convenient. It also means Lovable controls the DNS for that subdomain, which matters if you ever leave. Plan to redo email from scratch when you migrate.

The quotas are generous. Each paid workspace gets 50,000 transactional emails a month, and extra is 4 credits per 1,000. Hourly caps on Pro are 500 auth emails and 100 app emails. Business is 3,000 and 300.

And there are restrictions that will bite some people. Only transactional mail is allowed, no marketing or newsletters. App emails get an unsubscribe link added automatically and you can’t remove it. The template’s outer background has to stay white (#ffffff), which is a weird rule to discover after you’ve built a dark-mode email.

If you need a weekly digest or anything promotional, that has to go through a separate provider anyway.

Different problem, same symptom from the user’s point of view. The email arrives, they click, and the browser opens http://localhost:3000/#access_token=... and shows nothing.

That’s the Site URL in your Supabase auth settings (Authentication, URL Configuration). It’s still set to whatever it was during development. Set it to your real domain, and add your custom domain and your lovable.app URL to the Redirect URLs list. If you use preview URLs, add those too with a wildcard. We see this on maybe a third of the Supabase projects we take over.

This one is sneaky. The user clicks the link once and gets told it’s expired.

Corporate inboxes (Outlook with Safe Links, Mimecast, a lot of security gateways) open every link in an email before the human does, to scan it. Magic links and confirmation links are single use. The scanner uses it, the human gets the error.

You can’t fix the scanner. You can change the flow: send a 6-digit code instead of a link (Supabase supports email OTP with the {{ .Token }} variable in the template), or make the link open a page with a “Confirm” button that does the actual verification on click. If your users are mostly B2B, do this before launch, not after the first angry ticket.

Spam folder

If emails arrive but land in spam, it’s almost always DNS. Gmail and Yahoo tightened their sender rules in 2024: SPF and DKIM on the sending domain, plus a DMARC record once you send any real volume. They’re not lenient about it.

Send from a subdomain, not your root. When we set up our own outreach mail we put Resend on mail. and left the root domain’s MX, SPF and DMARC alone, because the root already belonged to our regular inbox provider. Mixing two providers on one root SPF record is how people end up with permerror and every email failing silently. A subdomain keeps them separate, and a bad week of bounces on one won’t hurt the other.

Also, stop sending from no-reply@. Not for deliverability, it barely matters there. It matters because users reply to “verify your email” asking for help, and those replies vanish.

Auth email is one of those boring pieces that decides whether launch day goes well. It’s part of what we check when we take a Lovable app to production, and it’s on the list for every Lovable Cloud to Supabase migration, since moving backends means rebuilding your email setup. If your verification emails are vanishing right now, send us a message.