Lovable emails going to spam: causes and fixes

As of October 12, 2026, when emails from a Lovable app go to spam or never arrive, the usual cause is the sender, not your code. The app is still using a default sender meant for testing, or it sends from a domain that has not proved it is allowed to send (no SPF, DKIM and DMARC records), so Gmail and Yahoo do not trust it. On your own Supabase project, the built-in sender only delivers to your own team, 2 emails an hour, so real customers get nothing at all. The fix is to send from your own verified domain: Lovable Emails on a paid Lovable Cloud plan, or custom SMTP in Supabase through a provider such as Resend, with the DNS records in place and a DMARC policy published.

This guide is for founders whose customers are missing sign-up confirmations, password resets, invites or receipts. It covers which sender your app uses, a diagnosis you can run yourself, and the fix. Platform facts come from the Lovable, Supabase, Resend, Google and Yahoo documentation listed under Sources. If you are setting up Resend from scratch, our guide to Lovable email with Resend covers the setup step by step; this page stays on the symptom.

Why do emails from my Lovable app go to spam or never arrive?

Inbox providers judge who sent an email and whether the sender can prove it. Most cases come down to one of six causes:

Which email sender is my Lovable app using?

It depends on your backend, so check this first. If your app runs on Lovable Cloud, Lovable's docs say free plans use the default Lovable Cloud Auth sender. Paid plans can switch on Lovable Emails, which sends sign-in emails and app emails from your own domain. Lovable then maintains SPF, DKIM and DMARC for you. To see which you have, open More, then Cloud, then Emails.

If your app is connected to its own Supabase project, Supabase sends the sign-in emails. Lovable's docs are clear that sign-in emails from your own domain through Lovable need Lovable Cloud, so on your own Supabase project you set the sender up in Supabase. Supabase's built-in sender is for testing only. Its docs say it is best effort, refuses to deliver to anyone outside your project's team, and is currently limited to 2 messages an hour. Other addresses fail with the error Email address not authorized. That is why it works when you test it and fails for customers.

How do I find out why emails are not arriving?

Work through these in order.

1. 01Test as a customerOn your published site, sign up with a Gmail address that is not on your Lovable or Supabase team. Check the inbox and the spam folder.
2. 02Read the auth logsOn Lovable Cloud, open More, then Cloud, then Logs, and choose Authentication logs. On your own Supabase project, open Logs and select Auth under Log Type. Look for Email address not authorized or rate limit errors around the time of the sign-up.
3. 03Check the email provider's logWith Lovable Emails, open More, then Cloud, then Emails, then Analytics and logs, which lists each email's recipient, status and any error. With Resend, open the Emails dashboard. If the email is not in the provider's log at all, it never left your app.
4. 04Read the authentication results in GmailOpen a test email in Gmail on a computer. Next to Reply, click More, then Show original. Find the Authentication-Results line and look for spf=pass, dkim=pass and dmarc=pass. A fail, or no DKIM result at all, points to missing or wrong DNS records.
5. 05Check the DNS recordsIn Resend, open your domain's Records tab and check it is verified. With Lovable Emails, the domain must say Verified. Offline means a required record was changed or removed after setup.

Here is how to read what you found:

What do Gmail and Yahoo require from senders?

Proof of who you are and a low complaint rate. Google's email sender guidelines, in force since February 1, 2024, require every sender to personal Gmail accounts to set up SPF or DKIM, keep valid forward and reverse DNS, send over TLS and keep the spam rate in Google's Postmaster Tools below 0.3%. Google advises staying below 0.1%. Senders of more than 5,000 messages a day to Gmail must also use both SPF and DKIM, publish DMARC, align the From domain with the SPF or DKIM domain, and offer one-click unsubscribe on marketing mail.

Yahoo's sender hub sets close to the same rules: SPF or DKIM and a spam rate below 0.3% for everyone, and for bulk senders both records, a DMARC policy of at least p=none that passes, and unsubscribes honored within 2 days. A young app is rarely a bulk sender, but the bulk rules are a few DNS records, so set them up now.

In plain terms: SPF is a public list of servers allowed to send for your domain. DKIM is a signature on each email that proves it came from your domain and was not changed. DMARC tells inbox providers what to do with mail that fails both, and asks them to send you reports.

Why shouldn't my app send from a Gmail address?

Only a domain's owner can publish its SPF, DKIM and DMARC records, and Google owns gmail.com, so an app sending as [email protected] cannot pass those checks. Google's sender guidelines say not to impersonate Gmail From headers. Resend's shared test sender, [email protected], only delivers to your own account address; to reach anyone else you must verify a domain you own. Send from a subdomain of a domain you own.

How do you fix emails going to spam?

