# Lovable email with Resend: transactional email that arrives

Source: https://www.plutonapps.com/resources/lovable-resend-email

Published 2026-10-02. By Plutonapps Engineering.

Lovable's Resend connector gets the first email out. Here is what makes the hundredth arrive: a verified domain, your own auth sender, idempotent retries and bounce handling.

As of 2 October 2026, reliable email from a Lovable app with Resend has four parts. Send from a subdomain you have verified in Resend, with SPF, DKIM and DMARC records in place. Send sign-up and password-reset emails from your own domain, not the default sender. Give every send an idempotency key so a retry never emails twice. Listen for bounces and complaints so you stop mailing addresses that fail. Lovable's Resend connector gets the first email out. The other parts are what make the hundredth one arrive.

This guide covers each part in order, for a founder deciding what their app needs. Platform facts come from Lovable, Resend, Supabase, Google and Yahoo documentation checked on 2 October 2026, listed under Sources.

## Should you use Lovable's Resend connector or your own edge function?

Lovable's own docs point standard transactional email, such as sign-up confirmations, password resets and receipts, to its built-in Lovable Emails. They suggest the Resend connector when you need marketing email or Resend's delivery tooling, or already send through Resend. If Resend is your choice, start with the connector and move to code you control when email starts to matter.

The connector sends email through your own Resend account, from a domain you have verified in Resend. You paste in a Resend API key; a Sending access key is enough for an app that only sends. One connection is shared across every project linked to it. Resend's shared test sender, onboarding@resend.dev, only delivers to the Resend account owner, so real users need your verified domain.

Lovable's docs also list what the connector cannot do. It does not set up DNS or verify domains. It cannot receive webhooks. It does not support a separate Resend login per user. Those gaps are fine for a first release. They matter once you need to know whether an email bounced.

Lovable Emails runs on paid plans and needs no Resend account. Lovable sets up SPF, DKIM and DMARC itself. It sends transactional email only, not marketing, and caps sending per hour: on the Pro plan, 100 app emails and 500 sign-in emails. If you use it, most of the domain work below is done for you.

| Option | Good for | What it leaves to you |
| --- | --- | --- |
| Lovable Resend connector | Getting transactional email working fast | Domain setup in Resend, bounce handling, retries |
| Your own edge function calling Resend | Control over retries, keys and logging | Writing and testing the function, storing the key as a secret |
| Supabase custom SMTP pointed at Resend | Sign-up, reset and invite emails when the app uses its own Supabase project | Domain setup, Supabase rate limits |
| Lovable Emails (paid plans) | Sign-in and app emails with no email vendor | Its hourly limits; no marketing email |

If you use Resend, treat the API key like a password. Lovable's docs say so too. It belongs in a server-side secret, never in browser code, where anyone can read it.

## How do you verify your domain so email arrives?

Add a subdomain in Resend, copy the records it generates into your DNS, and add a DMARC record. Resend recommends sending from a subdomain such as updates.example.com rather than your root domain, to isolate your sending reputation, with one subdomain per kind of mail. Supabase suggests the same for sign-in mail, such as auth.example.com.

Resend generates two kinds of record, as TXT plus MX or CNAME entries:

- SPF says which servers may send for your domain.
- DKIM signs each message, so receivers can check it was not changed and really came from you.

Once the domain verifies, Resend's next step is a DMARC record. Resend calls it important for deliverability, and it protects against spoofing. Resend notes that a domain often verifies within 15 minutes, while DNS changes can take up to 72 hours to spread. Copy and paste the records exactly as Resend generated them. If your DNS is on Cloudflare, turn off proxying for Resend's CNAME records, or verification will not complete.

## What do Gmail and Yahoo require from senders?

Authentication, a low spam rate and, for marketing mail, one-click unsubscribe. Google's sender guidelines, in force since February 2024, require every sender to Gmail to set up SPF or DKIM, keep valid forward and reverse DNS, use TLS and keep spam rates in Postmaster Tools below 0.3%. Google advises keeping the rate below 0.10%.

Senders of more than 5,000 messages a day to Gmail accounts must also use both SPF and DKIM, publish DMARC, and align the From domain with the SPF or DKIM domain. Their marketing messages need one-click unsubscribe and a visible unsubscribe link.

Yahoo's rules are close. All senders need SPF or DKIM and a spam rate below 0.3%. Bulk senders need both, a DMARC policy of at least p=none that passes, one-click unsubscribe and unsubscribes honored within 2 days.

Until you send more than 5,000 emails a day to Gmail, Google's bulk rules do not apply. Set up the bulk-sender records anyway. They are a few DNS entries, and you will not have to add them in a hurry later.

