Lovable Email Setup: Auth, Transactional and Custom Domain

Choose the email path before changing DNS

Start by classifying the messages the application must send. Authentication email proves identity or restores account access. Transactional email confirms a user action or reports an account event. Marketing email promotes a product, campaign, or offer. The sender, consent rules, template controls, unsubscribe behavior, and reputation risk differ across these categories.

For a paid Lovable workspace using Lovable Cloud, built-in custom email is the simplest path for authentication and standard transactional messages. Lovable documents domain verification, DNS assistance, sending, authentication templates, application email generation, and delivery logs in one workflow. An owner or admin with access to the domain's DNS is required.

Use an external provider when the project uses its own Supabase connection, needs marketing campaigns, already has established email infrastructure, or requires provider-specific features and scale. Lovable documents connectors for providers including Resend and Mailgun. The provider account, billing, DNS, limits, suppression rules, and compliance then remain your responsibility.

Prepare the project, domain and ownership first

A reliable email setup depends on administrative access that should not live with one temporary contractor. Confirm who owns the Lovable workspace, the domain registrar, DNS zone, email provider account, and any Supabase project. Record these accounts in the team's access register and use role-based access where available.

For Lovable built-in email, the current prerequisites include a paid workspace, a project using Lovable Cloud, an owned domain, DNS access, and workspace owner or admin permission. A domain connected only for web hosting is not automatically configured for outbound email. Email authentication uses additional DNS records and a sending subdomain.

Choose the production domain carefully. One active email domain can be attached to a project at a time under the current Lovable workflow, while verified domains are managed at workspace level and can be reused. Removing a shared domain can affect every project that uses it, so check workspace dependencies before deletion or replacement.

Use a dedicated sending subdomain

A dedicated subdomain separates transactional reputation from the root domain used by the website and employee mail. A pattern such as notify.example.com or updates.example.com is easier to isolate, diagnose, and replace than sending every application message directly from the organizational root. Lovable uses notify as its default transactional subdomain and can still display a root-domain From address in supported configurations.

The visible From address, technical return path, and authenticated sending domain are related but not identical. A message can look branded while delivery systems evaluate DKIM signatures, SPF authorization, DMARC alignment, bounce history, complaint rates, and sending behavior behind the scenes. The setup is complete only when those signals align and the reply path reaches a monitored mailbox.

Do not create a different sending domain for every minor email type. Fragmentation slows reputation building and increases DNS and monitoring work. Separate streams when there is a meaningful risk boundary, such as high-volume marketing versus essential account and payment messages.

Configure DNS without taking the domain offline

Lovable offers an automated Entri workflow for supported DNS providers and a manual path when automation is unavailable. Follow the exact records shown inside the project. DNS host fields vary by provider: some expect only the subdomain label, while others expect the full hostname. Copying a record format from another registrar can create a duplicated domain name and prevent verification.

The highest-risk step is nameserver handling. Lovable's manual setup can ask for NS records that delegate only the transactional subdomain. Add those NS records inside the existing DNS zone. Do not replace the root nameservers at the registrar. Replacing the root delegation can disconnect the website, employee email, verification records, and every other service on the domain.

Allow time for propagation and do not repeatedly delete and recreate correct records. Lovable notes that verification can take up to 48 hours. Use a public DNS lookup to confirm TXT, DKIM, and subdomain delegation from outside your own network. If the domain does not verify, compare each hostname, value, record type, and conflicting record before changing anything else.

Configure authentication email as account infrastructure

Authentication messages are part of the security boundary. Lovable's current built-in workflow supports templates for signup confirmation, password reset, magic links, invitations, email-address changes, and reauthentication. Each template must state what happened, identify the application, present one clear action, and tell the recipient what to do if they did not request it.

A polished template cannot repair a broken redirect. Test every link from a fresh browser session, an expired link, a previously used link, and a mobile email client. Confirm that the destination belongs to the correct environment and domain. A production reset email that points to a preview URL is both a conversion failure and a security concern.

