Skip to main content

​
Overview

Emails allow your app to send authentication emails and custom app emails from your own email domain. For example: noreply@notify.yourdomain.com or noreply@yourdomain.com Using a dedicated sending subdomain helps protect your root domain’s reputation while keeping your branding consistent. You can customize:
  • Which email domain your project uses
  • The sender subdomain configuration
  • Email branding and visual style
  • Email templates and subject lines
Lovable handles domain verification, DNS configuration, email authentication (, , and ), and delivery infrastructure. No external email provider accounts or API keys are required.
Ready to set up emails? Check the Prerequisites, then jump to Add an email domain for the step-by-step setup and Generate and customize email templates to draft your auth and app emails.

​
Supported email types

You can send authentication emails and custom app emails.

​
Authentication emails

Authentication emails are a type of transactional email related to account access and identity verification. They are automatically triggered by Lovable Auth, the built-in backend’s authentication, when users perform specific security-related actions. Lovable provides six built-in templates you can use:
  • Confirm signup
    Sent when a user creates an account and email confirmation is enabled. Verifies that the user owns the email address before activating the account.
  • Password reset
    Sent when a user requests to reset their password. Allows secure password recovery.
  • Invite
    Sent when you invite a user to join your project (from More → Users). Grants account access through a secure invitation link.
  • Magic link
    Sent when passwordless login is enabled and a user requests a login link. Authenticates the user without requiring a password. You can ask Lovable to enable magic link authentication if it is not already configured.
  • Email change
    Sent when a user updates their email address. Confirms ownership of the new address before applying the change.
  • Reauthentication
    Sent when a user must verify their identity before performing a sensitive action, such as changing a password. Typically includes a short-lived verification code. You can ask Lovable to enable reauthentication if it is not already configured.
See Generate and customize email templates for more information.

​
App emails

App emails are a type of transactional email sent in response to user activity or events in your app. They are triggered by your application logic when something happens, like a purchase or update. There are no built-in templates, you decide when to send them and what they contain. Ask Lovable to add the required functionality, such as shipping notifications, order confirmations, purchase receipts, a message to you when someone submits a form, and other updates, and it will generate the templates for you. Lovable also handles unsubscribe automatically by adding an unsubscribe link to the email footer. See Generate and customize email templates for more information.

​
Availability and usage

  • Emails are available on paid plans.
  • Each paid workspace includes 50,000 transactional emails per month at no additional cost. Usage is calculated across the entire workspace. Additional emails are billed 4 credits per 1000 emails.
  • Lovable limits how many emails a workspace sends per hour, with separate limits for app emails and authentication emails: When a workspace reaches a limit, Lovable rejects new emails until the hour resets. More → Emails shows a warning once the workspace has used 80% of a limit. If you need a higher limit, contact Lovable Support. Authentication emails also have a per-project limit, Rate limit for sending emails, that you can adjust yourself. See Sending limits.

​
Why use emails

  • Better deliverability: Emails sent from your own domain are more likely to reach the inbox instead of spam.
  • More trust: Users see your domain in the From address, reinforcing credibility.
  • Consistent branding: Emails match your product identity.
  • Managed setup: Lovable verifies your domain and configures the required DNS records.
  • Authenticated sending: Lovable automatically sets up SPF, DKIM, and DMARC to authenticate your emails and improve inbox placement.
  • Continuous monitoring: Lovable keeps checking your DNS records after verification and marks the domain Offline if they change.

​
Prerequisites

To use emails:
  • Lovable sends app emails from your app’s server code. TanStack Start projects include their own server, so they don’t need the built-in backend. React + Vite projects need the built-in backend enabled, because their server code runs there. If your project is on React + Vite, you can upgrade it to TanStack Start.
  • Authentication emails need the built-in backend, because Lovable sends them through Lovable Auth.
  • Lovable may still send through the built-in backend for projects that first set up emails before August 14, 2026. Keep it enabled on those projects.
  • Your workspace must be on a paid plan.
  • You must own a domain and have access to manage its DNS settings.
  • You must be a workspace admin or owner to set up, disconnect, remove, or verify email senders.

