Why is my Lovable custom domain stuck on Verifying?

Lovable says Verifying means it is waiting for DNS records to propagate. Check that the exact A and TXT records shown in Project → Settings → Domains exist publicly, especially the full TXT verification value.

Why does Lovable say Unable to verify?

Lovable uses Unable to verify when DNS verification has not completed within one hour. Incorrect records or propagation are common causes. Confirm the records publicly before deleting and reconnecting the domain.

Can I use Cloudflare with a Lovable custom domain?

Yes. Lovable now documents an advanced Uses Cloudflare or similar proxy mode. In that mode it provides CNAME records instead of the standard A plus verification-TXT setup, and you are responsible for the proxy configuration.

Can an AAAA record break a Lovable domain connection?

Yes. Lovable's current prerequisites explicitly say there should be no AAAA record on the hostname being connected because it can interfere with setup and route traffic incorrectly.

What should I do if Lovable says Stalled or Failed while setting up SSL?

If ownership verification already succeeded, Lovable says Stalled and Failed are certificate-provisioning states. Use Retry; its documentation says you do not need to remove and re-add the domain for a Stalled setup.

Lovable Custom Domain Not Working? Fix DNS, Verification and SSL

A Lovable project can work perfectly on its lovable.app address while the custom domain stays on Verifying, becomes Unable to verify, fails SSL setup or suddenly goes Offline.

Those messages look like one problem. They are not.

A custom-domain launch has several layers:

domain ownership → public DNS → Lovable verification → SSL certificate → routing → application

The fastest fix is to identify the layer that failed before changing records. Repeatedly deleting the domain, switching nameservers or adding random DNS records can turn one diagnosable problem into several.

This is the troubleshooting order I would use.

Start with the exact Lovable status

Lovable’s current custom-domain documentation defines different states for domains connected from another provider.

Lovable status	What it means	First action
Action required	Setup is incomplete	Open Complete setup and finish the DNS steps
Verifying	Lovable is waiting for DNS	Check the exact A/TXT records publicly
Unable to verify	Verification did not finish within an hour	Recheck DNS values and propagation
Setting up	Ownership passed; SSL is being issued	Wait
Stalled	SSL provisioning is taking longer than expected	Use Retry
Failed	Ownership passed but SSL failed	Use Retry
Live	Domain and SSL are working	Test root, www and application routes
Offline	A previously live domain no longer points correctly	Use Recover and compare the required DNS
Connection issue	Lovable can no longer reliably serve the connected domain	Follow the warning before changing DNS
Check failed	Lovable could not complete its health check	Check again; do not rewrite DNS from this status alone

That table matters because Unable to verify is primarily a DNS/ownership problem, while Failed after verification is an SSL-provisioning problem.

Do not use the same fix for both.

1. Confirm the project itself is published

Before debugging DNS, open the project’s normal Lovable URL.

If the application is not published there, the custom domain cannot make an unpublished project magically available. Lovable says a domain can be Ready while the project is unpublished and will begin serving once the project is published.

This sounds obvious, but it is a useful isolation test:

if the Lovable URL is broken too, debug the application or deployment first;
if the Lovable URL works and only the custom domain fails, stay focused on domain infrastructure.

Do not rebuild working application code to solve a DNS problem.

2. For a normal external domain, check the A and TXT records exactly

For the standard manual setup, Lovable currently asks for two important records:

an A record pointing the hostname to Lovable’s edge IP;
a verification TXT record whose value begins with lovable_verify=.

The exact values shown in your Lovable project are the source of truth. Copy them rather than relying on an old tutorial or another project’s settings.

Lovable currently documents its edge A-record target as 185.158.133.1, but I would still compare your DNS panel against the value displayed for the project you are actually connecting.

The TXT hostname also changes with the type of connection. A root domain uses _lovable; a subdomain uses a host such as _lovable.app for app.example.com.

One common mistake is entering the full hostname into a DNS provider that automatically appends the domain again. That can silently create something like:

_lovable.example.com.example.com

The dashboard may look populated while public DNS contains the wrong name.

Check the public result, not only the form you typed into.

3. Remove conflicting AAAA records from the hostname

This is an unusually specific Lovable requirement and therefore worth checking early.

Lovable’s current prerequisites say the domain being connected should have no AAAA record, because an AAAA record can interfere with setup and route traffic incorrectly.

That means a hostname can have the correct Lovable A record and still behave inconsistently if IPv6 traffic is being sent somewhere else.

Before blaming propagation, inspect the hostname for:

old A records from a previous host;
AAAA records;
a CNAME left by another platform;
wildcard records that unexpectedly affect the hostname.

Migration failures are often not caused by the new record. They are caused by old infrastructure that was never removed.

4. Separate DNS propagation from DNS correctness

“Wait 72 hours” is not a diagnosis.

Lovable says DNS changes can take up to 72 hours, although most are applied within a few hours. That does not mean every broken setup should be left untouched for three days.

