Lovable Custom Domain Not Working? These Are the DNS Records You’re Missing

You built something impressive in Lovable. The project looks great. The idea is solid. And now you want to put it on a real domain instead of the default yourproject.lovable.app URL. You follow the setup steps, enter your domain, wait a few hours, and then nothing happens. The domain still does not load. The status stays stuck. The site either throws an error or shows the wrong page entirely.

This is one of the most common frustrations developers and entrepreneurs run into when working with Lovable. The platform is excellent for building fast, shipping quickly, and getting a product to market without heavy engineering overhead. But the custom domain setup has enough moving parts that even experienced developers get tripped up by it. Missing a single DNS record, using the wrong record type, or leaving a conflicting entry in place is enough to break the entire connection.

This guide covers everything you need to know to get your Lovable custom domain working correctly. It explains the exact records required, the most common reasons they fail, how different DNS providers handle these records, what Cloudflare users need to do differently, and how to verify everything is working. By the end, you will have a complete, working custom domain connected to your Lovable project.

Why Custom Domains Matter for Your Lovable Project

Before getting into the technical details, it is worth understanding why connecting a custom domain is not just cosmetic. A branded domain directly affects how your project performs and how seriously people take it.

When someone visits yourproject.lovable.app, they immediately know they are visiting a hosted subdomain. That is fine during development. It is not fine if you are trying to land clients, run a SaaS product, or build any kind of professional presence. A custom domain like yourcompany.com tells visitors that you are serious, that this is a real business, and that you have invested in the infrastructure behind what you built.

Beyond first impressions, custom domains affect search engine optimization in a measurable way. Search engines treat your custom domain as an independent entity that can build authority, earn backlinks, and rank for keywords over time. The lovable.app subdomain you start with cannot do that for you. Every day your project stays on the default URL is a day you are not building domain authority that could be driving you organic traffic six months from now.

For anyone building a product that they intend to monetize, either through direct client work, a SaaS subscription model, or affiliate-driven content, a custom domain is not optional. It is the baseline that makes everything else credible. The good news is that once you understand what Lovable actually requires at the DNS level, the setup is straightforward. The bad news is that the documentation, while accurate, leaves some important details in the footnotes where most people miss them.

What Lovable Actually Requires: The Full DNS Record Breakdown

Most hosting platforms ask you to point your domain using a CNAME record. You add one entry, it points to the host’s servers, and within a few hours everything works. Lovable does not always follow this pattern, and that is the first place people go wrong.

Lovable uses a combination of record types depending on whether you are connecting a root domain, a subdomain, or going through a CDN. Understanding which record type applies to your specific setup is the starting point for fixing any connection issue.

The A Record

An A record maps your domain or subdomain to a specific IPv4 address. Lovable uses A records as part of its domain verification and routing system. When you connect a domain through the Lovable settings panel, the platform will show you the specific A record values you need to enter. These typically point to Lovable’s infrastructure IP addresses. The A record alone is not enough to complete the setup, which is where many users get stuck. They add the A record, see the domain appear to be pointing somewhere, and assume the job is done. It is not.

The TXT Verification Record

Lovable requires a TXT record for domain ownership verification. This is the record that most people miss entirely, and it is the most common reason a Lovable domain stays in a pending or unverified state indefinitely. The TXT record is a string of characters that Lovable generates specifically for your domain during the setup process. It proves to Lovable that you actually control the DNS for the domain you are trying to connect. Without it, the platform cannot verify your ownership and the domain will not go live regardless of how correctly your A record is configured.

When you initiate a domain connection in Lovable under Project, then Settings, then Domains, the interface will display both the A record value and the TXT record value you need to enter in your DNS provider’s control panel. Both must be present and correct for the domain to verify successfully.

The CNAME Record for Subdomains

If you are connecting a subdomain rather than a root domain, the record type changes. For a subdomain like app.yourdomain.com or blog.yourdomain.com, Lovable expects a CNAME record that points to your Lovable project URL. A CNAME cannot be used on a root domain because of how DNS standards work, which is why root domains use A records instead. But for any subdomain, a CNAME pointing to your specific project URL on the lovable.app infrastructure is the correct approach.