​
How emails work

When you configure an email domain, Lovable:
  • Sets up a sender, the domain or subdomain your emails are sent from, such as notify.yourdomain.com
  • Guides you through DNS configuration using an automated setup flow
  • Verifies your domain by checking required DNS records
  • Provides six built-in branded authentication email templates that you can generate and customize
  • Generates custom app email templates based on the functionality you request, such as confirmations, notifications, and updates
  • Activates email delivery once DNS verification completes
After domain verification, emails are sent from your domain.

​
Email domain scope and usage

Email domains are provisioned at the workspace level.
  • A workspace can have multiple email domains
  • A verified domain can be used across multiple projects
  • You choose the project’s email domain in More → Emails
  • Only domains with status Active can send emails
  • Emails can be enabled or disabled per project

​
Add an email domain

Select the domain you want to use for sending emails. This will be the domain your users see in their inbox. There are two ways to start:
  • From the project chat: Ask Lovable to set up emails and it will present a setup button. For example:
  • From the Emails view: Go to More → Emails and click Get started. This takes you to the email setup flow.
1

Set an email domain

  • Enter a domain you own, such as yourdomain.com, or choose a suggestion in Email domain. Suggestions include domains registered through Lovable, connected website domains, and domains whose DNS Lovable manages. You can type a domain that is not listed.
  • Domains already configured for email show a status badge. Other suggestions show the domain name without a badge.
  • Click Continue.
Lovable reuses an existing sender when its configuration does not need repair. For a new email domain or one that needs DNS repair, complete the sender and DNS setup below.
The sender domain, including any prefix such as notify, can have at most 5 parts separated by dots. For example, notify.mail.yourdomain.com has 4 parts and works. notify.a.b.c.yourdomain.com has 6 parts, so Lovable does not accept it.
2

Review the sender address

Review the sender address shown in the setup flow. The inbox preview shows example emails from that address.
  • For a domain registered through Lovable that uses Lovable’s nameservers, Lovable defaults to sending from the domain itself, such as noreply@yourdomain.com.
  • For other new email domains, Lovable suggests a notify subdomain, such as noreply@notify.yourdomain.com. You can change the prefix.
  • When Show as sent from @yourdomain.com is available, enable it to show @yourdomain.com to recipients while the subdomain handles delivery.
  • Click Set up domain.
If you use a sender subdomain, its prefix must:
  • Use only lowercase letters, numbers, and hyphens
  • Not start or end with a hyphen
  • Be between 1 and 63 characters
  • Differ from the first part of your domain. For example, on mail.yourdomain.com you cannot use the mail prefix.
3

Complete DNS configuration

Lovable configures DNS automatically for domains registered through Lovable that use Lovable’s nameservers. For a domain that needs DNS changes at another provider, Lovable opens an automated setup flow after you click Set up domain. The flow, powered by Entri, asks you to sign in to your DNS provider and adds the records there after you authorize the update.If your DNS provider is not listed or you prefer manual control, you can configure DNS records yourself. Scroll to the bottom of the Select your domain provider window and choose Go to our manual setup.Both the automated and manual methods require verifying ownership of your domain. Lovable will provision your domain and generate the required DNS records.
If you close the Entri window before finishing, Lovable removes the domain setup you just started and you have to begin again. To add the records yourself, choose Go to our manual setup instead of closing the window.
For DNS providers that can’t hold NS records on subdomains, such as Hostinger and Wix, Lovable skips the Entri flow and shows Your DNS provider can’t hold these records. See My DNS provider doesn’t support NS records for subdomains.
Follow the on-screen prompts to log in to your DNS provider and authorize Entri to update your DNS records.
4

Wait for verification

