The DNS Setup Your No-Code Builder Doesn't Tell You About

Quick answer: when you point a custom domain at a no-code builder, the platform walks you through adding a few DNS records and then tells you your site is live. That's true, but it's only half the job. DNS also controls whether your emails land in inboxes instead of spam, whether an old subdomain you forgot about can be hijacked by someone else, and whether visitors reliably reach your site at all. None of that gets checked by the "your site is live" confirmation screen. A five-minute look at your DNS records catches almost all of it.

Most no-code creators never think about DNS again after the initial setup. It's invisible by design: you add a record, wait a few minutes, and the site works, so the assumption is that the job is done. But DNS keeps doing things in the background long after launch, and it doesn't clean up after itself when you switch builders, add a new tool, or stop using an old one.

In short: getting your domain to point at your no-code builder is the easy 20% of DNS. The other 80% (email authentication, leftover records, and record conflicts) is what actually causes problems later, and it's worth checking directly rather than trusting a "connected" checkmark.

What Actually Happens When You Connect a Custom Domain

DNS is the system that turns a domain name into instructions: where to send visitors, where to send email, and which services are allowed to act on behalf of your domain. When you connect a custom domain to a builder like Webflow, Framer, Lovable, or Bolt, you're usually asked to add one or two records at your domain registrar (GoDaddy, Namecheap, Cloudflare, wherever you bought the domain):

• A record: points your domain directly to an IP address.
• CNAME record: points your domain (usually www or a subdomain) to another domain, like yoursite.builderapp.com.

Add the record the builder tells you to add, wait for it to propagate, and the site resolves. That part almost always works, because it's the one thing every builder's onboarding flow is optimized to get right. What the onboarding flow doesn't cover is everything else sharing that same domain.

The Three Things That Quietly Break

1. Email authentication (SPF, DKIM, DMARC)

If you send any email from your domain, whether it's a contact form notification, a Google Workspace inbox, or a marketing tool, that email relies on three DNS records to prove it's really coming from you: SPF, DKIM, and DMARC. No-code builders that host your site have no reason to set these up, because they're not sending your email. So if you add a custom domain to a builder and separately connect an email service, it's common for nobody to have configured the email side.

The result isn't a hard failure you'd notice immediately. It's quieter: messages start landing in spam, or a portion of them silently bounce, or (with no SPF/DKIM at all) anyone can spoof an email that looks like it's from your domain. This is the kind of thing that goes unnoticed for months because "the site works fine."

2. Dangling records and subdomain takeover

This is the one most creators have never heard of, and it's the most serious. If you ever pointed a subdomain (like blog.yoursite.com or app.yoursite.com) at a third-party service with a CNAME record, and later stopped using that service without removing the record, the CNAME can be left "dangling," still pointing at a service you no longer control.

If that third-party service lets anyone claim an unused project name (many hosting platforms, page builders, and staging environments work this way), someone else can register the exact name your old CNAME still points to. Your subdomain then serves their content instead of a dead link. This is a well-documented category of issue called subdomain takeover, and it's common specifically because people try a builder, a landing page tool, or a staging environment, move on, and never clean up the DNS record pointing at it.

3. Duplicate or conflicting records

It's common to end up with more than one A or CNAME record for the same hostname after testing different tools or following outdated setup instructions. Depending on the provider, this can cause the site to resolve inconsistently: some visitors and some DNS resolvers see the current version, others see a stale or broken one, until the conflicting record is removed. It's a frustrating one to diagnose because it doesn't fail the same way for everyone testing it.

A 5-Minute DNS Check You Can Run Yourself

You don't need special access to check any of this. A public DNS lookup tool (like whatsmydns.net or dig from a terminal) shows you exactly what's published for your domain.

If you don't recognize a record and don't remember adding it, that's worth investigating before you delete or ignore it, since it could be intentional (a CDN, an email tool, a verification record) or it could be exactly the kind of leftover that causes problems.

Why This Falls Through the Cracks

No-code builder documentation is written to answer one question: "how do I make my site live?" It answers that question well. It has no reason to cover what happens to your DNS six months later, after you've added an email tool, tried a second builder, spun up a staging subdomain, or dropped a service you didn't end up using. That's not a gap in any one builder's docs, it's just outside the scope of what "connect your domain" onboarding is meant to do.

The practical result is that DNS hygiene ends up being nobody's job. It's not the builder's job (they only care about their own record), and it's easy for it to not be yours either, since nothing about a working site tells you a stale record is sitting there. A quick infrastructure check once in a while, especially after switching tools or adding a new email service, is enough to catch this before it turns into a spoofed email or a hijacked subdomain.

Final Thoughts

DNS is one of the few parts of a website that keeps functioning, or malfunctioning, entirely out of view. A no-code builder's job ends at "your domain resolves to your site," and that's a reasonable place for it to end. It's just not the same thing as "your domain's DNS is fully in order."

The good news is that this isn't a hard problem to fix once you know to look. Nothing in this checklist requires code or developer access, just a DNS lookup tool and ten minutes to compare what's published against what you actually still use.

If you've connected a custom domain more than once, added an email tool after the fact, or tried more than one builder before settling, it's worth doing that check now rather than assuming the "connected" checkmark covered it.