Lovable Custom Domain: Connect It Without Breaking Email

Connecting a Lovable custom domain becomes risky when the same domain also handles business email, an existing website, or customer login. The useful question is which records and URLs need to change, and which services depend on the current setup.

This guide reviews official documentation and supplies an editorial launch procedure. The examples use the reserved domain example.com; substitute your own domain and the exact values shown inside your project. We have not performed this connection in a paid Lovable account.

Which domain route should you choose?

Lovable’s domain documentation confirms that connecting a new domain requires a paid plan. You can configure it before publishing, but publication is required to serve content. Decide where the project belongs before editing DNS.

For an existing site, a subdomain provides a smaller trial surface. It lets you inspect the project without routing every visitor away from the current website. It is not an automatic SEO improvement; it is a way to contain the launch change.

External hosting has a different responsibility boundary. Lovable’s ownership guide distinguishes hosting the frontend elsewhere from moving backend services too. A custom domain connected to Lovable changes the public address while retaining that hosting arrangement.

Make a DNS change sheet before you connect

Record the current configuration in your DNS provider. The registrar that sold the domain and the provider serving its authoritative DNS may be different companies. Editing a DNS screen that is no longer authoritative will have no effect.

Use this change sheet:

Do not paste a generic IP address from a tutorial. A copied value can belong to an older configuration or another project. Treat the current setup screen as the record specification.

Keep email records in the change sheet even if you do not plan to touch them. A hurried replacement of an entire DNS zone can make the website work while incoming mail stops. Website SSL also tells you nothing about whether your mailbox still receives messages.

Check what your MX records point to, too. If a mail destination uses the same hostname whose website address you are replacing, preserving the MX entry alone may not preserve delivery. Resolve that dependency with your mail provider before switching. Save mail host address records, SPF, DKIM, and DMARC alongside the MX entries; do not remove unrelated TXT records to make room for website verification.

Connect the domain in a controlled order

Start at Project → Settings → Domains or Publish → Add domain. The current setup instructions distinguish two connection modes:

• Direct connection: apply the supplied A and TXT records. Keep the A record DNS-only during verification.
• Intentional CDN or reverse proxy: select Advanced → Uses Cloudflare or similar proxy in setup. This uses a CNAME instead, without the direct mode’s verification TXT record; you maintain the proxy configuration.

Choose one mode and follow its record specification. Do not combine instructions from the two flows.

The following sequence is our operational recommendation:

1. Publish a representative version. Include a working homepage, a nested page, and the customer action you care about. A blank placeholder cannot reveal routing or login failures.
2. Save the old records. Record the destination and record type, not just a screenshot of the final edited screen.
3. Add only the specified changes. Check how your DNS provider handles hostnames. Some expect app; others show the full hostname after saving. Review conflicting website records at that exact host, including stale AAAA records, rather than clearing the whole zone.
4. Wait for domain setup to finish. Separate DNS verification from certificate readiness. Avoid repeatedly deleting and recreating the domain while setup is progressing.
5. Choose the primary public hostname. Once it is Live, use its three-dot menu to select Set as primary. Use that address consistently in navigation, canonical URLs, marketing links, and authentication configuration.
6. Run the acceptance checks below. Keep the old website available until you have verified the replacement.

For a proxy deployment, record who maintains the proxy and how you will test its origin connection. Changing the host, certificate behavior, and app configuration together makes diagnosis harder. A standard direct connection is a simpler trial when a proxy is optional.

Diagnose the layer that failed

Start with the symptom. Rewriting application code will not repair a record at the wrong DNS provider.

Record the hostname, observation time, and exact error. “The domain is broken” hides whether you are looking at DNS, TLS, routing, or authentication.

For a technical handoff, a read-only DNS lookup can help. On Windows PowerShell, these examples inspect public records; they do not change DNS:

Resolve-DnsName example.com -Type NS
Resolve-DnsName app.example.com -Type A
Resolve-DnsName example.com -Type MX

Use the verification hostname and record type from your setup screen when checking verification. An absent A record does not establish a fault if your intended setup uses a different record type.

Verify the customer journey after HTTPS works

A successful homepage load is the start of acceptance. Open these paths in a fresh browser session and save the results:

• The chosen primary hostname and any alternate host you connected.
• A nested page opened directly, without first navigating through the homepage.
• A deliberately missing URL, to inspect the site’s missing-page behavior.
• Signup or login, followed by logout and a new login.
• A password reset or transactional link, using a test account you control.
• The contact form’s actual destination, plus incoming business email.
• A mobile visit to the page used in your main marketing link.

For redirects, check that the destination preserves the path where appropriate. Sending every old URL to the new homepage leaves a customer who bookmarked a useful page without the information they expected.

Lovable’s primary-domain setting uses temporary 302 redirects between connected domains. It does not provide permanent 301 redirects for that setting. For a permanent URL migration, Google’s site-move guidance recommends server-side permanent redirects where possible. Record the actual redirect status and where your old-to-new rules will run before retiring the previous host.

If you are changing established URLs, use Google’s site-move guidance to plan old-to-new mappings. Our recommendation is to list the pages with traffic or business value first, verify their replacements, and monitor the change in Search Console. Avoid combining a domain move with a broad content deletion unless the deletion is intentional.

What does a Lovable custom domain cost?

Connecting a new domain requires a paid Lovable plan. The current documentation says already-connected domains keep serving after a downgrade; reconnecting or adding one requires a paid plan. Budget separately for domain registration and renewal, email, and hosting or backend usage. Check current billing in the vendor’s plan screen.

When comparing native hosting with external deployment, include the maintainer’s work. A cheaper hosting bill can be outweighed by configuring a server runtime, updating dependencies, or restoring a failed release. Our running-cost guide explains how to inventory those costs.

Questions to resolve before the final switch

Do I need to transfer my domain registration to Lovable?

An existing-domain connection is available, so transferring registration is not a prerequisite. Keep track of where registration, DNS, and hosting are managed. They are separate responsibilities even when one provider offers all three.

Does a connected domain guarantee Google indexing?

No. A domain connection establishes an address and hosting route. Public accessibility, crawl rules, canonical URLs, page content, and Google’s indexing decision remain separate checks. Use the SEO launch checklist after the domain works.

When should I cancel the previous hosting?

Keep it until the replacement’s important URLs and customer actions pass, the old-to-new mapping works, and you have a rollback route. If the old host also supplied email, identify that dependency before cancellation.

Your launch record should end with an explicit owner: who can change DNS, who can deploy the app, and who will receive a failure report. That handoff is useful long after the domain first turns live.