After DNS is configured, you’re taken back to the Emails page in your project.A progress panel shows the current state of your domain setup and an estimated wait while DNS verification completes. See Email domain statuses to learn what each status means.
DNS changes typically propagate within a few hours, but may take up to 72 hours.
While DNS verification is in progress, you can start setting up your authentication and app email templates. See Generate and customize email templates for more information.
Lovable automatically detects when DNS verification completes and activates your domain. Once the domain status changes to Active, emails begin sending from your domain.
Newly provisioned domains start with a neutral reputation. Initial deliverability may fluctuate while your domain builds trust with inbox providers through consistent, legitimate sending. See Email deliverability best practices for more information.

​
Email domain statuses

The email setup domain picker can show the following statuses: In Project → Settings → Domains, email sender rows show these statuses:
  • Verifying sender: Lovable is checking the sender’s setup.
  • Active: The sender is ready to send emails.
When a sender needs attention, a warning explains the problem below its row.
Domains are continuously monitored. If required DNS records drift, are removed, or expire, the domain may move to an inactive state until re-verified.

​
Generate and customize email templates

The Emails page includes two tabs, Auth emails and App emails, where you can preview the generated templates for your app. The Auth emails tab appears only when your project has a backend, either the built-in backend or your own Supabase project. Email templates are not generated automatically. To generate email templates:
  • Auth email templates
    Go to the Auth emails tab and click Customize auth emails. Lovable generates six built-in branded templates.
  • App email templates
    Ask Lovable to add the required functionality, such as notifications, confirmations, or receipts. Lovable generates the corresponding email templates. For example:
    Lovable also generates a template when you ask for a form that visitors use to reach you.
Each template shows:
  • From address
  • Subject line
  • Live preview of the email template rendered in an iframe
  • Send test options, including sending a test email to your account or to a custom address.
    Emails sent from newly configured domains may initially land in spam while reputation builds.

​
Automatic branding

When generating the email templates, Lovable applies your app’s branding automatically by:
  • Extracting your app’s CSS variables (primary colors, fonts, border radius)
  • Detecting logo files in your app’s public and asset folders
  • Uploading a detected logo to a dedicated email assets storage bucket
  • Adapting email copy to match your app’s tone and language
The outer email body background is always #ffffff to ensure consistent rendering across email clients. Inner components can use your brand colors.

​
What you can customize

You can ask Lovable to update:
  • Copy and tone
  • Brand colors
  • Layout and structure
  • Images and logo placement
  • Subject lines