Ask two questions:

Does public DNS return the records I intended?
Does Lovable recognize those records?

If public DNS still shows the previous host, waiting may genuinely be appropriate.

If public DNS already shows the exact required A and TXT values but Lovable remains unable to verify long after that, you have narrowed the problem considerably. Use Check status and the domain warning rather than changing unrelated application code.

This evidence-first approach is useful whenever I am moving a site between platforms: registrar settings, authoritative nameservers and public DNS are separate things. What the internet can resolve is more important than what one dashboard claims should exist.

5. If you use Cloudflare, decide whether it is DNS or a reverse proxy

Cloudflare creates an extra decision because a DNS record can be DNS-only or Proxied.

Cloudflare’s proxy-status documentation explains the difference: DNS-only returns the configured origin information, while a proxied record sends HTTP/HTTPS traffic through Cloudflare first.

Lovable now explicitly supports a CDN or reverse proxy such as Cloudflare through Advanced → Uses Cloudflare or similar proxy during domain connection.

In that mode, Lovable provides a CNAME pointing to the project’s lovable.app address. Lovable says this proxy-mode CNAME replaces the normal A-record setup and does not require the standard verification TXT record.

So do not accidentally combine two architectures:

Standard Lovable domain connection

Use the A and TXT records Lovable gives you.

Lovable behind Cloudflare or another proxy

Enable Lovable’s advanced proxy option and use the CNAME it provides, then configure and maintain the proxy deliberately.

Cloudflare also notes that some SaaS-hosted websites and verification records need DNS-only behaviour, while proxied records change what the public internet sees. If you are not intentionally designing a reverse-proxy architecture, adding the orange cloud because “Cloudflare is safer” can make troubleshooting harder.

6. If verification passed but SSL is Stalled or Failed, stop changing DNS blindly

Once Lovable moves from verification into Setting up, it has already crossed an important boundary: ownership verification succeeded and SSL certificates are being issued.

Lovable’s current status guidance says:

Stalled means certificate provisioning is taking longer than expected;
Failed means ownership was verified but the certificate could not be provisioned;
both expose a Retry action.

For Stalled specifically, Lovable says you do not need to remove and re-add the domain.

That is a much safer first response than resetting the entire connection and starting DNS verification again.

7. If a domain worked before and now says Offline, compare what changed

A domain that was Live yesterday and a domain that has never verified are different incidents.

Lovable uses Offline when a previously live domain’s DNS is no longer valid. Its recovery flow shows the records required to reconnect it.

Look for changes around the failure time:

nameservers changed;
a registrar migration completed;
an old DNS zone was deleted;
Cloudflare proxy settings changed;
an AAAA record was introduced;
the domain was connected to another project;
a wildcard or redirect rule changed;
DNS was moved to another provider without recreating all records.

If the app still works on its Lovable URL, that is more evidence that the incident is at the domain layer rather than the product layer.

8. Be careful when changing nameservers

Changing nameservers is not the same as editing one A record.

It moves authority for the entire DNS zone.

Lovable’s documentation warns that if a domain bought through Lovable is switched to custom nameservers, Lovable stops managing its DNS and the connected site and email can stay offline until the necessary records are recreated at the new provider.

The same systems principle applies regardless of registrar: before changing nameservers, inventory everything using the domain.

That may include:

website records;
email MX records;
SPF, DKIM and DMARC;
Search Console verification;
subdomains;
API endpoints;
third-party verification TXT records.

A website migration should not accidentally become an email outage.

9. Once it is Live, test the business journey, not just the homepage

A green Live badge is not the end of deployment.

Test the domain like a customer:

open the root domain in a private browser;
test www if you use it;
confirm HTTPS has no certificate warning;
open important deep links directly;
submit the enquiry or signup form;
test authentication redirects if the product has accounts;
test payment return URLs if payments are enabled;
confirm email links point to the production domain;
check the canonical and sitemap host if the site should rank in Google.

If search visibility is the next problem, use my separate guide to diagnose a Lovable site that is live but not showing on Google. A DNS outage and an indexing problem should not share a troubleshooting checklist.

For a broader launch review, the AI-built app production checklist covers permissions, payments, storage, testing and operational readiness beyond the domain itself.

When should you stop troubleshooting and change the deployment architecture?

Not every DNS problem justifies moving the application.

I would consider a deployment change when the domain issue is part of a larger requirement the current setup cannot satisfy: infrastructure control, custom edge logic, portability, observability, compliance, or a deployment workflow the team needs to own independently.

That is an architecture decision, not a panic response to one verification error.

If the product is working but the deployment, DNS, GitHub handoff or production setup has become difficult to reason about, I can help audit the system through MVP development or you can contact me with the current architecture and the failure you are seeing.

The goal is not merely to make the domain turn green. It is to leave you with a deployment you understand and can operate.