Lovable email: the DNS records and DMARC for your domain

Lovable can send your app's sign-up and password emails from your own domain, and it sets up SPF and DKIM for you. The DMARC record on your root domain is the part you check yourself.

1. Find out which service sends your app's email. Open More, then Emails, in your project. A domain listed there means Lovable sends the mail itself. If your code calls Resend through the connector, Resend sends it.
2. Add the records Lovable shows you. A domain registered through Lovable that uses its nameservers skips this step. Lovable sets up its DNS and sends from the domain itself. For most other domains, clicking Set up domain opens a window that asks you to sign in to your DNS provider and adds the records there. To add them yourself, choose Go to our manual setup at the bottom of it. You get a TXT record that verifies the domain and NS records for the sending subdomain, which is notify unless you changed it. Add them inside your DNS zone, and leave your domain's nameservers at the registrar alone.
3. Check the sending domain's records, then send yourself a test email.
4. Keep one DMARC record on your root domain, with your own report address in it.

On the free plan, Lovable sends sign-in emails from its own default sender, so there's nothing to set up on your domain.

The notify subdomain

Once the NS records are in place, Lovable's nameservers answer for the sending subdomain. According to Lovable's custom email docs, Lovable then creates the records there and keeps them up to date, so you never edit them.

Lovable's docs list Hostinger and Wix as DNS hosts that can't hold NS records on a subdomain. Lovable accepts no TXT, CNAME or MX record in their place. You can copy every existing record to a host that can, such as Cloudflare, then switch to its nameservers and keep the domain at your registrar.

Check the NS records with this lookup.

It should return the nameservers Lovable showed you. Domains using Lovable's emails that we looked up in November 2026 had nameservers such as ns3.lovable.cloud and ns4.lovable.cloud, and Mailgun in the subdomain's SPF record. Some also had a DMARC record on the subdomain:

Enter notify.example.com in the free SPF checker to read its SPF record.

Show as sent from @yourdomain.com

With this setting off, your emails come from an address like noreply@notify.example.com. Receivers apply the subdomain's DMARC record to them, or your root domain's record if the subdomain has none.

With it on, the From address ends in @example.com and Lovable still sends through the subdomain. DMARC counts a subdomain as a match for its root domain unless the record sets strict alignment, so the mail can still pass. Receivers then apply the DMARC record on your root domain.

Lovable's manual setup gives you a _dmarc TXT record for the root domain when this setting is on. If your domain already had one, you'd end up with two, and receivers ignore both when there are two. Run this lookup.

You want exactly one line that starts with v=DMARC1. If you get two, merge what you need into one record and delete the other. Our DMARC checker shows every tag in the record.

dmarcreports@lovable.dev in your record

Some domains that use Lovable's emails list dmarcreports@lovable.dev in their DMARC record. Lovable's docs don't print the record, and they don't say whether its setup adds that address. Where it's listed, Google's and Microsoft's reports for your domain would go to Lovable instead of you. Our write-up of report addresses without authorization has the counts.

Put an address you read in its place.

That address needs a working mailbox. An address at gmail.com won't do. Google publishes no authorization records for its users' addresses, so receivers that check won't send reports there.

Lovable keeps checking your DNS records, and its docs say it marks the domain Offline if they change. The docs don't say whether that covers the root DMARC record. After you edit it, check that More, then Emails, still shows the domain as Active. If it shows Offline, Lovable has stopped sending, so put the old record back.

The Resend connector

With Lovable's Resend connector, you verify the domain in Resend and add its records to your DNS yourself:

The DKIM key and the region in the MX record come from your Resend account. Copy them from the Resend screen. Resend shows CNAME records for some domains. Add whichever kind it shows you. Resend's test address, onboarding@resend.dev, delivers only to the Resend account owner, so your users get nothing until the app sends from your verified domain. Tell Lovable which address to use.

Resend doesn't publish a DMARC record for you, so the root domain record above applies here too.

A project on your own Supabase

If you connected the project to your own Supabase project, you set up sign-in emails in Supabase. When I last checked Supabase's SMTP docs, its default email service delivered only to addresses on the project's team, 2 messages an hour. Set up custom SMTP in Supabase with a provider such as Resend, and that provider's records go in your DNS.

Checking a real email

Sign up to your own app with an address you control and open the message's headers. Paste them into the email header analyzer. You want dmarc=pass and a DKIM signature for notify.example.com or example.com. If you see dmarc=fail, compare the From domain with the domain in the DKIM signature first.

Moving off p=none

A policy of p=none collects reports and changes nothing about delivery. Once the reports show every service that sends as your domain passing, move to p=quarantine and then p=reject. The guide to moving to p=reject has the checks for each step.

If the notify subdomain has its own DMARC record, only Lovable can change it.

DomainCanary gives you a report address on our own domain, and we publish the authorization record for every domain that uses it. We read the reports from every receiver and show each server that sent as your domain. Your first domain is free.