You've chosen a domain, built your site, and are ready to share it. Then you open the registrar's DNS panel and find a list of unfamiliar records, confusing labels, and a warning that your domain isn't connected yet. The problem usually isn't that your website is broken. It's that several services must agree on where your domain belongs, and those changes don't always become visible immediately.
A reliable custom domain setup is more than entering a web address and clicking publish. You need to understand which hostname you're connecting, remove records that can interfere, wait for DNS updates, and confirm that SSL, redirects, and basic search signals work correctly. This guide walks through the process in plain language, with a focus on knowing when your site is live and safe to promote.
What a Custom Domain Setup Actually Does
Every website address has three moving parts. Your domain name, such as yourbrand.com, is the human-readable label people type into a browser. DNS, or the Domain Name System, acts like a directory that translates that label into the technical destination where your website is hosted. Connecting a domain means changing that directory so visitors are sent to your website platform's servers.
Think of your domain as the sign above a shop. DNS is the map that tells delivery drivers which street address matches that sign. When you update the map, not every driver receives the new version at the same moment. Internet providers and browsers may temporarily rely on an older copy, which is why a new connection can work for one person before it works for another.
The third piece is SSL/TLS, the security layer behind ` It encrypts information moving between the visitor and your website. In practical terms, SSL is like the lock on the shop's front door. A secure connection protects visitors and helps them recognize that they've reached the intended site.
Practical rule: A successful connection has three outcomes. The domain resolves to the right website, the browser receives a certificate for the exact hostname, and visitors consistently reach one preferred address.
This system is mature and widely used. The first registered domain, symbolics.com, was created in 1985. A history and market overview of domain names describes how domain registration developed into a global market with standardized registration, renewal, DNS, and extension choices. You're not performing an unusual technical experiment. You're updating a well-established directory system.
Choosing Between Apex, www, or a New Domain
Before editing DNS, decide which domain arrangement fits your current business setup. You may connect a domain you already own, transfer it to another provider for unified billing, or purchase a new name through a registrar. These choices affect who manages the registration and where you edit DNS, but they don't change the basic purpose of the connection.
The apex domain is the root address, such as yourbrand.com. The www version, www.yourbrand.com, is a subdomain. Many platforms, including Solo's recommended configuration, use www as the primary published hostname and redirect the apex to it. This creates one consistent public address instead of making search engines and visitors choose between two versions.
Apex domains generally can't use a CNAME directly because of DNS protocol rules. A www hostname can use a CNAME, which makes it a straightforward starting point. Root domains commonly use an A record or a registrar-supported ALIAS-style option, while the www hostname points to the platform's stable destination.
| Option | Ownership | DNS Control | Best For |
|---|---|---|---|
| Connect existing | You keep the domain at your current registrar | You edit records where the domain is registered or delegated | Businesses already using a domain and email service |
| Transfer | The domain moves to a new registrar or platform account | Billing and DNS may become centralized | Owners who want fewer accounts to manage |
| Buy new | You register an available domain | The purchasing registrar controls the initial DNS panel | New businesses without an established web address |
Choose the option that matches your current registrar organization. If your email, renewal, and DNS records already work in one account, connecting the existing domain is often less disruptive than transferring it. A migration can be useful, but it isn't required for a dependable setup.
Connecting Your Domain in Solo Step by Step
Start inside your Solo dashboard and open Settings. Select Custom domain, then choose the option to connect a domain you already own. Enter the domain you want to use and select the www hostname as the primary host when Solo presents that choice.
Solo will provide a destination value for the CNAME record. Copy that value exactly. Don't replace it with your business name, the full browser URL, or a guessed server address. The value is a host string generated for the connection, and even a small spelling difference can prevent verification.
Open your registrar's DNS editor in a separate browser tab. If you're unsure where it is, the Solo guide to setting up DNS records can help you identify the relevant panel. Look for a records list and a button labelled Add record, Create record, or something similar.
Create the record using this format:
- Host:
www - Type:
CNAME - Value: The host string Solo provides
- TTL: Auto or
3600, if your registrar asks
The registrar is the place where DNS records live. Solo can tell you what record to add, but the registrar publishes that instruction to the wider DNS system. New users often stall because the registrar's screen may show several existing records, an empty input modal, or labels such as Name, Host, Target, and Value that appear to mean the same thing.
Save the record, then return to Solo and start verification. The apex address will be handled through Solo's connection flow after the www hostname resolves. Avoid adding extra records “just in case.” A clean, canonical mapping is easier to verify and troubleshoot than a collection of guessed entries.
Reading DNS Records and Waiting for Propagation
DNS works like a postal system. Your domain is the address, each DNS record is a routing instruction, and recursive resolvers are couriers that keep local copies of those instructions. When you change a record, those couriers refresh their maps according to caching rules. That's why a correct update may not appear everywhere immediately.
The record type tells you what kind of instruction you're reading:
- A record: Sends a hostname to an IPv4 destination. It's commonly used for an apex domain when the hosting platform provides that type of target.
- CNAME record: Makes one hostname an alias for another hostname. It's the usual choice for
wwwwhen a platform provides a named destination. - TXT record: Stores text used for verification or email authentication. It doesn't route normal website traffic.
For a broader explanation of DNS terminology, see what DNS configuration means. For email-related checks, you can also verify DMARC record separately from the website connection. Website DNS and email authentication often share the same domain, but they serve different purposes.
| Time Since Setup | Expected Status | Verification Method |
|---|---|---|
| 10 minutes | The new CNAME may appear with some resolvers, while others still show the previous state | Check Solo's verification screen and test a public DNS lookup |
| 1 hour | More regions should show the new destination, though cached results may remain | Use whatsmydns and an incognito browser window |
| 6 hours | Most routine connection checks should be consistent if the record is correct | Compare public DNS results and test both the preferred hostname and redirect |
| 24 hours | The configuration should be stable enough for a final launch decision | Use dig, public DNS tools, browser checks, and Solo's status screen |
These are checkpoints, not promises. DNS providers note that setup can complete in roughly 5–10 minutes, while full propagation can take from a few minutes to 48 hours depending on caching and configuration. The custom-domain propagation guidance from Wasabi supports repeated testing rather than treating the first result as final.
Common Setup Problems and Quick Fixes
Most failed connections come from a small set of configuration mistakes. Before assuming your site is damaged, compare the symptom on your screen with the likely cause below.
Stale records from an old host
Symptom: Solo shows the requested record, but verification fails or the domain still opens an old website.
Cause: An A, CNAME, NS, or TXT record from a previous hosting provider is still influencing the same hostname.
Fix: First, review every record using the affected hostname and remove only the obsolete conflicting entry. Next, leave required email and verification records intact, save the cleaned configuration, and retry after the DNS cache refreshes.
A CNAME added to the apex
Symptom: The www address works, but yourbrand.com doesn't resolve correctly.
Cause: The root domain was given a CNAME even though the registrar expects an A record or a supported ALIAS-style record for the apex.
Fix: Remove the invalid apex CNAME. Then follow the hosting platform's requested root-domain method, while keeping the CNAME on www.
Cloudflare proxy interference
Symptom: DNS appears correct, but SSL issuance or domain verification doesn't complete.
Cause: Cloudflare's orange-cloud proxy is handling the record instead of passing through the direct DNS response. CNAME flattening or a different authoritative nameserver can cause similar failures.
Fix: Set the verification CNAME to DNS only, not proxied. Then check that flattening is disabled for the verification name and that no NS record delegates that subdomain to another provider. Cloudflare-specific behavior is described in the DNS verification troubleshooting guidance.
DNS managed somewhere else
Symptom: You edit a registrar panel, but public lookup tools never show the change.
Cause: The domain's authoritative nameservers point to another DNS provider, often after a partial transfer or a previous Cloudflare setup.
Fix: Identify the nameservers currently authoritative for the domain. Then make the record change in that provider's dashboard, or complete the nameserver migration before editing records again.
These issues are reversible. If email is involved, don't delete mail records while cleaning website entries. After the site works, a domain blacklist check spamhaus can help you investigate whether a separate email reputation issue needs attention.
Verifying SSL, SEO Signals, and Final Redirects
A domain isn't fully ready just because the homepage appears. Test the exact hostname visitors will use and treat each check as pass or fail.
Start with SSL. Open the preferred address in a private browser window and look for the padlock. Select the connection details and inspect the certificate issuer and the hostnames covered by the certificate. The certificate must match the name in the address bar. DNS record type doesn't determine SSL validity, as explained in this technical explanation of DNS records and SSL certificates.
If the certificate shows the wrong hostname or fails to provision after the DNS connection has had time to update, check the record target, proxy status, and authoritative nameservers before trying again. Certificate providers may use a DNS challenge that requires a unique CNAME to remain available until validation and issuance finish. The DNS CNAME validation process for SSL/TLS certificates explains why removing that record too early can interrupt verification.
Confirm one public URL
Test both the apex and www versions. Your chosen primary version should load the site, while the other should issue a permanent redirect to it. A 301 redirect tells browsers and search engines that the destination is the lasting version, helping consolidate visits and indexing signals instead of splitting them between duplicate addresses.
Check the basic search signals
Open the sitemap URL and confirm it loads rather than returning an error. Review robots.txt to ensure it isn't blocking the site from crawling. Finally, inspect the homepage manually and confirm the title, description, headings, and visible business information render correctly.
These checks support trust, but domain authority isn't created by DNS alone. For broader context on building credibility through useful content and reputable links, consult the Miles Marketing guide to SEO trust. Solo's SSL certificate installation information is also useful when you need to understand the certificate stage separately from DNS routing.
Your 24-Hour Confidence Checklist
Use a staged review instead of refreshing one browser tab and guessing. Each checkpoint answers a different question about whether the custom domain setup is ready.
At 10 minutes
Check whether the www CNAME is visible to at least some resolvers. Open the site in an incognito window and watch for SSL provisioning. An early warning or inconsistent result isn't automatically a failure, because cached DNS data may still be circulating.
At 1 hour
Test from more than one network or use a public DNS tool that checks multiple regions. Confirm that the preferred hostname resolves consistently, the certificate covers the exact hostname, and the non-preferred version begins redirecting to the canonical address.
At 24 hours
Perform the final stabilization review. Test the homepage, key contact or booking pages, the apex-to-www redirect, the sitemap, and robots.txt. If email uses the same domain, send a test message and confirm that authentication and links behave as expected.
A successful launch is simple to recognize: visitors see a secure padlock, one consistent canonical URL, and a discoverable website.
Minor warnings during early propagation are normal. The important result is not that every tool agrees instantly. It's that the DNS record settles, SSL matches the hostname, redirects stay consistent, and real visitors can reach the pages they need.
Solo AI Website Creator lets you create a professional site and connect a custom domain through its website settings, without requiring you to manage a traditional hosting workflow. Visit Solo AI Website Creator to create your site, connect your domain, and complete the final DNS and SSL checks with a clear launch path.