The outer email body background must remain white (#ffffff) to ensure consistent rendering across email clients. Inner components can use your brand colors.
For example:
Lovable updates templates while preserving required information, such as authentication variables, secure callback links, and the unsubscribe footer.

​
Edit templates manually

You can also edit the template files directly. Where they live depends on how your project was built, so ask Lovable to point you at them:
Whichever way you edit them:
  • Required authentication variables and callback links must remain intact, or authentication flows will break.
  • Lovable appends the unsubscribe footer to app emails. For projects created on or after July 9, 2026, Lovable also hosts the unsubscribe page. Older projects include the unsubscribe page in the app itself. Don’t add your own unsubscribe links or opt-out text to the templates.
  • Templates use React Email components with inline styles, because email clients do not support external CSS.
On some projects, edits to template files or subject lines only take effect after a redeploy. If your changes aren’t showing up, ask Lovable to redeploy:

​
Managing email domains

In More → Emails, use the domain dropdown to access:
  • Analytics and logs: View delivery metrics for the email domain and email activity for the current project using that domain.
  • Domain settings: Open Project → Settings → Domains to review this project’s email sender status.
  • Add domain: Choose a workspace domain or enter another domain to set up email for this project. Lovable reuses an existing sender configuration when it can.
  • Disable emails (or Enable emails when emails are disabled): Enable or disable emails for the current project. When disabled, authentication emails continue sending using the default Lovable auth sender instead of your custom email domain and templates, and other app emails stop sending.
When setup fails because of a DNS problem, select View DNS records in the setup panel to review the sender in Project → Settings → Domains. To inspect a sender’s DNS records during setup, open the domain in Workspace settings → Workspace domains and expand the sender under Email. To change the domain this project uses, open More → Emails, select Add domain from the domain dropdown, and choose or enter a domain. Click Continue and complete any sender or DNS setup Lovable requests. In Project → Settings → Domains, open the email sender’s three dots menu:
  • Check again: Workspace admins and owners can request another check while the sender is still verifying or shows a warning.
  • Email settings: Open this project’s Emails page.
  • Disconnect from this project: Workspace admins and owners can clear this project’s email setup without removing the workspace sender. The sender stays available to the workspace and its other projects. See What happens if I delete an email domain? for what changes in this project.
  • Remove sender: Workspace admins and owners can remove the sender from the whole workspace, including its use by other projects.
Removing a sender affects every project using it, including projects you cannot access. Review What happens if I delete an email domain? before confirming removal.

​
Analytics and logs

The analytics and logs view shows delivery metrics for the connected domain over 7, 30, or 90 days, and a log of recent emails sent for the current project.
  • Metrics cards:
    • Sent: Emails accepted and queued for delivery
    • Delivered: Emails successfully delivered to recipient inboxes
    • Bounced: Emails rejected by the recipient mail server
  • Delivery chart: Delivered and failed emails for the email domain, per hour for the 7-day range and per day for longer ranges. Hover over any point to see the exact counts.
  • Email activity log: An expandable list of recent emails sent for the current project, showing recipient, status, type, and time, with execution traces and error messages for failures.

​
Email deliverability best practices

When sending emails from a new domain, inbox placement may take time to stabilize. Inbox providers evaluate sender reputation over time based on engagement, authentication, and sending patterns. Follow these practices to improve deliverability and build a strong sender reputation.
New email domains have no sending history. Inbox providers treat them cautiously because spammers often use fresh domains and abandon them quickly.Initial deliverability may fluctuate during the first few days or weeks. This is normal.Your domain’s reputation builds gradually as real users engage with emails. This includes:
  • Authentication emails: Signups, password resets, email verifications
  • App emails: Order confirmations, shipping notifications, account updates
Both email types contribute to your overall domain reputation.Using a dedicated transactional subdomain helps isolate authentication traffic and protect your primary domain reputation.Typical timeline
  • First few days: Test emails may land in spam
  • First few weeks: Deliverability improves as legitimate traffic builds reputation
  • First few months: Reputation stabilizes with consistent, engaged sending
What helps:
  • Start sending with normal authentication traffic (user signups, password resets)
  • Let volume grow naturally as your user base expands
  • Add app emails gradually as transaction volume grows
  • Maintain consistent sending patterns over weeks and months
  • Ensure emails are expected and triggered by real user actions
  • Mark legitimate emails as “Not spam” in your inbox
What hurts:
  • Sudden large spikes in email volume from a brand-new domain
  • Sending bulk test emails immediately after setup
  • Inconsistent sending (long gaps followed by sudden bursts)
  • Panic-driven changes to domains or sender identity
Reputation builds automatically with consistent, legitimate sending behavior over time.
Authentication must pass for emails to reach the inbox. Lovable automatically configures SPF, DKIM, and DMARC when you set up your email domain.If DNS records are modified or misconfigured, authentication can fail and emails may land in spam.Always confirm the domain status is Active in More → Emails.
Authentication emails should only be triggered by real user actions, such as signing up or resetting a password.App emails should only be sent when directly related to user activity, for example:
  • Order confirmations: Only to the customer who placed the order
  • Shipping notifications: Only to customers with active shipments
  • Account updates: Only to users who made changes or need to be notified
Avoid generating artificial traffic for testing or automation purposes. Unnatural traffic patterns can negatively affect domain reputation.Don’t send to:
  • Email addresses that previously bounced
  • Users who unsubscribed from non-essential notifications
  • Inactive or closed accounts
Authentication emails should clearly match the user’s recent action and explain why the email was sent.App emails should focus on information relevant to the specific transaction or event.Good practices:
  • Use straightforward subject lines (“Reset your password”, “Verify your email”)
  • Include all necessary details (order numbers, tracking links, amounts, dates)
  • Clearly explain what the user needs to do
  • Match the email to the action the user took
Avoid:
  • Adding marketing content or upsells to auth emails
  • Misleading or clickbait subject lines
  • Promotional language in authentication emails
Mixing promotional content into transactional emails can trigger spam filters and reduce trust.
Use a consistent:
  • From address
  • Sender name
  • Domain
Frequent changes to sender identity reduce trust signals with inbox providers.
Authentication emails (password resets, email verification, magic links) don’t require unsubscribe links as they’re necessary for service functionality.Lovable automatically adds unsubscribe functionality to all app email templates. When a user unsubscribes, their email is added to a suppression list and future app emails to that address are blocked automatically before sending. Don’t remove the unsubscribe footer as this violates email sending requirements and will affect deliverability.
When customizing email templates:Do:
  • Use clear, descriptive subject lines (“Your order has shipped”, “Reset your password”)
  • Keep formatting simple and clean
  • Use a balanced text-to-image ratio
  • Include your brand name and a recognizable sender address
  • Ensure links in the email match your sending domain whenever possible
Don’t:
  • Use ALL CAPS in subject lines
  • Add excessive punctuation (!!!)
  • Create misleading subject lines
  • Use image-heavy layouts
  • Link to unrelated or mismatched domains
Inbox providers look for consistency between the sender domain and the domains used in links. If your email is sent from yourdomain.com, links inside the email should ideally point to yourdomain.com or its subdomains. Mismatched domains are commonly used in phishing attacks and may trigger spam filtering.Clear, predictable formatting and domain alignment improve trust and engagement.
High bounce rates damage sender reputation.Use Analytics and logs to monitor:
  • Sent
  • Delivered
  • Bounced
Hard bounces caused by invalid or mistyped addresses are especially harmful. Repeatedly sending to invalid addresses can reduce inbox placement.If bounce rates increase:
  • Review how email addresses are collected
  • Validate inputs at signup
  • Avoid retrying failed deliveries repeatedly
Spam complaints also negatively affect reputation. Both authentication and app emails should always be expected and clearly explained.
The Send test option in More → Emails is useful for validation, but limit your testing.Why this matters:
  • Inbox providers evaluate engagement signals from all emails you send
  • Repeated test emails to the same address create artificial traffic patterns
  • Bouncing test emails to fake addresses damages your reputation
Better approach:
  • Send a few test emails to yourself or your team
  • Use real email addresses you control
  • Avoid sending large batches of test emails
If authentication emails are marked as spam:
  1. Confirm the domain status is Active
  2. Ensure DNS records are correctly configured
  3. Review subject lines and content
  4. Check bounce rates in Analytics and logs
  5. Reduce sudden spikes in sending volume
  6. Be patient. New domains need time to build trust with inbox providers
Deliverability improves with consistent, legitimate sending behavior over time.
Inbox providers consider engagement when evaluating sender reputation.Authentication emails naturally generate positive signals when users:
  • Open the email
  • Click the verification or reset link
  • Complete the intended action
App emails generate positive signals when users:
  • Open order confirmations to check details
  • Click tracking links in shipping notifications
  • Interact with account update information
Clear messaging and expected flows increase engagement and improve long-term inbox placement.
Gmail clips emails larger than 102 KB. Keep your total email size under 100 KB to ensure your content displays fully.Best practices:
  • Optimize images before embedding them in app emails
  • Avoid large embedded images in receipts or order confirmations
  • Keep order details and transaction information concise
  • Consider linking to images hosted on your domain instead of embedding large files
Lovable includes plain text versions of emails automatically for accessibility and as a fallback for email clients that don’t support HTML.
While link tracking and open tracking can be useful for measuring engagement with marketing emails, they can hurt deliverability for transactional emails.Why this matters: When a shipping notification or order confirmation link doesn’t lead directly to your domain, it can make the email look suspicious to inbox providers.Recommendation: For app emails like order confirmations and shipping notifications, use direct links to your domain rather than tracking redirects whenever possible.
Inbox providers don’t share their spam filtering criteria publicly (to prevent spammers from gaming the system). However, they generally evaluate:
  • Sender authentication: Are SPF, DKIM, and DMARC configured correctly? (Lovable handles this automatically)
  • Sender reputation: What’s your history of bounces, complaints, and engagement?
  • Content quality: Are subject lines clear? Is formatting clean? Do links match your domain?
  • Engagement signals: Do users open emails? Click links? Reply? Or mark them as spam
  • Sending patterns: Are you sending consistently? Or in sudden bursts?
Think: “What would a phisher do?” Then do the opposite. Inbox providers want to protect their users, so demonstrate at every step that you’re a legitimate sender with no malicious intent.

​
Troubleshooting

Possible causes:
  • DNS records not fully propagated
  • NS delegation incorrect
  • TXT verification record missing
  • DNS configured on wrong domain level
  • NS records for a parent domain, for example hello.yourdomain.com, already point to Lovable nameservers, so the sender subdomain’s records are never found
What to do:
  • Open the domain in Workspace settings → Workspace domains and expand the sender under Email to inspect its DNS records
  • Confirm records were added to the correct root domain
  • Wait up to 72 hours for propagation
  • Open Project → Settings → Domains, then select Check again from the email sender’s three dots menu instead of waiting for the next scheduled check
If the domain stays in Pending or Verifying after the DNS records are correct and 72 hours have passed, see Domain verification is stuck or shows “Failed”.
Verification can stall, leaving the domain in Pending, Verifying, or Setting up even when your DNS records are correct and have propagated. A domain that stays unverified for one to two weeks moves to Failed.What to do:Before resetting the setup, review What happens if I delete an email domain?. Removing a sender interrupts its email for every project in the workspace that uses it, including projects you cannot access. Each of those projects has to be reconnected afterwards.
  1. Go to Project → Settings → Domains and select Check again from the email sender’s three dots menu. Lovable checks the sender’s setup again. Allow up to 72 hours for verification to complete.
  2. If the sender is still stuck, select Remove sender from the same menu and confirm. Wait for the sender to disappear, then set up the domain again from More → Emails. If Lovable says removal is still in progress, wait before trying again.
  3. Follow the new setup instructions and compare every record shown with the records at your DNS provider. Keep matching records and update any that differ. Do not assume the records stay unchanged after removing and re-adding a sender.
  4. After the sender is ready, reconnect each affected project from More → Emails and check delivery. Ask a workspace owner to restore setup for projects you cannot access.
  5. If the domain is still stuck after you re-add it, contact Lovable Support.
After your domain is verified, Lovable sends a test message through the email delivery provider to confirm that the sender is accepted. If the provider doesn’t accept it in time, the setup progress panel in More → Emails shows Send path not ready or Timed out waiting for email delivery path verification. The cause is usually on Lovable’s side, not in your DNS records.What to do:
  • Select Retry setup in the progress panel.
  • If Retry setup fails again, contact Lovable Support and include the domain name. Don’t delete the domain or change your DNS records in the meantime.
Setup fails with a message that the domain is already in use, set up in another workspace, or managed by another account. Lovable shows these errors when the sender domain is already set up somewhere else, usually in another workspace. A common case is the workspace a project was moved or remixed from. A remixed project’s original project still uses the sender domain.The problem is ownership, not your DNS records. Keep your existing DNS records in place.What to do:
  • If you’re an admin or owner of both workspaces, add the domain again in the workspace where setup failed. Lovable removes the sender domain from the other workspace and retries the setup. If Lovable says the domain becomes available later, wait and add it again then.
  • If another project in the other workspace still uses the sender domain, including a deleted project that can still be restored, Lovable can’t remove it. The error message names that project. Switch that project to another domain first, then try again.
  • If you’re a member of the other workspace but not an admin or owner, ask one of its admins or owners to remove the sender there. See What happens if I delete an email domain?.
  • If you aren’t a member of the other workspace, if setup fails with This subdomain is already in use, or if none of these steps work, contact Lovable Support and ask them to release the domain.
  • After the domain is released, add it again through the manual setup flow. If the email sender already appears in Project → Settings → Domains with an error, select Check again from its three dots menu instead. If Lovable shows This domain is still being removed, wait a few minutes and try again. If the records shown match your existing DNS records, you don’t need to change them.
Lovable requires NS records for the sender subdomain, for example notify, at your DNS provider. These records delegate the subdomain to Lovable, which lets Lovable create and maintain the SPF, DKIM, and DMARC records for it. Lovable has no alternative verification method:
  • TXT, CNAME, or MX records on the root domain cannot replace the NS records.
  • The manual setup flow replaces only the automated Entri flow. It requires the same NS and TXT records.
  • Use exactly the nameservers shown in Lovable. Verification fails with any other nameservers.
  • Choosing a different sender subdomain or enabling Show as sent from @yourdomain.com doesn’t remove the requirement.
For some providers, such as Hostinger and Wix, Lovable shows Your DNS provider can’t hold these records during setup.What to do:
  • Move the domain’s DNS to a provider that supports subdomain NS records, such as Cloudflare. Your domain can stay registered with your current registrar. Recreate your existing DNS records at the new provider before switching to its nameservers, then run the email setup again.
  • Alternatively, transfer the domain to Lovable and Lovable manages its DNS for you.
This means required DNS records were changed, removed, or expired after verification.What to do:
  • Open the domain in Workspace settings → Workspace domains and expand the sender under Email to inspect its DNS records
  • Restore missing NS or TXT records
  • Open Project → Settings → Domains and select Check again from the email sender’s three dots menu
The domain was deleted while this project was still using it. Go to More → Emails and start email setup to choose another workspace domain or enter a new one. Complete any sender and DNS setup Lovable requests.
Check:
  • Email domain is linked to your project
  • Domain status is Active
  • Emails are enabled for the project
  • For authentication emails: Lovable Auth is enabled, and you are triggering a supported auth event type
  • The correct edge function is deployed
  • Your workspace has not reached its hourly sending limit. See Availability and usage.
Use Send test on a template tab and check Analytics and logs for delivery failures or bounces.
Common causes:
  • Invalid email addresses
  • Typos during signup
  • Repeated retries to invalid addresses
Validate email input at signup and avoid retrying hard bounces.
This is common for newly provisioned domains.Avoid sending large volumes of internal test emails. Allow organic user-triggered emails to build reputation over time.
If you edited template files but users are still receiving old versions:
  • On older React + Vite apps, ask Lovable to redeploy your email templates.
  • On newer apps built with TanStack Start, publish your app to apply the change.
If emails are consistently landing in spam or being rejected, you can use the following tools for deeper diagnostics.These tools are optional and most useful for higher-volume senders.These tools help diagnose reputation or blocklist issues that may impact inbox placement.

​
FAQ

Authentication emails are a type of transactional email related to account access and identity verification. They are automatically triggered by Lovable Auth when users perform specific security-related actions, such as sign up, reset a password, or accept an invite. Lovable provides six built-in templates that you can generate when needed.App emails are a type of transactional email sent in response to user activity or events in your app. They are triggered by your application logic when something happens, like a purchase or update. There are no built-in templates, you decide when to send them and what they contain. Ask Lovable to add the functionality, such as notifications, confirmations, receipts, and other updates, and it will generate the templates for you.
Yes. Tell Lovable which address to send the submissions to, when you ask for the form or later. The prerequisites apply, so Lovable wires the email only after your sender domain is verified. Until then Lovable keeps saving the submissions to the table.These notifications come to you rather than to a customer, so unsubscribing from one stops them arriving. See Read your form submissions.
No. Both email types use the same custom domain and the same setup process.
No. Only transactional emails are supported, such as signup confirmations, password resets, order confirmations, and shipping notifications.Marketing emails, such as newsletters, promotional emails, product announcements, and similar messages are not supported.
Not always. TanStack Start projects include their own server, so Lovable sends their app emails without the built-in backend. React + Vite projects need the built-in backend, and so do authentication emails on any project, because Lovable sends them through Lovable Auth. Lovable may still send app emails through the built-in backend for projects that first set up emails before August 14, 2026, so keep it enabled on those.
No. Your web custom domain controls where your app is hosted. A custom email domain controls which domain your emails are sent from.These are separate configurations because web hosting and email delivery use different DNS records and infrastructure.You can use a completely different root domain for email sending as long as you control its DNS. However, using a domain that aligns with your product brand is recommended for user trust and deliverability.Hosting your app on a custom domain does not automatically configure email sending.
Yes. You can use a sending subdomain such as notify.yourdomain.com. The email setup flow shows the sender address before you confirm.When Show as sent from @yourdomain.com is available, you can display your root domain to recipients while the subdomain handles delivery.Using a dedicated email subdomain is recommended because it helps protect your root domain’s reputation.
No. Lovable manages domain verification, DNS configuration, authentication records such as SPF, DKIM, and DMARC, and delivery infrastructure. You do not need to manage API keys or third-party email provider accounts.
SPF, DKIM, and DMARC are email authentication standards that help inbox providers verify that your emails are legitimate and not spoofed.When you send an email, providers such as Gmail or Outlook check that:
  • The email is authorized to be sent from your domain
  • The message has not been altered in transit
  • The domain owner has defined a policy for handling suspicious emails
If authentication fails, emails may be marked as spam, rejected, or damage your domain reputation.Lovable automatically configures and maintains:
  • SPF (Sender Policy Framework): Authorizes which servers can send email for your domain
  • DKIM (DomainKeys Identified Mail): Cryptographically signs emails to prevent tampering
  • DMARC (Domain-based Message Authentication, Reporting, and Conformance): Defines how providers handle failed authentication and protects against spoofing
You do not need to manually configure these records. Lovable sets them up during domain verification and continuously monitors them. If authentication records are modified, removed, or expire, the domain status changes to Offline until you restore them.
Each paid workspace includes 50,000 transactional emails per month at no additional cost. Usage is calculated across the entire workspace. Additional emails are billed 4 credits per 1000 emails.
No. Emails are available on paid plans only. Free plans use the default Lovable auth sender.
DNS changes typically propagate within a few hours, but can take up to 72 hours.You can check the domain status in More → Emails. The status updates automatically once verification completes.
New email domains start with no sending reputation.If emails land in spam:• Confirm the domain status is Active
• Ensure DNS records have not changed
• Avoid sudden spikes in sending volume
• Avoid spam-trigger formatting
• Check bounce rates in Analytics and logsDeliverability improves over time with consistent, legitimate user activity.
Yes. You can customize:
  • Copy and tone
  • Brand colors
  • Layout and structure
  • Logos and images
  • Subject lines
You can ask Lovable to update the templates or edit the template files directly. Where the files live depends on how your project was built, so ask Lovable to show you where they are.Required authentication variables and callback links must remain intact in auth emails. Lovable adds the unsubscribe footer to app emails itself, so don’t add your own unsubscribe links or opt-out text.The outer email body background must remain white (#ffffff) to ensure consistent rendering across email clients. Inner components can use your brand colors.
If emails are disabled for a project, authentication emails continue sending using the default Lovable auth sender instead of your branded templates. App emails stop sending.
The effect depends on which action you use:
  • Disconnect from this project, on the sender row in Project → Settings → Domains, clears this project’s email setup. The sender stays configured for the workspace and other projects. Lovable sends authentication emails from its default sender. App code that explicitly uses the sender can still send from it.
  • Remove sender, on the sender row or in the workspace domain’s Email section, removes one sender for the whole workspace. Lovable clears its use from project settings, including projects you cannot access. The confirmation lists only affected projects you can access. Other senders remain configured.
After removal, app emails cannot use that sender. Lovable uses its default sender for authentication emails unless another ready sender remains configured for the project. To stop app emails for one project without removing its sender, use Disable emails instead of disconnecting the project.