1. 01Choose a real senderOn Lovable Cloud with a paid plan, set up Lovable Emails under More, then Cloud, then Emails. On your own Supabase project, open Authentication, then SMTP settings, and enter the details from a provider such as Resend. Our Resend guide has the exact settings. Keep the provider's API key server-side, as a secret, never in browser code.
2. 02Send from a subdomain you verifiedSupabase suggests a separate subdomain for sign-in emails, such as auth.yourdomain.com, and another for marketing. Resend recommends subdomains too, so each keeps its own reputation.
3. 03Add the DNS records exactlyCopy your provider's records into your DNS exactly. Resend says verification often finishes within 15 minutes but DNS can take up to 72 hours. On Cloudflare, turn off proxying for Resend's CNAME records. For Lovable Emails, add the NS records inside your domain's DNS zone: Lovable warns that replacing the nameservers for your whole domain takes your site and email offline, and some providers, such as Hostinger and Wix, cannot hold these records.
4. 04Publish DMARC, starting gentlyResend's example starting record is a TXT record at _dmarc.yourdomain.com reading v=DMARC1; p=none; rua=mailto: followed by an address that receives reports. Once the reports show all your real mail passing, move to p=quarantine, then p=reject.
5. 05Raise the sending limitSupabase starts custom SMTP at 30 messages an hour, which you can change on its Rate Limits page. On Lovable Cloud, the hourly limit sits under Advanced in the email settings; Lovable says to set up your own sender before raising it. Lovable Emails on the Pro plan allows 500 sign-in emails and 100 app emails an hour.
6. 06Test again with Show originalSend a sign-up and a password reset to a Gmail address outside your team and confirm all three say pass.

Then give it time. Lovable's docs say a new domain typically needs a few weeks to improve and a few months to stabilize, and Google advises starting with low volume and avoiding sudden spikes. Our launch checklist for US founders puts email in its place among the other launch tasks.

Can the email content or links cause spam problems?

Yes. Supabase's advice for sign-in emails is to keep them plain: no promotions, few links or images, a template different from your marketing email, and short subject lines with few or no emojis. Google says not to mix message types, such as promotions in a receipt, or hide content with HTML or CSS. Lovable suggests avoiding all-caps subject lines and keeping links on your sending domain.

Two link problems catch people:

• Click tracking. Supabase warns that email tracking rewrites links so they do not work as expected, and recommends turning it off for sign-in emails.
• Link scanners. Supabase notes that some email providers' security features open links in incoming mail before the person does. The confirmation link is used up, and your customer sees Token has expired or is invalid. Supabase suggests sending a one-time code instead, or linking to a page with a button that completes the step.

If a confirmation link sends people to the wrong address entirely, that is a redirect setting, not deliverability. Our guide to Google login not working covers redirect URLs, which apply to email links too.

What can a Lovable prompt fix, and what can it not?

A prompt can change what your emails say and how sign-in works. A useful one: "Rewrite our sign-up confirmation, password reset and invite email templates to be plain and short: one sentence of context, one link, no images, no promotions, a short subject line without emojis. Use our product name as the sender name. Do not change any other part of sign-in."

A prompt cannot add DNS records, verify your domain in Resend, or repair a sender's reputation. Lovable's docs say auth settings for a connected Supabase project live in Supabase, not in Lovable, so those steps are yours or your engineer's.

When should you stop prompting and get help?

Get an engineer when:

• Customers cannot sign up or reset their passwords right now and you are losing them.
• Receipts or invoices are not reaching paying customers.
• You changed DNS and your website or business email went down.
• The records pass in Show original, but mail still lands in spam weeks later.
• You have fixed the same email problem three times and it keeps coming back.

Our vibe-coding rescue service finds the cause, fixes the sender and records, and tests every email on the live app. For a wider view first, the free production-readiness check scores your app and names its biggest risks. Ongoing plans, with every change reviewed and tested, are on our pricing page.

Sources

All checked on October 12, 2026.

• Lovable documentation: Email authentication for your app, on emails landing in spam, the hourly sending limit and unconfirmed users (docs.lovable.dev/features/email-auth).
• Lovable documentation: Send branded emails from your own domain, on Lovable Emails, DNS setup, limits, logs and spam (docs.lovable.dev/features/custom-emails).
• Lovable documentation: Logs, on authentication logs (docs.lovable.dev/features/logs).
• Lovable documentation: Connect to Supabase, on sign-in emails needing Lovable Cloud and auth settings living in Supabase (docs.lovable.dev/integrations/supabase).
• Supabase documentation: Send emails with custom SMTP, on the built-in sender, custom SMTP, rate limits and content (supabase.com/docs/guides/auth/auth-smtp).
• Supabase documentation: Email templates, on link prefetching, one-time codes and email tracking (supabase.com/docs/guides/auth/auth-email-templates).
• Supabase documentation: Logs, on auth logs (supabase.com/docs/guides/telemetry/logs).
• Resend documentation: Domains, Add a domain and DMARC, on subdomains, verification time, Cloudflare proxying and the starting DMARC record (resend.com/docs/dashboard/domains/introduction; resend.com/docs/add-a-domain; resend.com/docs/dashboard/domains/dmarc).
• Resend documentation: Managing emails, on email statuses such as bounced, complained and suppressed (resend.com/docs/dashboard/emails/manage-emails).
• Resend documentation: Send emails using Supabase with SMTP, and 403 error using resend.dev domain (resend.com/docs/send-with-supabase-smtp; resend.com/docs/knowledge-base/403-error-resend-dev-domain).
• Google: Email sender guidelines, on requirements for all senders and bulk senders, Gmail From headers, content and sending volume (support.google.com/mail/answer/81126).
• Google: Check if your Gmail message is authenticated, and Set up DKIM, on Show original and the Authentication-Results header (support.google.com/mail/answer/180707; knowledge.workspace.google.com/admin/security/set-up-dkim).
• Yahoo: Sender best practices, on requirements for all senders and bulk senders (senders.yahooinc.com/best-practices).