There is also a separate consideration for the www subdomain. If you want both yourdomain.com and www.yourdomain.com to work, you need to set them up as separate entries in Lovable. The www version is not included automatically when you connect your root domain. You must add it independently through the same Settings, Domains interface, and configure its own CNAME record pointing to your project URL.

The Complete Record Set for a Root Domain

For a root domain setup, meaning yourdomain.com without any subdomain prefix, the minimum required records are the A record pointing to Lovable’s infrastructure IP as provided during setup, and the TXT verification record containing the unique string Lovable gives you. Both must propagate successfully before the domain status changes from pending to live. If you are also setting up the www version, that requires its own separate CNAME entry pointing to your project URL.

The Complete Record Set for a Subdomain

For a subdomain setup, meaning something like app.yourdomain.com or tool.yourdomain.com, you need the CNAME record pointing to your Lovable project URL, and in most cases you still need the TXT verification record as well. The exact requirements will be displayed in the Lovable interface when you initiate the connection for that specific subdomain.

The AAAA Record Problem That Breaks Routing Silently

This is one of the most insidious issues in the entire Lovable domain setup process because it causes problems without generating any obvious error. If your domain has an AAAA record configured, which is the IPv6 equivalent of an A record, traffic may be routed to the wrong destination entirely. Your site might show the wrong content, an old version of your project, or a completely different site.

The AAAA record problem happens because DNS resolvers prefer IPv6 when it is available. If your domain has an AAAA record pointing somewhere that is not Lovable’s current infrastructure, some browsers and networks will follow that IPv6 record instead of your A record. The result is unpredictable routing that can be incredibly difficult to diagnose if you do not know to look for it.

The fix is straightforward once you know about it. Log into your DNS provider’s control panel, look for any AAAA records associated with your domain, and delete them. After that change propagates, your domain should route correctly through the A record you configured for Lovable. This single step resolves a significant number of the custom domain complaints that appear in Lovable community forums, Reddit threads, and support tickets.

Cloudflare Users: What You Must Do Differently

If you manage your DNS through Cloudflare, which is one of the most popular DNS providers among developers and technical founders, there are specific considerations that apply to you and do not apply to users on other providers.

Cloudflare’s proxy feature, represented by the orange cloud icon in the DNS dashboard, routes traffic through Cloudflare’s own infrastructure before it reaches the destination server. This is great for performance and security in many contexts, but it creates a conflict when Lovable is trying to verify and manage your domain connection. When Cloudflare’s proxy is active on the records pointing to Lovable, Lovable cannot complete its verification process correctly, and the domain may never go live.

The standard recommendation for connecting a Lovable domain through Cloudflare is to set the relevant DNS records to DNS only mode, meaning the grey cloud rather than the orange cloud, at least during the initial verification and setup process. Once your domain is live in Lovable, you can revisit the Cloudflare proxy settings based on what you need, but the initial connection requires that Cloudflare’s proxy is not intercepting the DNS resolution.

There is an alternative approach if you want to keep Cloudflare’s full CDN and proxy benefits. Instead of connecting the domain through Lovable’s Settings, Domains interface, you configure your DNS to point directly to your Lovable project URL using CNAME flattening, which Cloudflare supports at the root domain level. In this setup, Cloudflare acts as the CDN and proxy, forwarding requests to your Lovable project URL. Lovable handles the application but Cloudflare manages the SSL certificate and traffic routing. This is more advanced, but it allows you to use Cloudflare’s performance and security features without fighting against Lovable’s verification system.

If you go the CDN or proxy route, you should not connect the domain inside Lovable’s settings at all. The two approaches are mutually exclusive. Either Lovable manages the domain connection, or your CDN does. Trying to do both simultaneously is a common source of conflicts that result in domains that never fully resolve.

Step-by-Step: Connecting Your Domain Manually

If you are not using the automatic Entri connection that Lovable offers with some DNS providers, here is the complete process for connecting your domain manually through any standard DNS provider.