## How do sign-up and password-reset emails reach users?

Through your own sender, not the default one. Which route you have depends on your backend. On Lovable Cloud, sign-in emails go through Cloud Auth: Lovable's default sender on free plans, or Lovable Emails from your own domain on paid plans. Lovable's docs describe no way to send them through Resend. On your own Supabase project, Supabase's rules apply.

There, Supabase's built-in email service is best-effort only and meant for non-production use. It sends 2 messages an hour, and only to your project's team members. A real customer signing up gets nothing.

Supabase gives you two ways out:

- Custom SMTP: in Supabase Auth's SMTP settings, use host smtp.resend.com, port 465, user name resend and your Resend API key as the password. Supabase then applies a starting limit of 30 messages an hour, which you can raise in its rate-limit settings.
- The Send Email Hook: Supabase calls your function instead of sending mail itself, passing the type of email, such as signup, recovery, invite or magiclink. Your function sends it through Resend's API. SMTP is not used while the hook is on.

SMTP is the quicker fix. The hook gives you full control of templates and logging, at the cost of code you must test. Our guide to [Lovable authentication and user roles](https://www.plutonapps.com/resources/lovable-authentication-user-roles) covers the sign-in side of the same flow.

## Why does my Lovable app show an error verifying email?

Check four causes, each with its own test:

1. **The confirmation link points to the wrong place** Lovable's troubleshooting guide covers sign-in that works in preview but fails on the published app. The published URL or custom domain is probably missing from the project's redirect URLs. Add every live address.
2. **The email never left** On your own Supabase project, the default sender only reaches your team. On Lovable Cloud, a burst of sign-ups can hit the project's hourly email limit, which Lovable's docs name as the first thing to check. Use your own sender and check the limit.
3. **The link expired** Lovable's docs say signing in again does not resend an expired confirmation. The person signs up again with the same address, or you create the account for them, which confirms it automatically.
4. **The email went to spam** Lovable's docs note that email from a new domain often lands there. Verify the domain and send from your own subdomain. A new domain needs time to build a reputation.

Test on the live site, with an address outside your team. The redirect problem only shows on the published app, and a team-only sender looks fine to you.

## How do you stop retries from sending the same email twice?

Give each email a key that names what it is for. Resend accepts an Idempotency-Key header of up to 256 characters. If the same key arrives again within 24 hours, Resend returns the first response and does not send the email again. If the key is reused with a different message, Resend refuses the request with a 409 error. Resend suggests keys shaped like an event and an ID, such as welcome-user/123456789.

Retries are not optional. Resend's API allows 10 requests a second per team by default, across all your API keys. Above that it answers 429, with a retry-after header saying how long to wait. A burst of sign-ups or a nightly digest can hit that limit. Resend's advice is a queue or fewer requests at once. So put email on a queue, run it as a [background job](https://www.plutonapps.com/resources/what-is-a-background-job), pace it under the limit and retry with the same key. That is [idempotency](https://www.plutonapps.com/resources/what-is-idempotency): the same request has the same effect however often it runs.

Note the 24-hour window. A retry that comes back two days later is not protected by Resend's key. Record in your own database that an email was sent, and check that record before sending.

## How do you handle bounces and spam complaints?

Listen for them with a webhook and stop mailing the address. Resend sends events for delivered, bounced, complained and delayed email to an endpoint you choose. A [webhook](https://www.plutonapps.com/resources/what-is-a-webhook) is how your app hears about them. Lovable's connector cannot receive webhooks, so this needs an endpoint of your own, such as an edge function. Lovable's docs name the other option: read email status from Resend's API.

Three rules make the endpoint safe:

- Verify the signature on every request, against the raw request body as Resend's docs describe, so nobody can fake a bounce.
- Expect repeats. Resend retries a failed delivery on a schedule from immediately to 10 hours apart, so the same event can arrive more than once. Handle it so a repeat changes nothing.
- Act on it. Mark a bounced or complained address as do-not-send, and check that mark before every send.

Complaints matter most. A complaint is a recipient marking your email as spam, which is what the Gmail and Yahoo spam rates measure. An address that complained should never get mail from you again.

## How do you test email without hurting your reputation?

Use Resend's test addresses, never made-up ones. Resend provides delivered@resend.dev, bounced@resend.dev, complained@resend.dev and suppressed@resend.dev, which simulate each outcome. Resend blocks addresses at domains like example.com and test.com, because they are not built to receive mail and bounces hurt your reputation.

A useful test run covers four paths:

- Sign up, confirm and reset a password on the live site, with a real inbox you own.
- Send to the bounced and complained test addresses, and check your webhook marks them.
- Send the same email twice with the same idempotency key, and check only one arrives.
- Send a burst larger than the rate limit, and check every email arrives once.

Keep a staging copy of the app with its own sending subdomain, so tests never touch the domain your customers see. Lovable lets you create separate Resend connections with different API keys for exactly this.

## What does this look like in a production app?

Looph is customer-feedback software its founder shaped in Lovable, and its whole promise is that people hear back. When our engineers measured the email pipeline, 23 notifications pointed at templates that did not exist, and no invitation had ever reached anyone. Now one typed pipeline carries every notification, with email sent through Resend and an idempotency key on each event. Email leaves through a queue in batches of 100, paced under the provider's limit. On staging, one email now takes a median of 6 seconds end to end, down from about 100. The details are on the [Looph case study](https://www.plutonapps.com/work/looph).

The product the founder designed did not change. What happens after someone clicks send did. The wider checklist is in our guide to [taking a Lovable app to production](https://www.plutonapps.com/guides/lovable-app-to-production).

> **Email that keeps arriving** You keep prompting in Lovable, and our Product Owner and engineers turn each version into the live product. Domain records, sign-in emails, retries and bounce handling are ordinary changes, and Starter does not cap changes, within fair use. Every change is code-reviewed and security-checked, we watch uptime, errors and performance around the clock, and production releases go out twice a week.

Starter is $2,999 a month paid annually, or $3,999 month to month; Growth is custom. See [pricing](https://www.plutonapps.com/pricing). To see where your app stands first, take the free [production-readiness check](https://www.plutonapps.com/tools/production-readiness-check): 19 questions, a score out of 100 and your three biggest risks.

## Sources

All checked on 2 October 2026. Looph facts are as our case study states them.

- Lovable documentation: Connect your app to Resend, on what the connector does and does not do (docs.lovable.dev/integrations/resend).
- Lovable documentation: Send branded emails from your own domain, on Lovable Emails, its plans and hourly limits (docs.lovable.dev/features/custom-emails).
- Lovable documentation: Email authentication for your app, on redirect URLs, sending limits and unconfirmed users (docs.lovable.dev/features/email-auth).
- Resend documentation: Verified domains, on sending from subdomains (resend.com/docs/dashboard/domains/introduction).
- Resend documentation: Add and verify a domain, on SPF, DKIM, DMARC and verification time (resend.com/docs/add-a-domain).
- Resend documentation: Idempotency keys (resend.com/docs/dashboard/emails/idempotency-keys).
- Resend documentation: Usage limits, on the API rate limit (resend.com/docs/api-reference/rate-limit).
- Resend documentation: Webhooks, Event types, Verify webhook requests, and Retries and replays (resend.com/docs/webhooks/introduction; resend.com/docs/webhooks/event-types; resend.com/docs/webhooks/verify-webhooks-requests; resend.com/docs/webhooks/retries-and-replays).
- Resend documentation: Send emails using Supabase with SMTP, and test email addresses (resend.com/docs/send-with-supabase-smtp; resend.com/docs/knowledge-base/what-email-addresses-to-use-for-testing).
- Supabase documentation: Send emails with custom SMTP (supabase.com/docs/guides/auth/auth-smtp).
- Supabase documentation: Send Email Hook (supabase.com/docs/guides/auth/auth-hooks/send-email-hook).
- Google: Email sender guidelines (support.google.com/mail/answer/81126).
- Yahoo: Sender best practices (senders.yahooinc.com/best-practices).
- Case-study facts: our Looph case study, as published on this site.

## Frequently asked questions

### Does Lovable have a Resend integration?

Yes. Lovable's Resend connector sends email through your own Resend account from a domain you verified in Resend. It does not set up DNS, verify domains or receive webhooks, so those stay with you. For standard sign-up and reset emails, Lovable points you to its built-in Lovable Emails.

### Why are my Supabase confirmation emails not arriving?

On your own Supabase project, the default sender is for non-production use. It sends 2 messages an hour and only to your project's team members. Set up custom SMTP with a provider such as Resend, or a Send Email Hook.

### Do I need SPF, DKIM and DMARC?

Gmail and Yahoo require SPF or DKIM from every sender, and both plus DMARC from bulk senders. Google draws that line at more than 5,000 messages a day to Gmail. Setting all three up from the start costs nothing and protects deliverability as you grow.

### How do I stop an email from being sent twice?

Send each email with an idempotency key that names its purpose. Resend will not resend a request with the same key within 24 hours. For longer protection, record each send in your own database and check it first.

### What should I use to test email sending?

Resend's test addresses, which simulate delivery, bounces, complaints and suppression. Avoid made-up addresses at domains like example.com, which Resend blocks and which harm your sending reputation.