If your custom domain isn’t working after you connect it to a website builder, the cause is almost always one of six things: a record was typed wrong, an old record is still competing with the new one, your nameservers point somewhere other than the panel you edited, resolvers are still serving a cached answer, only one of www and the root domain is set up, or the HTTPS certificate hasn’t been issued yet.
Check them in that order. The first three are mistakes that waiting will never fix. The fourth is the only one that really is “wait for propagation,” and you can confirm it in a minute with a public DNS lookup instead of guessing. Below is what each problem looks like and how to fix it.
1. The records are typed wrong
Most failed connections are typing mistakes. Your builder gives you a small set of records, usually an A record for the root domain and a CNAME for www, and each has three parts: the host (also called name), the type, and the value (also called target or points to). Get any of the three wrong and the domain goes nowhere or to the wrong place.
Host field. In most DNS panels, @ means the root domain itself (yourdomain.com) and www means www.yourdomain.com. Namecheap’s help describes @ as the host “used to point a root domain (yourdomain.tld) to the IP address.” A common mistake is typing the full name, such as www.yourdomain.com, into the host box. Many panels add your domain automatically, so you end up with www.yourdomain.com.yourdomain.com, a name nobody will ever visit.
Trailing dots. In DNS zone files, a name ending in a dot is absolute and a name without one is relative to your domain. Some panels want the target written with a final dot (builder.example.net.) and some add it for you. Follow your provider’s own examples, and don’t paste the dot into the host field.
Wrong type or target. An A record must hold an IP address. A CNAME must hold a host name, not an IP. Cloudflare’s docs describe A and AAAA records as mapping “a domain name to one or multiple IPv4 or IPv6 address(es)” and CNAME records as mapping “a domain name to another (canonical) domain name.” Copy the values straight from the builder’s instructions, with no extra spaces and no https:// at the front.
2. Old records are still there
If your domain shows an old website, a “coming soon” screen or a registrar parking page, the new record probably isn’t the only one for that name. When there are two A records for @, one pointing at your old host and one at your new builder, visitors land on either one more or less at random. An AAAA record left over from the old host can do the same for visitors on IPv6.
Registrars also add their own defaults to new domains: parking records, URL forwarding or redirect entries. Namecheap’s help tells you to look for conflicting records on the same host after adding an A record, listing unmasked, masked and permanent redirect records as well as other A or CNAME records, and to “remove them if there are any.”
CNAMEs have a stricter rule. RFC 1034, the core DNS standard, says: “If a CNAME RR is present at a node, no other data should be present.” So a CNAME for www can’t sit beside an A record or a redirect for www. Delete everything for that host except the records your builder asked for.
3. Your nameservers point somewhere else
This is the one that drives people mad. You add records at your registrar, they look perfect, and nothing changes. That’s because the internet only reads DNS from the provider your nameservers point to. If your domain uses Cloudflare’s nameservers, or your old host’s, or the builder’s, the record screen at the registrar is ignored completely.
Look up your domain’s NS records with a public lookup tool, or check the nameserver setting in your registrar account. Whichever company those nameservers belong to is where your A and CNAME records have to go. Then either add the records there, or switch the nameservers to the provider you want to use. If you switch, remember the new provider starts empty: copy over your email records (MX, plus SPF and DKIM TXT records) first or your email will stop working.
Nameserver changes are slower than record changes. Cloudflare’s setup guide says to “wait up to 24 hours while your registrar updates your nameservers,” and notes that some lookup tools cache answers, so they may show the old nameservers for a while longer.
4. It’s still cached (and how long DNS really takes)
“DNS propagation” isn’t a slow broadcast going around the world. Resolvers (your internet provider’s, Google’s, Cloudflare’s) save each answer for as long as the record’s TTL, or time to live, allows. Until that time runs out, they keep handing out the old answer. Cloudflare’s docs say TTL “controls how long each record is cached and — as a result — how long it takes for record updates to reach your end users.”
So the honest answer to “how long does DNS take to update” is: as long as the old record’s TTL. Google’s Workspace help gives an example: “Changes to a record that has a TTL of 86400 seconds, for example, will take up to 24 hours to go into effect.” Cloudflare’s Auto TTL is 300 seconds (five minutes), but its docs add that changes can still take longer to show because “your local DNS cache may take longer to update.” If you plan a move, lower the TTL a day ahead. Google recommends 3600 before making changes.
Don’t test in your own browser and guess. Query a public resolver: Google’s dns.google tool, or nslookup yourdomain.com 8.8.8.8 at a command prompt. If the public answer shows the builder’s IP or target, your DNS is right and only your computer is stale. Restart the browser or flush your local DNS cache. If you set a wrong record earlier and a public resolver is still holding it, Google Public DNS has a Flush Cache page for its own resolver.
If the public answer is still wrong long after the TTL should have run out, it isn’t caching. Go back to steps 1 to 3.
5. www works but the root domain doesn’t (or the reverse)
yourdomain.com and www.yourdomain.com are two separate DNS names. Each needs its own correct record, and the builder needs to know about both. When one works and the other doesn’t, one of them is missing a record or still has an old one.
The usual cause is the root domain. Builders like to use a CNAME, but you can’t put an ordinary CNAME on the root, because the root always has NS and SOA records and RFC 1034 says a CNAME name should hold no other data. That’s why builders give you an A record (an IP address) for @ and a CNAME only for www. Some DNS providers get around this: Cloudflare’s CNAME flattening, for example, resolves a CNAME at the zone apex and returns the IP address instead, and other providers call the same idea ALIAS or ANAME.
Also check the builder’s own settings. Most of them let you pick a primary version (with or without www) and redirect the other to it. If only one version is added in the builder, the other may show an error even when its DNS is correct.
6. The HTTPS certificate hasn’t been issued yet
Sometimes the domain does reach the builder, but the browser shows a “not secure” or certificate warning. Builders issue free certificates automatically, but only after your domain points at them, because the certificate authority checks that it can reach your site. Let’s Encrypt’s HTTP-01 check, for example, puts a file on your server at a /.well-known/acme-challenge/ path and fetches it, and the docs note this check “can only be done on port 80.”
So a certificate warning right after you connect a domain usually means steps 1 to 5 were only just fixed, or one version (www or root) still points somewhere else and fails the check. Confirm both names resolve to the builder, then use the builder’s “retry” or “verify” button if it has one. If you use Cloudflare with the orange-cloud proxy on, its SSL mode also has to match what the builder expects, or you can get redirect loops.
A quick checklist before you contact support
Write down your nameservers, then the A, AAAA and CNAME records for both @ and www as seen through a public lookup tool, and compare them line by line with what your builder asked for. In one pass you will see a typo (step 1), an extra record (step 2), the wrong DNS provider (step 3) or a correct record your computer hasn’t caught up with yet (step 4).
If you’d rather not touch DNS at all, OneSol Max is a done-for-you small-business website where we connect your own domain for you, including the root and www records and the HTTPS certificate, and set up your CRM and SEO as well. It’s $1 for the first month, then $29 a month. Either way, the six checks above cover nearly every “my domain isn’t working” case, and none of them needs you to wait 48 hours and hope.