Begin by logging into Lovable and navigating to your project. From there, go to Project, then Settings, then Domains. Click the option to connect an existing domain and enter the domain or subdomain you want to connect. Lovable will display the specific DNS records you need to add. Write these down or keep the browser window open because you will need these exact values.

Next, log into your domain registrar or DNS provider in a separate browser tab. This is wherever you purchased your domain or wherever you manage DNS, which might be the same place or a different service. Navigate to the DNS settings or DNS management section for your domain.

Add the A record using the exact IP address Lovable provided. Set the record name to your root domain, which is typically represented by an at sign or left blank depending on your provider. Set the TTL to a low value like 300 or 600 seconds if possible, because this will make your changes propagate more quickly during testing.

Add the TXT record Lovable provided. The record name for the TXT verification entry will typically be either your root domain or a specific subdomain prefix that Lovable specifies. Copy the full TXT value exactly as shown in the Lovable interface without adding or removing any characters. A single character difference will cause verification to fail.

If you are setting up a subdomain with a CNAME, add the CNAME record pointing to your Lovable project URL. Make sure the record name reflects exactly the subdomain you are connecting.

Check for any existing conflicting records. Look for any AAAA records on your domain and delete them. If there are old A records pointing to previous hosting providers, delete those as well. Conflicting records are a very common cause of domains that appear to be configured correctly but never go live in Lovable.

Return to the Lovable interface and wait for DNS propagation. For most DNS providers, initial propagation happens within one to four hours, but full global propagation can take up to 48 hours and in some cases up to 72 hours. You can use a DNS lookup tool to check whether your records have propagated from different global locations before troubleshooting further.

Common Reasons Your Lovable Domain Is Still Not Working

Even after following the correct setup process, domains sometimes refuse to go live. Here are the specific reasons this happens and what to do about each one.

Missing the TXT Record

This is the number one cause of domains stuck in a pending state. If you added the A record but forgot the TXT verification record, Lovable cannot verify ownership of your domain. Go back to the DNS settings and add the TXT record exactly as shown in the Lovable setup interface. After it propagates, return to Lovable and try refreshing the domain status or removing and re-adding the domain to trigger a new verification check.

DNS Changes Have Not Propagated Yet

If you just made changes, you may simply need to wait. DNS propagation is not instant. If your previous TTL values were set high, meaning 3600 seconds or higher, it can take the full duration of that TTL before the old cached records expire and new ones take effect. There is no way to force global propagation. You can verify that the records are visible from multiple geographic locations using a DNS propagation checker, and if they show up correctly globally, the issue is likely something else.

Incorrect Record Values

Even a small typo in an A record IP address or a TXT verification string will cause failure. Go back to your DNS provider and compare the records you entered against the values shown in the Lovable domain settings line by line. Pay attention to trailing periods, extra spaces, and character casing in TXT records.

The AAAA Record Conflict

As covered earlier, any AAAA record on your domain can cause traffic to route incorrectly. Delete any AAAA records you find and allow time for that change to propagate before testing again.

Cloudflare Proxy Interference

If your DNS is managed through Cloudflare and you have proxy mode enabled on the records pointing to Lovable, switch them to DNS only mode. This disables the proxy for those specific records and allows Lovable to complete its verification process directly.

Old Records from a Previous Setup

If this domain was previously hosted elsewhere, there may be leftover DNS records from that setup still present in your DNS panel. Old A records, old CNAME records, or old TXT records from previous verification processes can conflict with your new Lovable setup. Audit all records for your domain and remove anything that is not part of your current intended configuration.

Browser Cache and CDN Cache

Once your domain is technically configured correctly, you might still see an old site or an error because your browser or a CDN has cached the previous state of your domain. Test in an incognito browser window and from a different network or device to rule out local caching before concluding that there is still a DNS problem.

Subdomain Architecture: Planning It Right the First Time

If you are planning to use Lovable for multiple projects or multiple tools under the same root domain, taking a few minutes to think about your subdomain architecture before you start creating DNS records will save you significant trouble later.

