Lovable custom domain not working: stuck verifying, no SSL or the old site

You published the app, went to Settings, Domains, connected your domain, added the records and waited. A day later the domain still says Verifying, or the browser shows a certificate warning, or your domain loads the website you had before, or Cloudflare shows error 1001.

Lovable's side of this is simple: it needs two DNS records and nothing in the way. Almost every stuck domain is one record missing, one record too many, or a proxy in front.

What Lovable expects

For a root domain like example.com, set up manually, Lovable's documentation asks for exactly two records at your DNS provider:

An A record on @ (some panels want the name blank or the full domain instead) pointing to 185.158.133.1.
A TXT record on _lovable with the lovable_verify=... value shown in the setup screen.

For a subdomain like app.example.com, the A record goes on app and the TXT on _lovable.app. The www version is connected for you when you connect a root domain, unless you turned that option off.

Two requirements that catch people out: custom domains need a paid Lovable plan, and you need editor access or higher on the project.

Check what the internet sees

Your DNS provider's panel shows what you typed; what matters is what the world resolves. From a terminal (macOS and Linux have dig):

dig +short A example.com
dig +short AAAA example.com
dig +short TXT _lovable.example.com
dig +short CAA example.com
dig +short A www.example.com

What you want: one A answer, 185.158.133.1; no AAAA answer at all; the TXT showing your lovable_verify= value; and either no CAA answer or one that allows Lovable's certificate authorities (section 4).

1. Stuck in "Verifying"

Lovable says verification that has not finished within an hour usually means the records are wrong or still propagating. In order:

The TXT value is incomplete. Copy it again from the setup screen; a truncated or quoted-twice value never matches.
The TXT name is doubled. Some panels append the domain automatically, so typing _lovable.example.com creates _lovable.example.com.example.com. Type only _lovable. The dig above shows whether it resolves.
The A record is proxied. If your DNS is on Cloudflare and the cloud icon is orange, Lovable cannot see its own address. Set it to DNS only (grey) while verifying.
There are two A records. One for Lovable and one left over from the old host means some visitors, and sometimes the verifier, reach the old server.

Fix, wait a few minutes, then click Check status in Lovable.

2. The domain shows your old website

The new records are there, but so are the old ones. Remove every leftover A, AAAA and CNAME for that name, leaving only Lovable's A and TXT. The AAAA record is the usual culprit: it is the IPv6 address of the previous host, many panels hide it below the fold, and Lovable's docs say AAAA records can interfere with setup. Visitors on IPv6 networks, which includes many mobile networks, keep landing on the old site while your laptop shows the new one.

3. Cloudflare error 1001 or 1003

These errors come from Cloudflare, not Lovable. Lovable's documented fix is to set its records to DNS only instead of Proxied. If you do want Cloudflare in front of the app, turn on Uses Cloudflare or similar proxy under Advanced when connecting the domain: Lovable then gives you a CNAME to your lovable.app address instead of the A record, no TXT is needed, and keeping the proxy configured correctly becomes your job.

4. Verified, but "Setting up", "Stalled" or a certificate warning

After verification Lovable issues the SSL certificate itself; you do not buy or install one. Until the domain shows Live, browsers will show a security warning. Propagation usually takes a few hours and can take up to 72.

If it stays in Setting up, or moves to Stalled or Failed, look at the CAA records. A CAA record tells certificate authorities who may issue for your domain; one left by a previous host that only allows its own authority blocks Lovable. Lovable recommends allowing all three it uses:

0 issue "pki.goog"
0 issue "letsencrypt.org"
0 issue "ssl.com"

A subdomain inherits the parent's CAA records unless it has its own. Then click Retry in Lovable.

5. Live, then broken

If a domain that worked stops working, Lovable's docs point to the hosting connection having been moved, removed or blocked. Check whether someone connected the same domain to another project: inside one workspace it can be moved; in another workspace, the other project keeps serving it until it is disconnected there.

After the domain works

A live domain is often when the next problem appears, because the app's backend still believes it lives at the preview address. Logins that bounce to localhost or to the lovable.app address are fixed in the auth settings, not in DNS: see Supabase login redirects to localhost after deploy. Test both www and the bare domain, since a session started on one is not visible on the other.

The domain is one of six things that usually break between preview and production. If the domain was the easy part and the app behind it is the problem, that is what our vibe code rescue audit is for: 450 EUR, 48 working hours, a written report of what is broken and what each fix costs, with the fee deducted if you continue into the rescue (1,500-6,000 EUR, fixed scope).