Keep the message focused. Do not place promotional content next to password or verification actions. Avoid exposing sensitive account details in subject lines or preview text. The application should provide a generic response when someone requests a reset for an unknown address so the flow does not reveal who has an account.

Design transactional email around application events

Transactional email should be caused by a durable business event, not by a button click alone. A payment receipt should follow a verified payment event. A booking confirmation should follow a committed booking record. An invitation should reference an invitation object with an owner, recipient, role, expiration, and redemption state. This prevents the message from promising something the database never completed.

Define the event payload before asking Lovable to generate the message. Include a stable event ID, recipient, template type, locale, relevant record IDs, and the minimum display data required. Store a send attempt with status and provider response. If the function retries, use the event ID as an idempotency key so one order does not produce three receipts.

Lovable can generate application email flows through conversation, but the instruction should specify the trigger, recipient authorization, data source, template states, failure handling, and logging. Keep provider keys in server-side secrets. Never expose a private email API key in browser code or a public environment variable.

When to use Resend, Mailgun or another provider

An external provider is not automatically more professional. It adds another account, bill, API key, DNS configuration, suppression list, webhook surface, and incident path. Use it because the application needs a capability that the built-in path does not provide, or because an existing email operation should remain centralized.

Resend is a common developer-focused option for transactional sending and can support broader email workflows depending on the chosen product and plan. Its domain setup uses SPF and DKIM, and a dedicated subdomain remains sensible. Mailgun is appropriate for teams already operating Mailgun or needing its scale and controls. Lovable's Mailgun documentation notes that provider billing is separate and that some operational features, including direct webhook handling through the connector, require additional architecture.

Projects using an external Supabase backend need an external provider for branded application mail because Lovable's built-in custom email is limited to Lovable Cloud projects. Supabase authentication email has its own SMTP and template configuration. Keep authentication ownership clear: changing the app's transactional provider does not automatically change the provider used by the auth system.

Protect deliverability from the first send

A verified domain is eligible to send; it is not guaranteed to reach the inbox. New sending domains have little reputation. Start with real low-volume traffic, send only messages recipients expect, and increase volume gradually. A sudden campaign from a new transactional subdomain can cause deferrals, spam placement, or provider restrictions.

Suppress hard bounces and complaints immediately. Do not repeatedly send to addresses that fail. Validate obvious address mistakes at entry, but do not block legitimate uncommon domains with an overaggressive pattern. For high-value flows, let the user correct the address and resend with a reasonable rate limit.

Use DMARC reporting to see which systems send on behalf of the domain. Begin with a monitoring policy while legitimate sources are inventoried, then tighten enforcement deliberately. Keep marketing lists away from the critical stream used for password resets, security alerts, receipts, and account invitations.

Test the full lifecycle, not one successful inbox

Testing with one Gmail address proves almost nothing. Create a matrix covering the major mailbox providers used by the audience, mobile and desktop clients, light and dark modes, long names, missing optional data, expired actions, duplicates, and provider downtime. Inspect the text alternative as well as the HTML message.

Verify authorization at the sending boundary. A user should not be able to change a client-side recipient field and send private information to another address. The server should derive recipients from trusted application records and enforce the current user's right to trigger the message. Administrative bulk actions need tighter limits and audit history.

After a domain or template change, redeploy when required and repeat the critical flow. Lovable's delivery logs can show sent, delivered, and bounced outcomes for built-in email. External providers expose their own event model. Connect failures to application monitoring so the product team sees them before users report missing account access or receipts.

Production launch checklist

Move email into production only after domain authentication, application authorization, failure handling, and ownership are documented. The sender configuration should survive the original builder leaving the project. Provider accounts and DNS must belong to the business, not a personal login that cannot be recovered.

Treat launch as the start of operations. Review delivery and bounce trends, keep templates synchronized with product behavior, and test account recovery after authentication or domain changes. Add email incidents to the same release and rollback process used for database and deployment changes.

Frequently asked questions