The question is whether your subdomains should be organized as tool.projectname.yourdomain.com or projectname.tool.yourdomain.com. The difference is about hierarchy. In the first pattern, the project name is the primary category and the tool type is a sub-category of it. In the second pattern, the tool category is the primary organizer and the project name sits beneath it. The second pattern is usually the more scalable choice if you anticipate building multiple tools under a single category, because it lets you group related projects under a shared subdomain category like tool.yourdomain.com or app.yourdomain.com while each individual project gets its own prefix.

Getting the hierarchy right before you build your DNS structure prevents awkward migrations later. Renaming a subdomain after you have published content, built backlinks, or given the URL to clients is a painful process that requires redirects, re-verification in Lovable, and potentially a loss of any SEO value accumulated on the old URL.

SSL Certificates and HTTPS

Lovable automatically provisions an SSL certificate for any custom domain you connect through the standard Settings, Domains flow. You do not need to purchase or configure an SSL certificate separately. Once your domain verification completes and the status shows as live, your site will be served over HTTPS with a valid certificate.

If your domain has been live for more than 72 hours and still does not have a valid SSL certificate, this is a situation where you should contact Lovable’s support team directly. Automatic SSL provisioning should not take that long under normal circumstances, and a persistent lack of certificate usually indicates something went wrong in the backend provisioning process that requires manual intervention.

If you are using the CDN or reverse proxy approach with Cloudflare rather than the direct Lovable domain connection, SSL is managed by Cloudflare rather than Lovable. Make sure your Cloudflare SSL mode is set appropriately for your setup. Using Full SSL mode in Cloudflare while your Lovable project URL does not have an active certificate on the lovable.app domain can cause connection errors between Cloudflare and Lovable’s servers.

The www Subdomain: Why You Have to Add It Separately

Many people assume that when they connect yourdomain.com to Lovable, the www version is automatically included. It is not. The www subdomain is treated as a separate entity in Lovable’s domain system, and it must be added and configured independently through the same Project, Settings, Domains interface.

If you want visitors to reach your project at both yourdomain.com and www.yourdomain.com, you need to go back through the domain connection process for the www version and configure its own CNAME record pointing to your Lovable project URL. Lovable will list both versions separately in your domain settings, and each will have its own status that you can monitor independently.

This is worth addressing early in your setup because many users go live without the www version configured, then discover that people who type www before their domain get an error while people who type the bare domain get the correct site. That kind of inconsistency looks broken to visitors even if the root domain is functioning perfectly.

Primary Domain Settings and Redirect Behavior

If you have connected multiple domains or subdomains to the same Lovable project, you can designate one as the primary domain. The primary domain is the canonical URL for your project, which affects how Lovable handles redirects and which URL is treated as the authoritative address for SEO purposes.

To set a primary domain, the domain must first be in live status. Once it is live, go to Project, then Settings, then Domains, click the three dots menu next to the domain you want to set as primary, and select the option to set it as primary. If you later want to change your primary domain, you can use the same menu to unset the current primary and set a new one.

From an SEO standpoint, setting a primary domain matters because it helps avoid duplicate content issues. If your project is accessible at both your root domain and a www subdomain, designating one as primary ensures that Lovable handles the canonical relationship correctly and that search engines consolidate ranking signals to a single URL rather than splitting them across two versions of the same content.

Verifying Everything Is Working Correctly

After completing your DNS setup, use these verification steps to confirm everything is configured and functioning correctly before you consider the job done.

First, use a DNS lookup tool to check whether your A record and TXT record are resolving correctly from multiple global locations. If the records show up correctly globally, propagation is complete and any remaining issues are not propagation-related.

Second, check the domain status in Lovable’s Settings, Domains panel. A live status means Lovable has verified ownership and the domain is actively serving your project. A pending status means verification is still in progress or a required record is missing. A warning next to a pending status usually means the setup has taken longer than expected and you should investigate whether your records are correct.

Third, test the domain in an incognito browser window from your current network. Then test from a different network or device if possible. If the site loads correctly in both environments, your setup is complete and working.

Fourth, if you have Google Search Console or another SEO verification tool set up for your domain, verify the domain property after your custom domain is live. This step is separate from the Lovable setup but important for ensuring your SEO infrastructure is properly connected to your new domain.

When to Remove and Re-Add Your Domain

If you have verified that your DNS records are correct, propagation is complete globally, there are no conflicting records, and your domain is still not going live in Lovable, removing the domain from your Lovable settings and re-adding it can sometimes resolve persistent verification issues. This forces Lovable to initiate a fresh verification check rather than continuing to retry against a cached state.

To remove a domain, go to Project, then Settings, then Domains, click the three dots menu next to your domain, click Remove, and confirm the removal. Then wait a few minutes before re-adding the domain through the same interface. Lovable will generate a new TXT verification record during the re-add process. Check whether the new TXT record value differs from the previous one, and if it does, update your DNS accordingly. Once the new TXT record propagates, the domain should complete verification.

Professional Domain Setup Services: When to Ask for Help

DNS configuration is one of those tasks that looks simple on the surface but has enough edge cases and provider-specific quirks that it can genuinely consume hours of debugging time. If you have gone through all the steps in this guide, verified your records, waited for propagation, ruled out every common conflict, and your domain still refuses to go live, the problem may be something specific to your DNS provider’s implementation, a backend issue on Lovable’s side, or an unusual interaction between your domain configuration and Lovable’s infrastructure.

At that point, reaching out to a developer who specializes in DNS configuration, web infrastructure, or specifically in Lovable project setup is a practical decision. The cost of a few hours of professional time is usually lower than the cost of continued downtime for a project that should be generating business, client inquiries, or affiliate revenue. A professional can audit your entire DNS configuration, identify conflicts that are not obvious from a surface-level inspection, and get your domain live without the days of trial and error that self-troubleshooting often involves.

If you are looking for professional assistance with your Lovable domain setup, DNS configuration, or broader web infrastructure, working with someone who has done this specifically on the Lovable platform will save you significant time. The nuances of Lovable’s verification system, its specific requirements around TXT records, and the way it interacts with different DNS providers are not things you want to learn through repeated failed attempts. An experienced setup specialist can have your domain live within hours rather than days.

Lovable Custom Domain Setup for Client Projects

If you are a developer or agency using Lovable to build projects for clients, the custom domain process has some additional considerations worth being aware of.

Custom domains in Lovable are associated with the workspace account of the person who connects them. If you are building on a client’s behalf and they need to own the domain connection, either the client needs to connect the domain themselves using their own Lovable account, or you need to handle the DNS configuration through their domain registrar account directly. The domain must be verified by whoever is managing the Lovable project it is being connected to.

For agencies managing multiple client projects in Lovable, keeping a clear record of which DNS records belong to which project and which client’s account they are verified under will prevent considerable confusion when a domain needs to be updated, transferred, or troubleshot later. Document the A record values, TXT verification strings, and any CNAME entries used for each project at the time of setup rather than trying to reconstruct them months later when a client reports that their domain stopped working.

Conclusion: Get Your Lovable Project on a Real Domain

The Lovable platform is one of the most capable tools available for building and shipping web applications quickly. But the value of what you build there is directly tied to how professionally it is presented, and a real custom domain is fundamental to that presentation. The default lovable.app subdomain is fine for internal testing and early development. For anything you intend to show to clients, monetize, or grow through search, a custom domain is not optional.

The DNS records required to connect your domain to Lovable are an A record for the root domain, a TXT verification record to prove ownership, and a CNAME record for any subdomains including the www version. The most common reasons these setups fail are a missing TXT record, a conflicting AAAA record, Cloudflare proxy interference, and residual records from previous hosting configurations. Each of these has a straightforward fix once you know to look for it.

If you have followed every step in this guide and your domain is still not connecting, the options are to remove and re-add the domain to trigger a fresh verification, contact Lovable’s support team directly, or work with a professional who can audit your full configuration and identify the specific issue. Do not let a DNS problem keep a finished, functional Lovable project offline. The fix is almost always a small configuration detail, and with the right information, it is entirely solvable.